Load testing
What to check before load testing a release
A load test is useful only when it answers an engineering decision instead of merely producing charts.
Define the decision
Start with the release decision: can this version handle launch traffic, a campaign spike, or a known growth target? A useful target names the operation, load, latency, and error boundary.
Model realistic traffic
Split the test into real flows and preserve their order, pacing, and data shape. Raw virtual-user count is not a workload profile.
Prepare observability first
Confirm metrics, logs, and business counters before load starts. When the system slows down, evidence must separate application, database, queue, and dependency limits.
Use production-shaped data
Tiny payloads and empty databases hide problems. Generate the object counts, permissions, payload sizes, and access patterns that influence the target operations.
Leave time to fix
Run the first serious test early enough to change something. The result should name what failed, why, what to fix now, and what evidence supports the decision.