Inspired by mnot's latest post about http caching performance I thought i take a deeper look into lighttpd. I was just impressed by the numbers and thought: "Well, there is a piece of code where one can learn a thing or two just by reading it."
So, instructions on how to get the svn checkout are to be found here (And btw. universal binaries for svn client are available here).
While the svn binaries worked fine, the instructions to compile the checkout showed that some more tools are needed than I had installed. Hmm. How is fink for Intel doing these days? (I love fink's service, but i hate the interface...) Fink is not so well. autoconf25 which lighty wants is not available. Getting autoconf 2.5.60 from GNU server, building and installing it is a matter of seconds. But, alas, the svn checkout of lighty has some Makefile macros screwed up and autoconf does not like it. Well, maybe my setup is bent.
Ok, getting the stable release 1.4.11 source and building that is no problem at all. Bleeding edge. Except, it has skipped the pcre feature which everybody expects (especially the test cases), so after fink installed pcre, the rebuild is runs and the tests look much better now. 1 failure in mod-auth.t and one in mod-ssi.t.
So, let's get a feeling for http servers, installing autobench and diving into the HOWTO a bit. Turns out that autobench tests the response rates and times of a single resource. So, you learn what the server can do iff caching is at its best. Fair enough. Here I expected lighttpd to really shine.
So I made a little bench using my Macbook Pro as server, connecting it with gigabit ethernet to our network and running autobench on our Dell Xeon server against it. First the apache2 and then lighttpd running on the book. Of course this is not real super science. Our network was not isolated at the time and I had some applications open on the laptop. But, as I said, I wanted to get a feeling real quick.
And it worked quick and well and I had a text file with the measurements. Looking at the numbers I could immediately see that both servers showed more or less the same performance. Hmm. What does this mean? Everyone was telling that lighty is faster and it should be on this sort of benchmark. Some browsing brought me to tweaking lighty for multi processor setups. Since my book basically has two cores, I gave lighttpd 4 workers and made another run.
The graph you see was generated using Plot, a really nice and free application which did the job beautifully. Recommended for some quick graphing. It shows on the x axis the number of requests fired by autobench per second and on the y axis the number of responses it got within 5 ms. Every response coming a tiny bit later is not counted.
Now with 4 workers lighttpd could really shine. The ditch at 14000 I would disregard. I also included the second measurement of the apache2 server in the graph. As you can see, there is big variation, but the general tendency can be seen. Just don't take the number too serious.
So what do I see? First of all, I see that my little laptop can serve a good 8000 responses per second (downhill and with the wind from behind). Whew! Quite nice for a laptop. There is a saturation starting at around 6000 requests/s for apache and lighttpd with a single worker, while the 4 worker configuration is still blazing up to 10000 requests. Nice work and hat off!
So I feel fully motivated now to find out how lighttpd is doing it. But that is content for another posting...
Technorati Tags: apache, autobench, autoconf, benchmark, fink, http, httperf, lighttpd