# Load Testing

> Design and run load, stress, and soak tests to validate system performance under realistic and peak traffic. Use before major releases, after architecture changes, or when setting SLOs.

- Skill: `agent-packs/load-testing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add agent-packs/load-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/agent-packs/load-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: agent-packs (https://skillmd.com/u/agent-packs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/agent-packs/load-testing

---


# Load Testing

Load tests are experiments, not one-time checks. Define a hypothesis, measure, and iterate.

## Test Design

- Test against production-like infrastructure, not a scaled-down staging environment. Results from smaller environments don't transfer.
- Use realistic request distributions from production access logs — not uniform random traffic. 80% reads / 20% writes is a different test than 50/50.
- Warm up the system before measuring: send traffic at 10% of target load for 2–5 minutes before ramping to full load.
- Include think time between requests (1–5 seconds per virtual user) to match browser and API client behavior.
- Script tests at the scenario level: login, browse, add-to-cart, checkout — not individual endpoints in isolation.

## Test Types

- **Load test** — ramp to expected peak, hold for 10–30 minutes, observe steady-state behavior. Goal: confirm SLO compliance under normal load.
- **Stress test** — increase load beyond peak until the system degrades or fails. Goal: identify the breaking point and failure mode.
- **Soak test** — run at sustained normal load for 8–24 hours. Goal: catch memory leaks, connection pool exhaustion, log fill, and gradual degradation.
- **Spike test** — sudden 5–10× traffic increase over 30–60 seconds. Goal: verify auto-scaling reacts in time and the system recovers cleanly.

## Tooling

- **k6** — JavaScript-based, CI-friendly, outputs InfluxDB/Prometheus/CSV metrics natively.
- **Locust** — Python, distributed, good for complex user journeys.
- **Gatling** — Scala/DSL, high throughput, HTML reports.
- **Artillery** — YAML/JS, good for HTTP and WebSocket.

Pick one tool per project and commit to it — mixing tools makes trend comparison impossible.

## Metrics and Assertions

- Assert on p95 and p99 latency, not just average. Averages hide tail latency.
- Assert on error rate: `error_rate < 0.1%` under load test, `error_rate < 1%` under stress test.
- Capture throughput (requests/second), active virtual users, and saturation signals (CPU, connection pool usage).
- Export raw metrics to a time-series store (InfluxDB, Prometheus) so you can overlay with deployment markers.

## CI Integration

- Run a smoke load test (2–5 minutes, 10% of peak) in CI on every merge to main.
- Run full load tests in a pre-production environment before production deploys.
- Gate deploys on load test results — a 30% p99 latency regression should block release.
- Store test results and baselines in version control or a metrics store. Regression is meaningless without a baseline.

## Checklist

- [ ] Test runs against production-like infrastructure.
- [ ] Realistic traffic distribution derived from production logs.
- [ ] p95 and p99 assertions defined, not just averages.
- [ ] At least: load test, soak test, and spike test scenarios defined.
- [ ] Metrics exported to a time-series backend.
- [ ] Baseline results committed and compared on each run.