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 verify your system can absorb the spike without cascading failure, and — critically — that it recovers 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): intentionally short — 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 — 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: should jump steeply at the spike stage.
  • Latency (p95): will spike alongside VUs. Note the peak value — that is the degraded state.
  • Error rate: a well-sized system absorbs the spike with elevated latency but minimal 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. Sustained elevated latency post-spike indicates resource exhaustion (thread pools, connection pools, memory) that is 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 verify that a second spike after a recovery is handled 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: run the spike from a single region while baseline traffic continues from others using MaxoPerf’s multi-region support — see Multi-region distributed load.

Where to go next

Section titled “Where to go next”