There are some good nuggets in this article, but he seems to miss a point that I feel is very important and yet is often overlooked in real-world web load testing; emulating an actual client behaviour under different real-world scenarios. Hitting a page or pages X times usually bears almost no resemblance to how a real-world application is used and therefore gives no indication of actual performance and capacity.
To test a web app properly you need the ability to script and/or replay real-world session browsing behaviours, simulating typical interactions. This can be both very time consuming and difficult to set up but yields far more useful and realistic results. In the past I have reasonable success using tools like The Grinder (barely maintained and poorly documented, but very useful and scriptable in Python), and even Microsoft's Web Application Stress tool (scriptable in VB). There are probably better tools than these out there but these at least allow you to code a detailed interaction with you site.
> There are some good nuggets in this article, but he seems to miss a point that I feel is very important and yet is often overlooked in real-world web load testing; emulating an actual client behaviour under different real-world scenarios.
I don't think he missed that point; he specifically limits his scope to HTTP daemons:
> A lot of people seem to be talking about and performing load tests on HTTP servers, perhaps because there’s a lot more choice of servers these days.
Testing web apps for performance is, as you point out, more difficult. There are tools for taking integration tests and running them in large batches. With some good instrumentation this is a kind of systemic profiling of your app architecture.
Perhaps I didn't phrase my comment as well as I should have. Indeed all his points apply and are excellent. As you pointed out, his focus is on testing the HTTP server for performance, rather than the actual apps running on them. The point I was trying to make is that all of the above, _plus_ additionally integration testing and app specific testing should really be done when preparing for the onslaught of a real-world deployment. Admittedly this is deliberately beyond the scope of his article.
The tools built into the more recent versions of Visual Studio (which I believe are different from the Web Application Stress tool) are quite good for modeling accurate load testing. Setting up specific scenarios that are each then segmented into percentages of the overall load test was super straightforward with the test suite tools.
problem with most load testing tools is the fact that you have to script through them. It's a PITA. Especially with PaaS and Heroku/EngineYard/Other-Vendors/-style deployments, time-to-deploy often obsoletes the time-to-script-test-cases. Need something different, agile and continuous.
To test a web app properly you need the ability to script and/or replay real-world session browsing behaviours, simulating typical interactions. This can be both very time consuming and difficult to set up but yields far more useful and realistic results. In the past I have reasonable success using tools like The Grinder (barely maintained and poorly documented, but very useful and scriptable in Python), and even Microsoft's Web Application Stress tool (scriptable in VB). There are probably better tools than these out there but these at least allow you to code a detailed interaction with you site.