Q16 of 22 · Scenarios
How would you test for performance on a high-traffic page?
ScenariosSeniorscenarioperformanceload-testingstress-testingnon-functional
Short answer
Short answer: Clarify SLAs, expected concurrent users, caching strategy, and whether auto-scaling is in scope. Then run load, stress, spike, and soak tests; identify bottlenecks in DB queries, CDN caching, and N+1 patterns.
Detail
Clarify first
- What are the SLAs — acceptable p95/p99 response time and maximum error rate?
- What is the expected peak concurrent user count, and is there a historical baseline to validate against?
- Is the page cached (CDN, Redis) or fully dynamic (DB-backed on every request)?
- Is auto-scaling configured, and does the test need to validate scale-out behavior?
Functional baseline
- Page loads correctly at 1 user with no JS errors — confirm there is no pre-existing functional defect before adding load
Load test
- Ramp to expected concurrent users gradually; measure p50, p95, p99 response times at peak
- Identify the point where response times degrade (the knee of the curve)
- Confirm error rate stays within SLA at expected load
Stress test
- Drive beyond expected peak to find the breaking point
- Confirm the system degrades gracefully (timeouts and error responses, not silent hangs or data corruption)
Spike test
- Sudden burst to 10× normal traffic (flash sale scenario)
- Confirm auto-scaling (if applicable) activates within SLA; measure cold-start latency
Soak test
- Sustained load over several hours to detect memory leaks, connection pool exhaustion, or log file growth
Bottleneck identification
- Slow DB queries: run EXPLAIN ANALYZE on queries triggered during the load test
- N+1 queries: check APM for query counts per request rising with data volume
- Missing cache headers: verify CDN caches static assets and API responses where expected
- Unoptimised images: check bundle size and image dimensions in the load profile
Close: automate the load/stress/spike/soak scripts using k6, JMeter, or Gatling. Use APM (Datadog, New Relic, Grafana) for manual bottleneck analysis during the test run — dashboards reveal what assertion scripts cannot.
// WHAT INTERVIEWERS LOOK FOR
All four test types (load, stress, spike, soak) with distinct goals. N+1 query detection and CDN cache validation as bottleneck diagnostics. APM for manual analysis alongside automated scripts.
// COMMON PITFALL
Treating performance testing as a single load test. Missing soak (memory leaks), spike (auto-scaling), and the bottleneck identification step — the test just proves there's a problem; diagnosis requires deeper investigation.