Performance Testing — Load, Stress & Benchmarks
Performance bugs don't show up in functional tests. They show up when 10,000 users arrive at once. Here's how to test for load, stress, and durability before your users do.
Functional testing asks: does it work? Performance testing asks: does it work under pressure? Both matter. Only one is usually skipped.
Performance bugs are the silent killers of good products. The app works beautifully in dev with 10 users. Then marketing drives 10,000 users, and the site crashes.
The three types of performance testing
Load testing — Simulates expected peak traffic. Confirms the system handles it without degradation.
Stress testing — Pushes beyond expected peak to find the breaking point.
Soak testing — Runs moderate traffic for hours/days to find leaks and slow failures.
Metrics that actually matter
Throughput — Requests per second
Response time (P50, P95, P99) — Not averages
Error rate — % of requests that fail under load
Concurrency — Simultaneous users handled
Resource usage — CPU, memory, DB connections at load
Recovery time — Return to baseline after traffic drops
Skip "average response time" — it hides the P99 experience.
Tooling
k6 — Modern, developer-friendly. Our recommendation for most teams.
JMeter — Mature, feature-rich. Steeper learning curve.
Lighthouse — Frontend performance (different category).
Locust — Python-based.
Gatling — Scala-based.
How to run performance tests
- Define your target: expected peak traffic + response time SLO
- Build realistic scenarios (full user journeys, not single endpoints)
- Baseline at low traffic
- Load test at expected peak
- Stress test beyond peak
- Soak test for durability
- Monitor everything
What we typically find
- Database queries that scale linearly
- Missing indexes causing slow queries
- Connection pool exhaustion
- Memory leaks that surface after hours
- Third-party APIs that throttle unexpectedly
- N+1 query patterns in ORMs
None of these show up in functional testing.
When to run performance tests
Before major launches — Non-negotiable
- After infrastructure changes
- After scaling milestones
- Continuously in production (synthetic monitoring)
Common mistakes
- Testing single endpoints instead of full journeys
- Skipping soak testing
- Not testing from realistic locations
- Ignoring third-party API limits
- Testing in dev instead of production-like environments
Key takeaways
- Load, stress, and soak testing are all required
- Track P95 and P99, not averages
- k6 is the best starting point for most teams
- Test full user journeys, not single endpoints
- Run before launches, after infra changes, and continuously
Further reading
About the author
Senior QA Engineer →Senior QA Engineer · Quality Assurance Labs
