Well, if we take a look at normal expected utilization and maximum design capacity, then our tests are going to fall somewhere in between those.
- a stress test is where we escalate the amount of load over time until we find the limits of the system.
- a load test is where we understand the business requirements very well and can ramp up the load, leaving it running at a plateau until we’re happy that the performance is not continuing to degrade and then ramp down on the load.
And what we’re looking for in that plateau is an equilibrium. We’re looking for CPU levels to stay the same. Response times to stay the same. Memory levels to stay the same.
- a soak test would be something that we’d run over a weekend or over 24-hour period and we would be looking generally for things like memory leaks
- a spike test where we go over and above the maximum design capacity, just to see how the application can deal with a big spiking load. Generally, what you’ll find will be a ripple effect but what we’re looking for is for the application not to fall over.
These days with fast broadband networks people don’t wait much more than around five seconds to get a response for their page. In fact, this is what we would call the knee in the curve. That when you get a linear degradation, until you get to point where response time is really not good enough. In fact, this quite is a steep knee.
Next Basis of performance engineering