Spike Test
An important part of performance testing is designing a scenario which matches your test criteria. You will commonly hear the terms load, stress and soak test mentioned as the typical tests scenarios to perform. Each should be considered but it may not always make sense to perform just those tests. One test scenario that is less frequently considered is a Spike test.
A spike test simulates an extreme increment or decrement in load. It is used to understand the recovery time after the spike of load. Enabling us to understand the behaviour and any weakness in the application under test.
There is no exact setup for a spike test but in the examples below we have introduced a single spike half way through the test.
Loadrunner Controller
Under the controller we firstly add two scripts and assigned 10 vusers to one group and 40 vusers to the other group.
We then set the group with 10 vuser to ramp-up and run a constant load for 1 hour.
In the second group we delay the start of the execution until 30 minutes into the test. Then we simultaneously load all 40 vusers and for a short duration causing the spike.
The controller graph shows the spike with the purple line and the constant load is represented by the green line.
Apache JMeter
In JMeter we firstly add the Ultimate Thread group, which allows us to create a more complex scenario.
Then we add a row containing 100 threads with a gradual ramp-up and set the test to run for a duration of 1 hour creating a constant load.
The second row contains a 100 threads but this time with a start time of 30 minutes into the scenario. Again running for a short duration causing the spike.
The graph shows the combined view of load across the two rows of threads. The spike is visible half way through the test when the additional threads are added to the threads executing the constant load.
Monitoring
As with all performance testing, we need to monitor the application and infrastructure under test. Using this scenario as an example, we have allowed a steady state period of time to see the system under load before introducing a spike (and after). In this way we can be sure we understand how the system was behaving and then understand how it recovers post the spike. Try not to introduce additional spikes until you are sure that the recovery has been achieved.
Guru99.com provides some great reading around Spike testing and types of performance test types which can be seen on the links below.