Stop 10 · Performance TestingTopics · 2/8

Load, Stress & Spike Testing

In short

'Can it handle Diwali sale traffic?' is really three questions. Can it handle the expected crowd? Where does it break? And what happens when everyone arrives at 10:00 sharp?

Load testing verifies behavior under expected traffic; stress testing pushes beyond capacity to find the breaking point; spike testing checks how the system handles a sudden, dramatic traffic increase.

The purple blob sits behind a ticket window as a huge crowd rushes towards it at once.

Think of it like this

The Tatkal ticket window

On a normal day the booking window handles a steady line. Push more and more people in, and at some point the clerk can't cope. And at Tatkal opening, the whole crowd rushes in the same second. That's load, stress and spike.

Watch it happen

Four kinds of performance test

Perf tests

Load

Stress

Spike

Soak

Expected peak

Find breaking pt

Sudden jump

Hours, steady

1/5Same tools, different traffic shapes. Each answers a different question.

The big ideas

What you need to know

Load proves readiness

Run your expected peak traffic for a while and check it meets the agreed targets.

Stress finds limits

Push beyond normal on purpose. You want to see how it fails: slowly and politely, or with a crash.

Spikes test elasticity

Sales, results day, ticket openings. Can autoscaling and queues react fast enough?

Watch the recovery

After a spike or stress, the system should return to normal on its own.

See it in code

Walk through the code

1export const options = {2  stages: [3    { duration: "2m", target: 50 },    // normal traffic4    { duration: "30s", target: 1000 }, // sudden spike5    { duration: "1m", target: 1000 },  // hold the spike6    { duration: "30s", target: 50 },   // back to normal7    { duration: "2m", target: 50 },    // did it recover?8  ],9};

1/3Warm up with normal traffic so you have a baseline to compare against.

A spike profile in k6. Each stage ramps virtual users to the target over its duration.

Save yourself the pain

Common mistakes

Oops

Calling every performance test a 'load test'.

Do this instead

Name the type and the question it answers, so results are read correctly.

Oops

Stopping the test the moment errors appear in a stress test.

Do this instead

Note the breaking point, then watch how it degrades and recovers. That's the useful part.

Your mission

Sketch three traffic shapes

~20 min

Quick check

Results are announced at 10 am and traffic jumps tenfold within a minute. Which test fits best?

Go deeper

1Design a load test plan specifying expected concurrent users for a hypothetical system.
2Learn the specific goal each test type answers, since they're often confused with each other.
3Understand why stress testing intentionally aims to break the system, unlike load testing.