On HTTP Load Testing

Post by spydum » Wed, May 18, 2011, 12:44 PM UTC

troels wrote: post #8

Locke1689 wrote: post #5

The author makes this point, but in my opinion not strong enough. While it’s tempting to say that the way to achieve this is to run everything on VMs, I’m not convinced that adding another layer of abstraction (as well as more processes running on the host OS) is going to lead to more consistent results. Because of this, dedicated hardware is best. Failing that, just run all of the tests you can in one session, and m…

Did you mean to not use a VM for the test client, or did you mean that testing performance of a VM is tricky?

I'm sure he meant testing performance of a VM is tricky, but in actual fact, both are true. Using a VM for the test client is just as susceptible to the issues mentioned as running it as the server. As the article suggests: know your load generator client. This is difficult if it's not consistent.

Post by kowsik » Thu, May 19, 2011, 7:08 AM UTC

silon wrote: post #10

morganpyne wrote: post #2

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…

I found that Apache jmeter works well for me. Easier to use than Grinder, but much more useful than the MS tool.

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.

Re: On HTTP Load Testing

Re: On HTTP Load Testing