We all know how critical load testing is to a successful development effort … underestimate the possible success of your site, and you may have sabotaged that very success! If you are looking into simulated virtual user load testing for the thorough, comprehensive analysis it can offer developers, here we have some tips and tricks to make the process easier and faster.

Recognize that some questions cannot be answered

What every client wants to know, is whether their site can handle 10, 20, 50, or 400 users simultaneously (if they even recognize that there is an inbuilt load limit!). Unfortunately, this question resides in the realms of 'If a processor fails within the computing environment and nobody is sitting at the computer at the time, did it ever really fail?'! The question actually contains far too many variables to answer accurately, from user think-time to popular areas of the site and even into user's own computing environments. Approximations can certainly be made - as long as the client and team are aware of the precision limitations in performance testing.

Redefine your testing strategy according to non-standard questions

Seeking to answer the question 'Can my system handle 500 concurrent users?' requires several assumptions - and the answer you get will only be as accurate as your assumptions were. If you first seek to define the bottleneck, and then look at how many requests that tightest part of the system can handle concurrently, you will get a much more accurate picture of how the load is being handled. Make sure you check that the results scale linearly as more hardware is added, and check for stability issues as well.

Ensure you use circular test case scripts

Putting the system into the same state before and after each testing event. If you do this, you'll be able to repeatedly run your test cases over extended periods, with stable results.

Ensure you account for super users

In your performance engineering equation for calculating approximate load capacity, define a worst-case scenario (or best case, depending on who you are!), by utilising super-users in your testing. A super-user is highly familiar with the site and has a think time of next to zero in the real world. For the purposes of testing and finding limits, set the think time to zero and then scale up from there.

Know which metrics to pay attention to

The system:processor queue length is the critical metric that points to a bottleneck. Other metrics that an be used to uncover bottlenecks include the Active server pages:Requests per second ratio (where if the active counter is low during traffic spikes, there is a bottleneck), and the processor: % processor time ration (if the network adapter card and disk I/O are below capacity while this ratio is high).