At Surge 2012, I gave a talk called “The Architecture Behind Super Fast DNS” which explained the routing, redundancy and design of a modern anycast DNS network. In putting the slides together, I remembered a very important talk from the Velocity 2012 conference in Santa Clara, CA, titled “Understanding and Optimizing Web Performance Metrics” given by Bryan McQuade from Google.
This talk went into the guts of today’s modern web browsers, explaining how browsers interact with the network, how the HTML5 parser works and how renderers work.
Bryan touched on a topic near and dear to my heart: the serialized blocking exhibited by browsers as they complete DNS queries and how even a simple DNS timeout or dropped query can result in a one second retry interval for users.
On initial page load, there’s nothing a browser can do but wait for DNS queries to be returned. On inline object load, the browser has the ability to parallelize its queries, but each query is still a synchronous operation.
Time to first byte
In the web world, web optimizers are concerned about the time to first byte (TTFB) start time which encompasses the DNS transaction, TCP socket connection, request and server processing, up to the time the first byte of content is being delivered back to the requestor.
With DNS being the first piece of that chain, I thought I’d get funny with my presentation and created the acronym TTFDNSQR – Time to First DNS Query Response. Honestly, I was making a joke for all the geeks in the room who live in an acronym filled world, but then I realized that I was really talking about performance of the system before the first byte or performance behind the byte.
Performance behind the byte
One of the most significant discoveries came when I was working with a prospective Dyn client who was complaining that they had done everything they could possibly do to optimize their HTTP TTFB, but couldn’t get their page load time under 500ms.
To help out, we dove into a complete analysis of their site’s load cycle from DNS to connect time to TTFB, discovering that a multi-layered DNS load balancing system was accounting for over half of the page’s load time!
Having multiple layers of unicast DNS, delegations to GSLB appliances, and lame delegations was causing DNS timeouts at many layers of the system.
At Dyn, DNS latency is something we try to help our client optimize significantly in their environments, which is why we run a global IP anycast network. But we also strongly believe in reducing the number of DNS round trips that need to be performed for various DNS-based load balancing systems. My goal is to try to educate the world about the inherent latency of multi-delegation traffic management systems and why Dyn is so different in what we do.
Register for my upcoming webinar
Next Wednesday, October 31st, at 2 p.m. Eastern, I’ll be hosting a Dyn webinar titled “Managing Traffic with DynECT Managed DNS Advanced Services” where I’ll be teaching a lesson on our DNS-based load balancing and traffic management services – each with the unique feature of enabling geolocation with a single DNS round trip.
If you’re a performance junkie like I am, I hope you’ll join me for this informative webinar.