Benchmarking SPDY vs. HTTP in 4 steps
Conclusions first!: SPDY’s efficiency (header compression, TCP windowing && slow start, etc.) not only allows for high throttles, but the inline images are pushed along with the index, relieving the browser of first parsing/requesting the resources before they are sent. While SPDY’s response time was faster than HTTP for a single-domain page, a more real world scenario would involve sharding. SPDY saw no substantial improvement with sharding, but HTTP did (albeit requiring 24 times more sockets!).
Step 1. Configuring SPDY on the server
- yum install mod_ssl && rpm -Uvh https://dl-ssl.google.com/dl/linux/direct/mod-spdy-beta_current_x86_64.rpm
- Enable/Disable SPDY via /etc/httpd/conf.d/spdy.conf using “SpdyEnabled on”
- Enable non-SSL SPDY to facilitate debugging using “SpdyDebugUseSpdyForNonSslConnections 2” . Performance with SSL would be slightly different.
- Turn on Keep-Alive and MaxKeepAliveRequests to 200 so that Apache isn’t a limiting factor. Didn’t bother with gzip since everything other than the index is already compressed.
Step 2. Configuring the Browser
- Start Chrome with non-SSL mode enabled: chrome.exe –use-spdy=no-ssl
- Display SPDY debugging @ chrome://net-internals/#spdy
- Disable caching in Dev tools.
Step 3. Add artificial latency between you and the server using netem
Step 4. Creating the optimal test page
Since SPDY multiplexes all elements through a single TCP stream, I tested both with a single domain page and a 4-way shard. Domain sharding and 3rd party includes should be avoided for optimal SPDY performance.
