Load Test Harness
Turn "will it scale?" into a measured answer. Arm of scale-readiness-review; use deterministic-test-harness for seeded data.
Quick Start
- Define the target: path, throughput, p95/p99 latency, error budget.
- Seed realistic data at scale; isolate the env.
- Pick an available load tool.
- Run baseline, then target load, then push to breaking point.
- Report percentiles and the first bottleneck -- not averages.
Choose the Tool
- HTTP APIs:
k6, vegeta, wrk, locust, or the language's lib.
- Workers/queues: enqueue a burst, measure drain rate.
- Database/query:
EXPLAIN ANALYZE plus a timed batch loop.
- Pure functions: benchmark framework (
go test -bench, pytest-benchmark).
Run the Right Profiles
- Baseline: low, steady load; healthy latency.
- Target: expected peak; confirm it meets the goal.
- Stress: ramp until it breaks; find the ceiling and first bottleneck.
- Soak: sustained load over time; catch leaks, pool exhaustion, drift.
Measure and Report
Report throughput vs target, latency p50/p95/p99, and error rate/types. Pair with observability-instrumentation metrics to see the first saturated resource (CPU, connections, pool, queue, locks).
Result: checkout endpoint, target 200 rps
Throughput: 210 rps sustained
Latency: p50 40ms, p95 180ms, p99 850ms
Errors: 0.2% (timeouts at peak)
Bottleneck: DB connection pool saturated at ~190 rps; p99 spikes follow pool waits.
Next: raise pool size / add read replica; re-run to confirm p99.
Guardrails
- Do not run load tests against production without approval, or on toy data -- small datasets hide real bottlenecks.
- Do not conclude from a single run, or optimize before the harness shows the bottleneck.
1---2name: load-test-harness3description: Builds repeatable load tests and benchmarks for hot paths, measuring latency, throughput, and failures under load. Use when validating a throughput/latency target, a scalability concern, or asked for a load/stress/soak test or benchmark.4---56# Load Test Harness78Turn "will it scale?" into a measured answer. Arm of `scale-readiness-review`; use `deterministic-test-harness` for seeded data.910## Quick Start11121. Define the target: path, throughput, p95/p99 latency, error budget.132. Seed realistic data at scale; isolate the env.143. Pick an available load tool.154. Run baseline, then target load, then push to breaking point.165. Report percentiles and the first bottleneck -- not averages.1718## Choose the Tool1920- HTTP APIs: `k6`, `vegeta`, `wrk`, `locust`, or the language's lib.21- Workers/queues: enqueue a burst, measure drain rate.22- Database/query: `EXPLAIN ANALYZE` plus a timed batch loop.23- Pure functions: benchmark framework (`go test -bench`, `pytest-benchmark`).2425## Run the Right Profiles2627- **Baseline**: low, steady load; healthy latency.28- **Target**: expected peak; confirm it meets the goal.29- **Stress**: ramp until it breaks; find the ceiling and first bottleneck.30- **Soak**: sustained load over time; catch leaks, pool exhaustion, drift.3132## Measure and Report3334Report throughput vs target, latency p50/p95/p99, and error rate/types. Pair with `observability-instrumentation` metrics to see the first saturated resource (CPU, connections, pool, queue, locks).3536```text37Result: checkout endpoint, target 200 rps38Throughput: 210 rps sustained39Latency: p50 40ms, p95 180ms, p99 850ms40Errors: 0.2% (timeouts at peak)41Bottleneck: DB connection pool saturated at ~190 rps; p99 spikes follow pool waits.42Next: raise pool size / add read replica; re-run to confirm p99.43```4445## Guardrails4647- Do not run load tests against production without approval, or on toy data -- small datasets hide real bottlenecks.48- Do not conclude from a single run, or optimize before the harness shows the bottleneck.
rockclaver