Benchmarking lighttpd

I ran ab on our Manuals today and did parallel tests on it from both lighttpd and apache2. At first I was “concerned” because apache2 slightly outperformed lighttpd in both requests/second and total time to serve all requests (I used n=1000 and c=2, so 2 clients at a time, 1000 pages served).

Then I thought I would see how the two scale, and did a 1000 pages served to 10, 50, 100, 200, 500, 800 and a 1000 simultaneous clients)

Lighttpd didn’t begin to act funny until a concurrency of 800 while Apache began to flatten at 50 clients, degrade to a quarter of its previous speed (from 22 requests/second to 4 requests/second) by a concurrency of 100 and then finally was essentially unresponsive by a concurrency of 250 (and yes, I know how to tune up Apache and the pages were eventually serve because of a high ListenBackLog).

What I noticed is that lighttpd didn’t even show up in top until I hit a concurrency of >800, and when it did show up it was a single process using 9% of the CPU and as much RAM as a single Apache child (in contrast Apache had spawned up to to 400 processes). I killed it as it ramping up some more.

Here the kicker: when I took a look at the lighttd-error.log, the rampup of lighttpd wasn’t it’s fault, I only had 5 dynamically spawned FastCGIs and it just reached the limit on those. So I externally spawned 15 Ruby-FastCGIs, did a quick check at a concurrency of 1000, and the Hieraki application was putting about 20 requests/second. Ramped it up to 10,000 pages served to 1000 simultaneous clients and got the same results. I had to run it a couple of times because I just couldn’t believe it

Not bad, not bad at all, considering that the same scale would have fried Apache like an egg.

·:· Posted 8 February 2005, 22:43 by Jason Hoffman to Lighttpd  |