What is Spike Testing?

What is spike testing?

Spike testing is a performance test that hits a system with a sudden, very large jump in load and then drops it again, to see whether the system survives the surge and how quickly it recovers. Unlike a ramped load test there is little or no plateau: the rise is steep, and the result is judged on what happens during and after the burst.

For a longer walkthrough of designing a spike test and reading its result, see spike testing in performance testing on the LoadFocus blog.

Spike testing vs load testing and stress testing

A load test ramps users up and holds them at the level you expect on a busy day. A stress test pushes past that level to find where the system breaks (see load testing vs stress testing). A spike test is defined by its shape: normal traffic, a near-instant jump to a very high level, a short hold, then back to normal. The questions it answers are different:

• Load test: does the system meet its targets at expected peak?
• Spike test: what happens when traffic multiplies in seconds? Does scaling react in time, and does the system return to normal afterwards or stay degraded?

The maximum steady load a system can carry is a separate question, covered by capacity testing.

How a spike test works

1. Baseline. Run realistic traffic for a few minutes so caches, connection pools and autoscalers are in their normal state.
2. Spike. Raise the number of virtual users (or the request rate) to the target within seconds, not minutes.
3. Short hold. Keep the peak for a minute or two. Many real spikes are brief.
4. Drop and observe. Return to baseline and keep the test running long enough to see whether response times and errors recover.

Example (illustrative numbers): an online shop sends a push notification at 10:00. Normal traffic is 50 concurrent users. The test jumps to 1,000 virtual users in 10 seconds, holds for 2 minutes, drops back to 50 and runs 5 more minutes. Grafana's k6 guide uses a similar shape: a 2 minute climb to 2,000 users, no plateau, then a 1 minute drop to zero.

Serverless back ends are a good reason to run one. For AWS Lambda, the documentation gives a default of 1,000 concurrent executions per Region and a scaling rate of 1,000 new execution environments every 10 seconds per function, so a burst can outrun the scaler and be throttled. See serverless function for the details.

What to measure

• Error rate during the spike. Some errors are expected; what matters is which ones (timeouts, 429, 502, 503) and whether they stop when the spike ends.
• Response time percentiles. Look at p95 and p99, not the average. See latency.
• Time to recover. Seconds from the end of the spike until response times and errors are back to baseline.
• Back-end behaviour. Autoscaler events, CPU, database connections and queue depth. Without back-end monitoring you see the symptom but not the cause.

Common mistakes

• Ramping too slowly. A 10 minute ramp is a load test. The point is that scaling has no time to prepare.
• Stopping when the spike ends. Sticky failures (exhausted connection pools, crashed workers that did not restart) only show up in the recovery phase.
• One source, one URL. Real surges come from many places and hit several endpoints. Vary the journey and the origin.
• Warm caches. A cache or CDN that is already full hides what a cold start of the event would do.
• Expecting a clean pass. Errors under a spike are common. Run, tune and repeat until the failure mode is one you accept.

Running a spike test with LoadFocus

On LoadFocus load testing you can set the number of virtual users, duration and ramp-up for a JMeter test plan, or use k6 scenarios with executors such as ramping-vus, and run them from several of the 25 cloud regions at once. Paid plans go up to 20,000 concurrent virtual users per test. The Free plan is limited to 10 virtual users and 60 seconds, which is enough to check a script and its shape but not to create a real surge.

FAQ

How is a spike test different from a stress test?

A stress test keeps increasing load to find the breaking point. A spike test applies one sudden jump and checks survival and recovery. Stress asks how much; spike asks how fast.

How long should a spike test run?

The spike itself is often one to a few minutes. Add a baseline before it and a recovery period after it, so a typical run is 10 to 20 minutes in total.

Do I need autoscaling to run a spike test?

No. Without autoscaling the test shows how much headroom fixed capacity has. With autoscaling it also shows whether new capacity arrives before users are affected.

Should I run a spike test in production?

Prefer a staging environment sized like production. If you must test production, agree a time window, start small and make sure someone is watching the back end.