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!).

image

image

image

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

image

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.

image