Load tests simulate expected traffic. Stress tests find the ceiling. But what about sudden traffic bursts? Your marketing team sends a push notification to 500,000 users at 10:00 AM: "Flash sale! 70% off laptops for the next 30 minutes!" Within 60 seconds, your traffic goes from 50 concurrent users to 300. That is a spike, and it is the most realistic failure scenario for e-commerce applications.
Spike tests answer a different question than stress tests. Stress tests ask "how much can you handle?" Spike tests ask "how fast can you react to a sudden surge?" The difference matters because many systems can handle 300 users if they arrive gradually over 5 minutes, but crash if the same 300 users arrive in 30 seconds. Connection pools, thread pools, and auto-scaling mechanisms need time to respond.
A spike test has three phases: the calm before the storm, the storm itself, and the aftermath. We want to see how the system behaves in all three.
<!-- Use the Ultimate Thread Group plugin for precise spike control -->
<!-- Install via JMeter Plugins Manager: jpgc - Standard Set -->
<!--
Spike Profile:
Phase 1: 50 users for 60 seconds (normal traffic)
Phase 2: Ramp to 300 users in 10 seconds (the spike)
Phase 3: Hold 300 users for 120 seconds (sustained spike)
Phase 4: Drop back to 50 users in 10 seconds (traffic subsides)
Phase 5: 50 users for 60 seconds (recovery observation)
-->
<!-- If not using the plugin, simulate with multiple Thread Groups: -->
<!-- Thread Group 1: Base Load (always running) -->
<ThreadGroup testname="Base Load - 50 Users">
<intProp name="ThreadGroup.num_threads">50</intProp>
<intProp name="ThreadGroup.ramp_time">10</intProp>
<boolProp name="ThreadGroup.scheduler">true</boolProp>
<stringProp name="ThreadGroup.duration">300</stringProp>
<stringProp name="ThreadGroup.delay">0</stringProp>
</ThreadGroup>
<!-- Thread Group 2: Spike Load (delayed start) -->
<ThreadGroup testname="Spike Load - 250 Users">
<intProp name="ThreadGroup.num_threads">250</intProp>
<intProp name="ThreadGroup.ramp_time">10</intProp>
<boolProp name="ThreadGroup.scheduler">true</boolProp>
<stringProp name="ThreadGroup.duration">120</stringProp>
<stringProp name="ThreadGroup.delay">60</stringProp>
<!-- Starts at T+60s, 250 users arrive in 10 seconds -->
<!-- Total concurrent at peak: 50 + 250 = 300 users -->
</ThreadGroup>| Phase | What to Check | Good Result | Bad Result |
|---|---|---|---|
| Pre-spike (T+0 to T+60) | Baseline behavior at 50 users | Stable, fast, 0% errors | Already stressed at baseline -- fix before spike testing |
| Spike arrival (T+60 to T+70) | Response time during ramp | Response times increase but no errors | Immediate errors, connection refused, timeouts |
| Spike sustained (T+70 to T+180) | Behavior under sustained spike | System stabilizes at higher response times | Errors keep climbing, system never stabilizes |
| Spike end (T+180 to T+190) | How fast system recovers | Response times drop back to pre-spike within 30s | Response times stay high -- system is stuck |
| Post-spike (T+190 to T+300) | Recovery completeness | Metrics return to pre-spike baseline | Elevated response times or errors persist -- resource leak |
The recovery phase is the most revealing part of a spike test. A healthy system bounces back to baseline within seconds after the spike ends. An unhealthy system stays degraded because something got "stuck" -- exhausted connection pool, full garbage collection cycles, accumulated database locks. If your system does not recover after the spike, you have a serious resilience problem.
If the Ultimate Thread Group plugin is not available, you can simulate spikes using multiple Thread Groups with different delays and durations as shown in the code above. The key is having one thread group for base load (runs the entire time) and another for spike load (starts later, runs briefly, then stops).
Q: What is the difference between a load test, stress test, and spike test? When would you use each?
A: A load test simulates expected peak traffic to verify the system meets SLAs under normal production conditions -- you use it to confirm readiness for go-live. A stress test gradually increases load beyond expected peak to find the breaking point -- you use it to determine the system's maximum capacity and plan for growth. A spike test simulates a sudden traffic burst (like a flash sale or viral event) to test how the system handles rapid scaling and whether it recovers afterward -- you use it to validate resilience and auto-scaling behavior. The key difference is in the load profile: load tests have gradual ramp-up to a target, stress tests continuously increase past the target, and spike tests have a dramatic sudden increase followed by a return to normal. I typically run all three in sequence: load test to validate SLAs, stress test to find limits, spike test to verify resilience.
Key Point: Spike tests simulate sudden traffic bursts. The most important metric is recovery -- does the system return to baseline after the spike ends? If it does not recover, you have a resilience problem.
Key Point: Spike tests reveal resilience. A healthy system handles sudden traffic bursts and recovers quickly. A fragile system stays degraded even after traffic returns to normal.