So in the course of testing ruby http clients, I realized with full force that persistent HTTP connections really do matter, especially if you are doing SSL/https connections.
I knew in theory it improved performance, especially for SSL, but I guess I hadn’t really realized how much it really mattered, a lot. For your web apps/servers talking to ordinary browsers, not just for software automated http clients.
If you have an app that’s accessed over https, a browser connecting to that app might need to fetch half a dozen, a dozen, or more different assets over https. Sure, if things are working right they’ll be cached (until they change) after the first request. Sure, we try all sorts of things to minimize the number of seperate http connections. But there’s still probably 6-10, including images and such, at least.
Over https/SSL 6-10 separate HTTP connections vs 6-10 HTTP requests over a single persisted HTTP connection really does make a difference, as much as several hundred miliseconds, enough for your users to notice, possibly enough to effect CPU load on your machine.
It turns out, I have some web apps that enforce https only, which were not supporting persistent connections!
It looks like the default RHEL/CentOS 5 httpd install, for some reason has “KeepAlive Off” in it’s httpd.conf. Even though apache, for quite some time, has defaulted to KeepAlive On, for some reason RHEL installs override this default.
It’s worth checking. Check your httpd conf files, grep for “KeepAlive”, make sure there aren’t any “KeepAlive Off”s in there. Or check by actually making a connection to your server — with curl, with a browser using Chrome’s developer tools ‘network’ tab, or LiveHTTPHeaders in Firefox. When you make a request from your browser, in the response headers you do not want to see “Connection: close”. That means the server is insisting on closing the connection right away and not letting the client use a persistent connection.
Some people reading this are going to be thinking “Duh, how can you have been deployed with such a silly configuration, do you know what you’re doing?” But others of my peers at similar institutions know how it is, and probably have never checked this either. It’s really worth a check.
(I am curious why the heck RHEL5 installs httpd with KeepAlive Off. All I’ve found is some other people asking the same question. )
update: some notes on performance tradeoffs of using KeepAlive. I still believe that for a webapp that’s served over SSL, you pretty much have no choice but to enable keepalive for proper performance, and make sure your server can handle it.
It doesn’t look like there’s a way to tell apache “Allow X concurrent connections with KeepAlive, and if there are X connections and more connections come in, then for THOSE connections above X, insist on effectively ‘keepalive off’. If there were such a way, it could be the best of both worlds, making sure you serve KeepAlive within the constraints your server can handle. Can anyone figure out a way to do that?
Bibliographic Wilderness 