Load testing before a traffic peak: a practical plan

Write down service level objectives before testing: for example p95 response time under 500 ms for API calls, under 2 s for reports and PDFs, and fewer than 0.5% errors. Then agree the expected peak, such as 2× today's busiest hour.

• Take a week of access logs and compute the share of each endpoint
• Measure think time between user actions
• Generate test data at production scale: tenants, customers, invoices
• Never point a load test at production without an agreed window

• Load: expected peak, held for 30 minutes or more
• Stress: ramp beyond the peak until it breaks, to see where and how
• Spike: a sudden jump in users within 30 seconds
• Soak: normal load for hours, to catch memory leaks and slow degradation

Watch application, database and infrastructure metrics during each run. The bottleneck is often not where people expect: a connection pool that is too small, one slow endpoint like PDF generation, a missing index, or autoscaling that reacts too slowly. Fix one thing at a time and re-run.

• Keep the scripts and thresholds in the repository
• Run a small load test nightly to catch performance regressions
• Re-run the full test after big releases and before the next peak

For a typical SaaS API, building the traffic model and scripts takes 2–3 days, running and analysing the tests another 2–3 days, and each fix-and-retest cycle a day. Start at least four weeks before the peak.