Load testing
What to check before load testing a release
A load test is useful only when it answers a business or engineering question. Before running one, make sure the setup can produce a decision instead of just charts.
Define the decision
Start with the release decision: can this version handle launch traffic, a campaign spike, or a known growth target? A target like "test performance" is too vague. A useful target sounds like "the checkout flow should sustain 600 orders per minute with p95 latency under 800 ms and no error-rate spike."
Model realistic traffic
Traffic shape matters more than raw virtual user count. Split the test into real flows: browse, login, search, checkout, background jobs, API clients, and admin traffic. Include think time, ramp-up, and the parts of the system that usually get skipped in demos.
Prepare observability first
Before the test starts, confirm that metrics, logs, traces, and business counters are visible. If the system slows down, you need to know whether the limit is database saturation, queue lag, external APIs, CPU, memory, lock contention, or an application-level bottleneck.
Use production-like data
Empty databases and tiny payloads hide real problems. Use data volume, account shapes, object counts, permissions, and payload sizes that resemble production. If you cannot copy production, generate data that has the same operational shape.
Leave time to fix
Run the first serious test early enough to change something. The output should be a short list: what failed, why it failed, what to fix now, what to monitor, and what can wait.