Ajax Performance
A blog by Ryan Breen of CloudFloor
A brief coda on connection management: HTTP 1.0
December 21, 2006 on 2:09 am | In http | 3 CommentsIn 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.
3 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by WordPress with Pool theme design by Borja Fernandez.
Entries and comments feeds.
Valid XHTML and CSS. ^Top^
I am developing a web based application on a site that uses SSL. The page loads around 80 plus (1-5kb each) static images. Sometimes the app will load images (3 or 4 generally but could be as high as 80+) from the server side as well (they load a lot slower). I noticed you said multiple connections through SSL may not be beneficial (handshaking time and cost per certificate).
I have compressed the 20+ required JavaScript files into 1 file and performed the same with the CSS files. I have turned the interface images, where applicable, into a single tile based image (one image split into peaces with CSS). I will try disabling IIS “keep alive” as well.
The JavaScript and CSS solutions help with the initial load of the page, but it doesn’t solve the 80+ images or the Ajax calls which are qued when waiting for server side images to come down the pipe. I am wondering what you think I should do. Feel free to email if the comments section is not appropriate.
Comment by JD — January 21, 2007 #
In my previous post, Willy Tarreau had some interesting feedback in the comments about an application that sounds somewhat similar to yours but was running on Apache. In his case, disabling keepalives was quite beneficial because Apache was failing to handle the load from juggling so many concurrent connections.
However, given that your application has a number of small images, a better approach might be to segregate the images onto a separate domain, similar to the technique I discussed in those post. The image downloads would happen on a different connection pool from your Ajax calls, so it would never be the case that Ajax calls queued up behind 80+ image loads.
I would suggest that you leave keepalives enabled unless you have a strong sense that IIS is choking under the load from the inbound connections. You can always experiment with leaving keepalives on or off, but separating your content should give you a more predictable and smooth user experience.
Note that, as Georges mentioned in the last article, you will likely need a separate SSL certificate for the images host. That may or may not be a show stopper for you, but I’m assuming it can be overcome, at least for the purposes of benchmarking performance to see if this approach is worthwhile.
Please let me know what you find in your research. I am very interested to hear what approach works best for you.
Ryan
Comment by Ryan Breen — January 22, 2007 #
Turning off keepalives for IIS on our dev server caused all the pages except the inital page to fail (almost immediately). Flip the switch back ‘on’ and the site loads like normal. I will see about the sep. connections (a lot of red tap, within the company to get extra sub domain and within the gov as well). I will keep you updated.
Comment by JD — January 23, 2007 #