| name | load-testing |
| description | 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. |
| license | Apache-2.0 |
| compatibility | Works with coding agents that support Agent Skills. |
| metadata | {"agentpacks.version":"0.1.0"} |
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
