Persistent Connections & Performance
Reaping performance benefits from using persistent connections on your HTTP web server is nothing new. In a recent test of a SSL site, one of our clients enabled persistent connections on their servers as part of a new deployment. The results were quite impressive: for a single user & negligible server utilization, page durations dropped from 12 seconds to only 3.5 seconds. Persistent connections can contribute to much of this duration difference by reducing the amount of time needed establish new connections. The use of SSL makes this feature even more important, as the SSL layer requires additional session negotiation. Despite the potential for better performance, many systems still today do not utilize this feature for one reason or another.
Load Tester can be easily used to identify a system which may not be using persistent connections. The best place to start is in the Headers View. The Headers View will identify both the protocol used, as well as other HTTP Headers being sent back.
If you see the header: “Connection: close”, then your site is not using persistent connections. Some servers may also send back a response using HTTP 1.0, in which case the connection most likely is not persistent.
So why would sites not support persistent connections?
- Limited by maximum number of open connections on the server: This appears to be especially true for Apache 1.x servers, which have a low connection limit. Administrators can work around this by increasing the connection limit (which may require recompiling Apache), or decreasing the HTTP Keep-Alive timeout. The later option can be used to reclaim connections shortly after the browser is done, but still allow browsers to reap the benefits of reusable connections to gather static resources on a page. Alternatively, administrators may consider upgrading web servers to one which supports large numbers of open connections without difficulty.
- Disabling persistent connections provides a workaround for browsers with problematic SSL implementations: Particularly, IE 5, as well as some unpatched versions of IE 6 have been documented to interact badly with SSL sites using persistent connections. In some Apache configurations, the workaround has been to disable persistent connections over SSL with all versions of IE. In practice, we’ve found that enabling persistent connections for IE 7 and above can yield significant performance improvements for a substantial user base without introducing new defects.
- For Load Balanced sites (which do not use sticky sessions), establishing a new connection for each transaction ensures the transaction is serviced by the least loaded server: before turning off persistent connections entirely, test it! If it makes sense to balance page resources against multiple hosts, it may be more effective to use alternate hostnames to split the traffic. As the traffic scales up to many users, it becomes statistically improbable (except under very selective circumstances) for independent users to be favoring connections that happen to be routed to a single overloaded server while other servers remain idle. Further, this situation can be minimized by reducing the idle connection Keep-Alive, as mentioned above.
Given those conditions, persistent connections aren’t necessarily the best choice for every possible configuration. But before writing them off entirely, we do recommend testing that option first: it can be an easy setting to improve end user experience considerably!
-Frank, Engineer at Web Performance