 |
| Bryan |
 |
| Matthew |
By Matthew Steele and Bryan McQuade,
PageSpeed Insights Team
At Google, we strive to make the whole web fast. Our work in this area includes
PageSpeed,
Google Chrome, and the
SPDY protocol, among other efforts. In December of 2011, to make it easy for you to enable the SPDY (pronounced "SPeeDY") protocol on your sites, we released an early beta of mod_spdy, an Apache module that adds SPDY support to the Apache HTTPD server. We’ve spent the last few months working with our early adopters to fix bugs and tune performance of the module. Today, we’re launching a version of mod_spdy that we encourage you to try on your web server.
Installing mod_spdy
To install mod_spdy on your Apache 2.2 server, simply download the appropriate
mod_spdy Debian or RPM package for your platform, or
compile from source. Once installed, your Apache server will begin using SPDY to communicate with SPDY-compatible browsers (e.g. Google Chrome, Android, and recent versions of Firefox). SPDY runs over HTTPS, so any HTTP (non-HTTPS) traffic on your site will not be affected by mod_spdy. Further, since SPDY requires server-side support for the NPN TLS HTTPS extension, which is not available in most current Apache environments, a version of mod_ssl with NPN support is included with the mod_spdy packages.
Enabling SPDY for your site improves performance in several ways:
- The server and browser can compress HTTP headers, saving bytes on the network.
- Multiple resource requests can be multiplexed over a single TCP connection, saving connections on the network.
- The browser can request all page resources at once instead of a few at a time, which reduces the number of network round-trips needed between server and client.
We've tested mod_spdy using locally-mirrored pages from popular websites, and have seen significant speedups compared to serving via plain HTTPS – comparable to the gains that Google’s own servers achieve by using SPDY – with no extra configuration and negligible effect on Apache’s CPU and memory usage. In extreme cases, for example, pages with many small resources, we’ve seen mod_spdy reduce load times by more than 50%.
How mod_spdy works in Apache
Implementing SPDY in Apache posed several interesting challenges. For example, multiplexing is an important performance feature of SPDY which allows for multiple requests in a single SPDY session to be processed concurrently, and their responses interleaved down the wire. However, due to the serialized nature of the HTTP/1.1 protocol, the Apache HTTP server provides a one-request-per-connection architecture. Apache’s connection and request processing normally happens in a single thread, like so:
This works well for HTTP, but it presents a problem for multiplexed protocols like SPDY because in this flow, each connection can only process one request at a time. Once Apache starts processing a request, control is transferred to the request handler and does not return to the connection handler until the request is complete.
To allow for SPDY multiplexing, mod_spdy separates connection processing and request processing into different threads. The connection thread is responsible for decoding SPDY frames and dispatching new SPDY requests to the mod_spdy request thread pool. Each request thread can process a different HTTP request concurrently. The diagram below shows the high-level architecture.
Happily, all this is almost completely invisible to users and server administrators alike--you can continue to use your existing Apache modules and configurations.
Download mod_spdy for your platform and give it a try, and let us know what you think on our
mailing list. mod_spdy is an
open-source project and we welcome contributions. We are continuing to add new features, tune performance, and improve support for up-and-coming versions of the SPDY protocol.
Matthew Steele and Bryan McQuade are Software Engineers on the Google PageSpeed Insights Team in Cambridge, MA. When not working on mod_spdy, they focus on developing tools to help site owners understand how to speed up their sites.
Posted by Scott Knaster, Editor
