Benchmark raises questions over SPDY performance

A web performance researcher has raised questions over how effective the SPDY protocol will be when working with real world web sites. The SPDY protocol, developed by Google, has been designed to speed up traffic on the web by using a number of techniques including compression of HTTP headers and multiplexing of multiple HTTP requests over one TCP connection. Google has reported 50% faster performance improvements when using SPDY. The protocol has already been implemented in Chrome and Firefox 13, and for Apache.

That reported performance improvement led to research being carried out by web performance researcher and Akamai Chief Product Architect Guy Podjarny. He wanted to create a more realistic test of SPDY, and set about testing the top 500 web sites (according to Alexa) using a SPDY implementing reverse proxy. He reports that he found SPDY is only 4.5% faster than HTTPS and is 3.4% slower than unencrypted HTTP.

One issue is that the common performance optimising practice of spreading content over a number of domains works against SPDY's multiplexing, which only works well when the content is from a single domain. Podjarny concludes that "I believe SPDY is still awesome, and is a step in the right direction. This study and its conclusions do not mean we should stop working on SPDY, but rather that we should work on it more, and make it even faster".

Meanwhile, developers are continuing to implement the SPDY protocol as it stands. Valentin C Bartenev has announced that a test version of a SPDY module for the Nginx web server is now available. Currently though, it is necessary to patch the Nginx sources to integrate the support. Bartenev describes the necessary steps in his posting to the project's mailing list.

The implementation currently has a number of known problems and limitations though. There is no support for server push and SSL buffering is switched off, also the post_action directive and rate limiting are not supported on SPDY connections. Bartenev says that they plan to improve this support over the next few months and eventually integrate the code into the main Nginx code; with that in mind, he notes that users should expect frequent updates and asks them to report their experiences.

(djwm)