Ajax Performance

Real world case study in slimming down bandwidth consumption

One issue I keep coming back to here is the hidden, cumulative cost of bandwidth as traffic scales. Another case study showed up a few days ago from Jeff Atwood at Coding Horror. Using traffic patterns from a popular article published in February, he found 4 useful techniques for bandwidth optimization: offload images to a third party, use HTTP compression, offload RSS hosting, and compress JavaScript and CSS.

Offloading images ties in well to my discussion of connection parallelism back in December. Loyal readers will recall the tip for using DNS wildcards to trick the browser into assigning more connections to your host, but that does nothing to reduce your bandwidth costs. The solution I suggested is appropriate when you want to maximize connection parallelism and have bandwidth to spare.

Images hosted by a third party are allocated two connections, and none of the bandwidth tracks back to your infrastructure. I’m curious whether any of the third party hosts allow you to make use of the DNS hack to also get the benefits of 6 connections over their pipes. That would truly be the best of both worlds — outsourced hosting and as much parallelism as the browser can handle.

Jeff recommends using Amazon S3 for image hosting, and that echoes what I’ve heard from numerous other users. At $0.20 per GB transferred, it’s hard to argue with the economics. This is a great solution if you have the time or energy. If anyone knows whether DNS wildcarding works with S3, I would love to hear about it.

A brief coda on connection management: HTTP 1.0

In my previous article, I briefly mentioned that per-host connection limits are different for HTTP 1.0 vs HTTP 1.1, and I suggested that you almost always want to use HTTP 1.1. Today, I will explore why and highlight one tiny scenario where HTTP 1.0 might still be useful.

While IE and Firefox both default to two concurrent persistent connections, the limits are a bit less stringent for HTTP 1.0. IE allows 4 concurrent HTTP 1.0 connections, while about:config tells me that Firefox currently allows 8. So, without any DNS hackery, HTTP 1.0 gives you at least twice as many connections to work with, but it comes at a substantial cost.

To understand why, let’s revisit our goals from the previous connection discussion. We were talking about optimizing your connection layout to benefit the modern population of users on broadband connections for whom the time to set up a connection and request content is a much higher percentage of the total transfer time than the actual content download. Persistent connections allow us to minimize the cost of connection setup, since we only have to do that once for each connection to the server, and the DNS hack lets us parallelize the requests so we have fewer stalls waiting for the server to reply to our requests. Switching to HTTP 1.0 is typically a significant step back as you now need to eat that connection cost for each request to the server.

I can think of only one case where the gain would outweigh the costs. For a site with a small number of large objects or a small number of objects that require server side content generation (which tends to elongate the time from when we send our request till we start receiving data), the cost of creating the connections will be a smaller chunk of the total latency. Switching to HTTP 1.0 may give an effective gain in throughput without requiring you to monkey around with DNS.

In the time I’ve been in the performance space, I’ve seen only one customer use this technique. They had very specific constraints — a few large objects — so they got a nice win with HTTP 1.0. For all other cases, HTTP 1.1 is unambiguously the way to go.