When designing a set of performance tests it is necessary to consider pauses between user interactions. This is usually referred to as “think time”, and represents the time between the system presenting the results of an action and the next action being taken. If a load test script doesn’t include any think time at all then the system will be bombarded with requests at a rate that isn’t humanly possible. Depending on the system there are likely to be between 10 and 100 times the interactions generated with zero think time than with realistic scenarios.
When creating test scripts via “record and playback”, however, the tool will usually record page delays and play them back during the script run – and so the problem is solved. Isn’t it?
There are two issues that must be considered here. The first follows on naturally from the comment above: If the recorded wait time is not realistic then the resultant loading will not be realistic, and so the test will be better but still not correct. This could be fixed by simply using a user who is likely to have realistic waits – assuming you can identify such a user and make them available for the testing. I can be surprising just how long real users do spend on think time.
The next issue is more important, and harder to understand. For illustration let us assume we have 10 users with a 5s think time. Let us further assume that requests usually take 0.1s to process, and that simulated users are started 0.5s apart. In normal operation these requests will never coincide. This could be an issue in itself, but this isn’t the worst of it.
Let us now presume there is a problem – a temporary server issue would be sufficient – that causes all of the responses to arrive back at the client at the same time. It does happen in load testing for various reasons. Now all of the scripts will wait 5s and send the next requests at exactly the same time. The message loading on the server suddenly goes up dramatically, and is likely to continue in this pattern for some time. The result is that the system doesn’t seem to be able to cope with even 10 users in realistic conditions.
The solution is to introduce a level of randomisation in think time delays. It is then possible to introduce an appropriate statistical think time profile – and to break up bursts. The cost is extra test script development time, but the benefit is much more realistic testing.
If you would like advice, or to discuss how to decide on the most appropriate way to set up load testing in your circumstances then please feel free to contact me at dh@sarquol.com, or call on +44 7887 536083.
Sarquol Ltd 