Load Test Before Launch

Define realistic scenarios, measure baseline and peak behavior, identify saturation points, and decide capacity with evidence instead of guesses.

intermediate~60 minperformancetestingcapacity

Objective

Determine whether a release meets its latency and error SLOs at expected peak traffic and identify the first bottleneck before users find it.

Environment

A load-testing tool such as k6 or Artillery
A staging environment with production-like data and configuration
Metrics for latency, error rate, CPU, memory, and dependency saturation
A defined traffic model and SLO

Steps

1. Model real traffic

Identify the critical user journeys, their request mix, payload sizes, and expected peak requests per second. Include think time and authentication.

Expected state: A scenario file represents realistic behavior, not a single endpoint hammered uniformly.

2. Measure a baseline

Run a low-load test to confirm correctness and collect baseline latency and resource usage.

Expected state: The system is healthy at baseline and the test itself is not the bottleneck.

3. Ramp to peak and beyond

Increase load in stages to expected peak, then beyond it to find the saturation point. Watch error rate, p95/p99 latency, and dependency limits.

Expected state: The first bottleneck is identified with evidence: CPU, memory, connection pool, database, or network.

4. Analyze and decide

Compare results with the SLO, fix the bottleneck or adjust capacity, and rerun the failing stage.

Expected state: A documented capacity decision with before/after measurements.

5. Test recovery

Drop load abruptly and confirm the system returns to baseline without lingering errors, queues, or leaked connections.

Expected state: Recovery behavior is measured, not assumed.

Decision points

Should the test target staging or production?

Production-like staging with isolated data
Production with synthetic traffic

Prefer isolated staging; use production only with strict safeguards, synthetic identities, and the ability to stop immediately.

What is the pass criterion?

SLO met at expected peak with defined headroom
No errors during the test

Use SLO plus headroom; zero errors at low load does not prove capacity.

Expected outcome

Evidence that the release meets its SLO at expected peak, a known saturation point, and a prioritized list of bottlenecks and capacity actions.

Verification

Confirm p95/p99 latency and error rate stay within the SLO at expected peak, the saturation point is above peak with headroom, and recovery returns metrics to baseline within a defined window.

Cleanup

Destroy test data and load generators, reset staging configuration, and archive results with the release record.

Model before you measure

A load test that hits one endpoint with uniform requests produces a number, not a capacity answer. Model the journeys users actually perform, with realistic payloads, think time, and authentication.

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const res = http.get('https://staging.example.com/api/products');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Analyze

Compare p95/p99 latency and error rate with the SLO.
Correlate the first failure with resource saturation: CPU, memory, pool, database, or network.
Fix the bottleneck or add capacity, then rerun the failing stage.
Drop load and verify recovery.

Verification

The SLO is met at expected peak with documented headroom.
The saturation point and first bottleneck are known.
Dependency limits, such as database connections, are respected.
Metrics return to baseline after load stops.
Results and the capacity decision are recorded with the release.

Pitfalls

Testing with production data without isolation, ignoring think time, and treating a single successful run as proof of capacity. Also test the failure path: what happens when a dependency is slow or unavailable under load.