At Wormly we’re ardent believers in the maxim that performance is a feature.  Google’s SPDY protocol is an experimental extension to HTTP with the goal of reducing the latency inherent in the HTTP protocol.  Or, rather more simply: “Get those pages delivered to the user faster!”

From our perspective the biggest benefits come from stream multiplexing and header compression.

Multiplexed streams allow the browser to simultaneously request a bunch of resources over a single TCP connection – particularly handy because it avoids the latency penalty of setting up multiple TLS sessions for HTTPS.

Header compression (both request and response headers) helps further reduce the amount of data that must traverse the pipes of the internet.  These headers are probably bigger than you think – take an example request to wormly.com:

That’s 348 bytes just in the request header. And most users’ upstream bandwidth is rather more limited than your web servers’.

SPDY is currently supported by Firefox and Chrome – on Windows, Linux, Mac and Android platforms.  As it happens more than 70% of our users are on Chrome, so the benefits of adopting SPDY will be seen widely.

Enter mod_spdy

Google has released a very simple to use Apache extension to add SPDY support to your web server. We use Apache to serve www.wormly.com and we were also using mod_php to serve the parts of our web application which are written in PHP.

This actually presents a problem with mod_spdy, because its’ implementation is threaded, and PHP is not guaranteed to be thread safe.  The recommended approach is to replace mod_php with a FastCGI interface to serve any PHP requests from a dedicated pool of PHP processes – leaving the Apache processes free of any trace of the PHP interpreter.

We actually intended to switch to this sort of setup some time ago – and to switch from Apache to Nginx in the process.  However a still-unresolved limitation in Nginx whereby all FastCGI requests are buffered – meaning PHP cannot ensure that data is immediately flushed to the client – has so far prevented us from doing so.

Happily the availability of mod_spdy pushed us to find a solution; and ultimately we found it in mod_fastcgi, which does support unbuffered connections to the upstream PHP server.

Switching to FastCGI also allowed us to switch Apache to the Worker MPM rather than the Prefork MPM – and the benefits of these two changes significantly reduced the volatility of response times through our web application.  So we had a win even before deploying SPDY!

After this, installing mod_spdy is as simple as:

Restart Apache, and you’re done.

Note that Google’s included package management handles automatic updates of the mod_spdy package.

It should be noted that mod_fastcgi is not commonly included in CentOS / Red Hat Enterprise linux distributions and their derivatives (including Amazon Linux).  You can either compile it from source or use a 3rd party repository which does include it: for example the RPMForge, DAG or City-Fan.