I think all emphasis on server software speed is overrated. In pretty much everything but hello world, the vast majority of the time is spent inside the web app, not in the server.

Yes, lowering the web server overhead is a good thing. But I think in most cases it's already so low that further reducing this overhead results in no noticeable impact in real-life scenarios. At some point you'll just be benchmarking how fast the kernel is at doing connect(), read() and write() - in other words how fast your computer can do nothing.

For example, let's consider this thought experiment:

Someone here mentioned Mongrel2 getting 4000 req/sec. Let's replace the name "Mongrel2" with "Server A" because this thought experiment is not limited to Mongrel2, but all servers. I assume he's benchmarking a hello world app on his laptop. Suppose that a hypothetical Server B gets "only" 2000 req/sec. One might now (mistakenly) conclude that:

- Server B is a lot slower.

- One should use Server A instead of Server B in high-traffic production environments.

Now put Server A behind HAProxy. HAproxy is known as a high-performance HTTP proxy server with minimal overhead. Benchmark this setup, and watch req/sec drop to about 2000-3000 (when benchmarked on a typical dual core laptop).

What just happened? Server B appears to be very slow. But the reality is that both Server A and Server B are so fast that doing even a minimum amount of extra work will have a significant effect on the req/sec number. In this case, the overhead of an extra context switch and a read()/write() call to the kernel is already enough to make the req/sec number drop by half. Any reasonably complex web app logic will make the number drop so much that the performance difference between the different servers become negligible.