Web Performance Calendar

The speed geek's favorite time of year
2011 Edition
Matthew Steele photo

Matthew Steele is a software engineer at Google, working on making the web faster. Matthew has worked on Page Speed for Firefox and Chrome, has contributed to mod_pagespeed, and most recently, has led design and development of mod_spdy for Apache.

Bryan McQuade photo

Bryan McQuade (@bryanmcquade) leads the Page Speed team at Google. He has contributed to various projects that make the web faster, including Shared Dictionary Compression over HTTP and optimizing web servers to better utilize HTTP.

At Google, we strive to make the whole web fast. Our work in this area includes Page Speed Online, mod_pagespeed, Page Speed Service, Google Chrome, making TCP faster, and the SPDY protocol, among other efforts. The SPDY (pronounced “SPeeDY”) protocol allows web sites to be transmitted more efficiently to the web browser, resulting in page load time improvements of as much as 55%. To make it easier for web sites to realize the benefits of SPDY, we’re releasing the source code for mod_spdy, an open-source module for the Apache HTTP server.

Getting Started with mod_spdy

mod_spdy is still in early beta, and is not yet recommended for deployment in production environments. If you’d like to test out mod_spdy and help us to make it better, please consult our Getting Started guide. We hope to make it production-ready sometime in early 2012. Stay tuned by subscribing to our discussion forum.

SPDY and Apache

mod_spdy is an Apache 2.2-compatible module that provides SPDY support for Apache HTTP servers. 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.

To learn more about how mod_spdy works within Apache, consult our wiki.

Help to improve mod_spdy

You can help us to make mod_spdy better by doing compatibility and performance testing, by reviewing the code and sending us feedback on the mod_spdy discussion list. We look forward to your contributions and feedback!