Just a tiny correction: ‘httperf_num-call = 1′ should probably read ‘httperf_num-calls = 1′ in autoperf.conf (at least on my system and the docs).

And for those who get connreset errors, set num-calls to 1 - the reason might be the fact that your server does not support persistent connections (just so there’s a solution to this problem in google ;)

It measure loading speed of page and it’s requisites (images/js/css) like browsers do and shows nice detailed chart - so you can easily spot bottlenecks.
It’s very detailed and accurate, supports a lof of features like Keep-Alive or HTTP-compression.

Also very useful thing is that this tool is able to verify network quality of your server (packet loss level and ping delays).

http://www.dailyartisan.com/news/12-tools-to-increase-website-speed/

The output gives a lot of metrics, as summary and as graphs against times. Definitively not the tool to copy/paste a few figures to boast with your friends, but quite useful to actually know what your application/servers we’ll do in real wild life. (Note: “ab” is still useful, but it is _not_ a load testing tool)

We’ve successfully stressed (and optimized till success) an application with a load of 100,000 people invading a ten-server cluster in 1 minute (/. effect if you will). It didn’t need special hardware or setup, just a few servers sitting on the same GbE switch. We even hacked a plugin to actually use a login database to simulate those people so they could all auth individually.

It took time for the first setup, but now we can bench about anything for real in 30 minutes (record, edit, play, see). But admittedly, it takes also a few times to fully understand the result and link them to concrete behaviours from the application.

Tsung authors are reactive and very friendly on the mailing-list. And not the least, Tsung is a generic load test, and HTTP is not the most important concern for them (they target messaging and VoIP).