Putting together a viable stress test is not as simple a task as it would seem to be at a casual glance. The problems that one encounters can be subtle and often can only be clearly seen if one uses some not-so-simple mathematics to clarify things. But rather than watch your eyes glaze over in a complex exploration of Markov chains, state change models, queuing theory, probability distributions, etc., Kirk Pepperdine explores a less tedious, more hand-waving explanation that hopefully will shed some light on how to fix this common problem found in many stress tests.

Read Tuning Your Stress Test Harness

Hi Kerk,

Nice gentle introduction to software performance testing. I was wondering do you see many home grown testing solutions being used in the field? Are most of your assignments involving the configuration of commercial load tools?

You did not mention that impact of test (user transaction) case mixing in the article. Do you have any advice in this area? This seems to be another area were testing teams fail.

A nice outline of the overall steps involved in a good performance or stress assignment would be a good follow up.


All the best,


William Louth
JXInsight Product Architect
JInspired


"J2EE tuning, testing and tracing with JXInsight"
http://www.jinspired.com

Sorry Kirk,

I was looking out the window at time and the bit of Dutch I do know and speak came to the surface.

William

Hi Kerk,Nice gentle introduction to software performance testing. I was wondering do you see many home grown testing solutions being used in the field?

Actually no. I see quite a few people using Mercury LoadRunner. It's quite a good tool but it still requires one to understand the things that I put into the article in order for one to use it effectivily. I've seen teams make interesting customizations to LoadRunner which did end up causing some problems. In those cases, the customizations were wonderful ideas that just needed a bit of tuning.

 Are most of your assignments involving the configuration of commercial load tools?

Actually my assignments are an even split between reviewing architectures and performance tuning.

You did not mention that impact of test (user transaction) case mixing in the article. Do you have any advice in this area? This seems to be another area were testing teams fail.

I do cover this topic in my performance tuning courses. Maybe it's ripe for yet another article. The general advice is make it real!

Kirk

Thanks for the article, it made interesting reading, but I did get a little lost towards the end. It seemed to be saying that an increase in the average pause time was prefered, but the results showed that this was reducing the number of requests per second and that there is little value in increasing the number of threads?

Isn't it necessary to have staged tests where the load applied is increased in stages with the results recorded for each load, otherwise if you apply as much load as you can the total throughout will likely be less than the maximum and also the response times will be high, i.e. a convergent system. What you want is to do is push the system to see what is the limit of it being a steady state system

Dave

I also felt a little perplexed. I believe what you are saying is you are testing the actual thruput of the application, irregardless of load. If you need more thruput, then you tune the application until it performs better (e.g. lower response time), but having more threads does not tell you much other than you are overloading the server. Is that correct?