Skip to content
MaxoPerf MaxoPerf docs

Spike and recover

import { Steps, Aside } from ‘@astrojs/starlight/components’;

Problem: Traffic spikes are rarely gradual. A flash sale, a breaking news story, or a viral post can send requests from baseline to 10× normal in under a minute. You want to confirm that your system absorbs the spike without cascading failure. Just as important, it must recover fully once the spike passes.

Test type: Spike test.

Prerequisites

Section titled “Prerequisites”
  • A MaxoPerf account and a test file ready to upload.
  • A known baseline VU/RPS level for your system (from a prior load test or staged ramp).

Step by step in MaxoPerf

Section titled “Step by step in MaxoPerf”

1. Write the spike scenario

Section titled “1. Write the spike scenario”
execution:
  - scenario: spike-checkout
    stages:
      # Baseline — confirm system is healthy before the spike
      - duration: 3m
        target: 50
      # Spike — near-instant ramp to 10× baseline
      - duration: 30s
        target: 500
      # Hold at spike level briefly
      - duration: 2m
        target: 500
      # Recover — ramp back down
      - duration: 30s
        target: 50
      # Post-spike baseline — verify recovery
      - duration: 5m
        target: 50


scenarios:
  spike-checkout:
    requests:
      - label: GET /home
        url: https://app.example.com/
        method: GET
      - label: POST /cart/add
        url: https://app.example.com/cart/add
        method: POST
        headers:
          Content-Type: application/json
        body: '{"product_id": "sku-flash-sale"}'

Key parameters:

  • Spike ramp duration (30s): short on purpose, because real spikes are fast.
  • Spike hold (2m): long enough to see sustained degradation, short enough to recover within the test window.
  • Post-spike hold (5m): the recovery period. This is the most important part of the test.

2. Create the test and upload the file

Section titled “2. Create the test and upload the file”
  1. Go to Tests → New test in the MaxoPerf console.
  2. Upload the YAML as the entrypoint.
  3. Choose a location close to your staging environment.
  4. Click Run now.

3. Watch the spike and recovery in real time

Section titled “3. Watch the spike and recovery in real time”

During the run, keep the Overview tab open and observe:

  • VU chart: jumps steeply at the spike stage.
  • Latency (p95): spikes along with VUs. Note the peak value. That is the degraded state.
  • Error rate: a well-sized system absorbs the spike with higher latency but few errors. If errors spike too, the system is over capacity.
  • Recovery: after the VU count returns to baseline, latency should return to pre-spike levels within 30–60 seconds. If latency stays high after the spike, some resource (thread pools, connection pools, memory) is exhausted and not recovering cleanly.

Verify

Section titled “Verify”
  • During the spike: latency increases. Errors may appear briefly. This is expected at high load.
  • After ramp-down to baseline (post-spike hold):
    • p95 latency returns to within 10–20 % of the pre-spike baseline.
    • Error rate returns to near zero.
    • Throughput (RPS) tracks the VU count (not lagging behind it).
  • If the system does not recover, file a finding for the engineering team. The spike test has done its job.

Variations

Section titled “Variations”
  • Steeper spike: use a 10-second ramp-up for an even more abrupt burst.
  • Multiple spikes: repeat the spike pattern twice to check that the system handles a second spike after recovery as well as the first.
  • RPS-based spike: replace VU targets with throughput values to model a request-rate spike instead of a connection spike.
  • Location-specific spike: with MaxoPerf’s multi-region support, run the spike from a single region while baseline traffic continues from the others. See Multi-region distributed load.

Where to go next

Section titled “Where to go next”