Skip to content
MaxoPerf MaxoPerf docs

Spike test

A spike test simulates a sudden, dramatic increase in traffic — the kind that happens when a marketing email goes out, a product is featured on a high-traffic site, or a flash sale opens. Unlike a stress test (which ramps gradually), a spike test jumps to a very high load almost instantly and then measures how the system behaves during the surge and — crucially — whether it recovers cleanly afterward.

Before you start

Section titled “Before you start”
  • A load test has already established your baseline behaviour at expected peak load.
  • Stakeholders have been informed that a spike run may cause elevated errors or temporary unavailability on the target system.
  • Run against staging, not production.

What is a spike test?

Section titled “What is a spike test?”

A spike test has a distinctive shape:

  1. Low baseline — a short period at normal load (e.g., 10 VUs for 1 min) to establish a clean starting point.
  2. Instant surge — a near-instantaneous ramp to a very high VU count (e.g., 500 VUs in under 30 seconds) simulating a flash-traffic event.
  3. Brief hold — hold at the spike peak long enough for autoscaling or circuit breakers to respond (1–3 min).
  4. Drop and recovery — traffic returns to baseline; observe whether the system recovers or continues to show errors.

The questions a spike test answers:

  • Does the system stay alive (no 5xx cascade) during the surge?
  • If errors occur, do they stop once traffic drops back?
  • How long does recovery take?

How to run a spike test in MaxoPerf

Section titled “How to run a spike test in MaxoPerf”

Load profile

Section titled “Load profile”
ParameterValue
Baseline VUs10–20 (1 min)
Spike VUs500–1000 (5×–20× normal)
Ramp to spike10–30 s (very fast)
Hold at spike1–3 min
Recovery ramp-downBack to baseline in 30 s
Total duration~8–10 min

Console walk-through

Section titled “Console walk-through”

  1. Create a new test named api-spike based on the same scenario as your load test.

  2. For a spike profile in Taurus, use a stages configuration:

    execution:
      - executor: jmeter
        concurrency:
          - const: 10
            duration: 1m
          - const: 500
            duration: 3m
          - const: 10
            duration: 2m
        scenario: api-spike
    

    scenarios:
      api-spike:
        requests:
          - url: https://api.staging.example.com/v1/products
            label: list-products

    This holds 10 VUs for 1 minute, jumps to 500 VUs for 3 minutes, then drops back to 10 VUs for a 2-minute recovery observation window.

  3. In Load profile, use the duration stop mode and set Duration to the total scenario length (6m).

  4. Select the same location(s) as your load test.

  5. Click Run and monitor the live Overview tab — the VU surge and its effect on latency should be visible in real time.

How to read the result

Section titled “How to read the result”

Open the Overview tab after the run:

  • Throughput — should spike with the VU surge. A flat throughput despite rising VUs means the system is queuing requests internally.
  • p95 latency — watch for the spike coinciding with the VU surge. A sharp climb that quickly recovers after VU drop-off shows a resilient system.
  • Error rate — errors during the surge are expected if the system auto-scales; errors that persist after the VU drop-off indicate a slow or failed recovery.
  • Runners tab — confirm all runners were in running state during the surge; runner failures during a spike run make the result unreliable.

If the error rate remains elevated after the VU count drops back to baseline, the system has not recovered — investigate connection pool exhaustion, circuit breaker state, or downstream service backpressure.

Do / don’t

Section titled “Do / don’t”
DoDon’t
Include a recovery window after the spike (2 min minimum)End the run immediately after the spike peak — you miss the recovery data
Compare the spike result against the load-test baselineSpike a system that has not passed a load test first
Watch for slow recovery (errors persisting post-spike)Conclude the system “passed” just because it survived the spike
Alert ops before running on shared infrastructureSpike production without a maintenance window

Where to go next

Section titled “Where to go next”