Sp(ee)dy Protocol

Ever heard of SPDY before? It's a protocol draft based on HTTP introduced by the Google Chromium Project. In contrast to HTTP, SPDY supports request multiplexing over a single TCP connection, which leads to a much higher efficiency. SPDY also compresses the HTTP headers carried on top of it, to mention just two features.

Implementing SPDY in existing web servers is not a pony farm since it requires major changes to the core server logic. "mod_spdy" provides SPDY support for Apache but does not support request multiplexing, which would require hacking the core.

Apart from visiting the CeBIT last Saturday, I've spent my weekend implementing SPDY in pronghorn. In order to make multiplexing work, I've to put in some additional effort. But the results look really encouraging so far.

pronghorn outperforms lighttpd and nginx

As this benchmark shows, pronghorn 0.8 outperforms lighttpd and nginx with ease. Apache is beaten as well, but it's like taking candy from a baby.

A 10 kilobyte sized file has been served 10,000 times at 6 concurrency levels (1, 10, 100, 200, 500 up to 1000 simultaneous requests). As this benchmark shows, pronghorn performs best at 100 concurrent requests (handling ~55,000 requests/s) in this scenario. The requests have been generated using ApacheBench (ab) on a Linux 2.6 system with the following specs:

  • Intel Xeon X3220
  • 8 GB DDR2-800 ECC RAM
  • 2x Samsung HD103HJ @ RAID-1
  • 3ware 9650SE-2LP RAID controller
  • chassis/board/power supply: Dell PowerEdge R200 (shouldn't matter)

The server side was powered by another Xen domU on the same physical machine (with just 1GB of RAM).

software versions used:

  • Linux 2.6.26
  • pronghorn 0.8 (single-threaded, epoll, sendfile)
  • lighttpd 1.4.19 (epoll, sendfile)
  • nginx 0.7.62
  • Apache 2.2.12 (worker mpm)

 

Bench1

 

But, as nice as this might look like, be aware that pronghorn 0.8 isn't stable yet and the final performance might slightly differ from these results.