Load, Stress, Soak, Spike: Choosing the Right Performance Test
The four performance test types answer four different questions. A practical guide to when to run each one, and what a passing result actually tells you.
“Run a performance test” is ambiguous — there are four common shapes, and each answers a completely different question. Running the wrong one gives you a green result that proves nothing about the risk you actually care about.
Load = “does it hold up at expected traffic?” · Stress = “where does it break?” · Soak = “does it survive over time?” · Spike = “can it handle a sudden surge?” Pick by the question you need answered.
Load test — the expected day
A load test holds a realistic, expected level of traffic and checks that response times and error rates stay within SLA. This is your regression baseline — the test you run on every release.
- Ramp to expected peak concurrency, hold, then ramp down
- Assert p95/p99 latency and error rate against SLAs
- Answers: is production-normal traffic safe to ship?
Stress test — find the cliff
A stress test deliberately pushes past expected load until the system degrades or fails. The goal is not to pass — it is to learn where and how it breaks.
The valuable output of a stress test is the failure mode. Does it slow down gracefully, shed load, and recover — or does it fall over and stay down? Graceful degradation is a feature you can only verify by breaking things on purpose.
- Ramp load up until latency spikes or errors climb
- Note the breaking point and how it fails
- Answers: how much headroom do we have, and what happens at the limit?
Soak test — the slow leak
A soak (or endurance) test holds a moderate load for a long time — hours, sometimes days. It catches the problems that only appear with time and accumulation.
- Memory leaks that grow until the process dies
- Connection or file-handle exhaustion
- Log/disk fill-up, cache unbounded growth
- Answers: will it still be healthy after running all week?
A system can pass every short test and still fall over at 3 a.m. on day three. Only a soak test finds that.
Spike test — the sudden surge
A spike test throws a sudden, sharp jump in traffic at the system — a flash sale, a viral moment, a cron job stampede — then watches recovery.
- Jump from baseline to many times the load almost instantly
- Watch whether it absorbs, queues, or crashes — and how fast it recovers
- Answers: can it survive a surge and return to normal?
Choosing quickly
When you are not sure which to run, match the test to the fear:
- Worried about a normal busy day? → Load
- Need to know your ceiling and failure mode? → Stress
- Worried about leaks / long-running stability? → Soak
- Expecting a launch, sale, or traffic burst? → Spike
The takeaway
These are not competing tests — they are four lenses on the same system. Mature teams run load tests continuously in CI, and reach for stress, soak, and spike tests around capacity planning and big launches. A green load test is necessary, but it is not the same as “we are ready for anything.”