Some benchmarks

Replies (3)

RE: Some benchmarks - Added by icy over 12 years ago


I'm the author of weighty. I'm curious why pound should be so much faster than weighty. Did you use the multiple threads feature?
Without looking into it further, I can imagine pound using multiple threads while you didn't with weighty. "ab" of course doesn't support that.

Which brings me to my main point: please publish all configs and parameters you used.


RE: Some benchmarks - Added by fredrikwidlund over 12 years ago


I added a post with tests using multiple cores now and the different between weighttp and pounce is much smaller but at least in this test is seems pounce is slightly faster.


RE: Some benchmarks - Added by gstrauss about 8 years ago

FYI: a new (and quite a bit faster) version of weighttp is in my fork at

x-ref: pounce code can be found at as the project on appears to no longer be available.
@fredrikwidlund, is there a better source?

A quick, non-scientific test on an old laptop (1st generation i5 with 2 cores) and I can see that my branch of weighttp is quite a bit slower than pounce when running a single thread of weighttp. The limitation is 100% CPU usage of the single core. However when running 2, 3, and 4 threads, my branch of weighttp is faster than pounce. These quick tests were all done without keep-alive for a 100-byte static file, and with lighttpd running with 3 workers.

From a quick glance at the pounce code, one difference is that lighttpd parses the HTTP response headers and pounce does not. This might explain some of the performance difference between the two. Another difference is that pounce enables SO_LINGER with 0 timeout, and TCP_QUICKACK socket options. A further quick test and I see that enabling SO_LINGER with 0 timeout in single-threaded weighttp made weighttp almost as fast as pounce, though the test results are still limited by weighttp hitting 100% CPU use of single core. For the small requests in my quick tests, the overhead of setsockopt to set TCP_QUICKACK on each connection (per request) slightly degraded performance.

Now then, back to applying these load tests to speed up lighttpd... :)