http_load - test your server for heavy load
acme.com
acme.com
In a web application, most bottlenecks are at the database and appserver layers as opposed to the webserver. A good load test needs to be fully transactional so you can simulate login/logout, shopping, searching, or whatever real users of your application do. A good load test also needs error detection (content-checking). Without content checking, I've seen demos where a "testing tool" ran, someone unplugged the DB machine, and everything still came up green. From an end-user perspective, a real user would have seen the "data grid" section of the webpage replaced with an error message and the web app was unusable, but the testing tool was happily chugging along, showing green.
close static file: 750 fetches/sec, openload shows 800.
php output: big stream of errors about byte count wrong
other php site: 37 fetches/sec, openload does 135.
I'm not sure which is right, but the 37 vs. 135 could easily lead you astray. This run is 10-13% cpu load on the local machine so it is likely not a saturation problem.Not that I'm recommending openload, it could use some help, but it is useful to compare.
But 'ab' only manages a load of 36 tps and is unable to saturate my web server. (identical machines, php+sqlite3 hairy web page) 'http_load' has the same problem. 'openload' can saturate the web server at 135 tps or so.
'ab' does not present a significant load on its host, so I'm not sure why it can't drive the web server to saturation, but there it is.
Number of simultanous clients to simulate. This is optional and defaults to 5.
I believe ab defaults to 1 client.
that will give you 1000 concurrent connections, 100k total connections.
good luck.
However this is just HTTP load.. if you have JS running and making database calls after page load I don't think this will help your testing methods.
It generates N requests every second without waiting for the previous N requests to complete. Actually, it never waits for requests to complete. It kills them so the http server has no where to send data. With Tomcat, this causes hella errors in the logs. It's just not an accurate stress test.
ab is okay but I found it was more difficult to ramp it up to really stress the server. I prefer siege (http://www.joedog.org/JoeDog/Siege) because it performed well, produced useful output (ab's output is pretty good too), and was convenient.
We used these three to test a new app stack for yellowpages.ca a couple years ago. siege became the standard in the end. We also tried JMeter which performed pretty well but the GUI/XML configuration was inconvenient (it's a complicated development environment).