What Is Load Testing? | Vantage
Load Testing Load testing is the practice of simulating user traffic and usage patterns against a system to verify it can handle expected load and to identify performance bottlenecks before they affect production users. Load testing encompasses several related practices: load testing (expected production volume), stress testing (beyond expected volume to find breaking points), spike testing (sudden traffic increases), soak testing (sustained load over time to find memory leaks), and volume testing (large data quantities). Tools like k6, Locust, Gatling, and Apache JMeter are used to generate synthetic traffic.
Why load testing matters
Systems that work correctly for one user may fail or degrade significantly under production load. Database queries with O(n) complexity, connection pool exhaustion, memory leaks, and unbounded queue depths only surface under load. Discovering these in production — at 2am during a traffic spike — is dramatically more expensive than discovering them in a load test. A 10-minute load test before a high-traffic event can prevent hours of incident response.
How it works
Define the scenario: which user journeys to simulate, at what concurrency, for how long. Write test scripts that reproduce user behavior (login, navigate, perform core action, log out). Define acceptance criteria: p50, p95, p99 latency thresholds and error rate limits. Run the test against a staging environment that mirrors production configuration (same instance sizes, same database, same caches). Analyze results: identify the bottleneck that limits throughput, fix it, re-test. Repeat until the system meets the acceptance criteria at expected peak load.
Common mistakes
Load testing against development environments — development environments do not mirror production and produce misleading results
No acceptance criteria — a load test without a pass/fail threshold is a performance exploration, not a gate
Not including database load — the database is most commonly the bottleneck; tests that do not hit the database find the wrong bottleneck
Running load tests only before major launches — load characteristics change as the product grows; regular load testing catches regressions
Ignoring p99 latency — mean latency looks healthy while a significant percentage of users experience slow responses; look at percentiles, not means
Related terms
How Vantage relates
Non-functional performance requirements extracted from a Vantage PRD — response time under load, throughput targets, concurrency expectations — generate explicit tickets for load testing. This ensures load test work is scoped and scheduled alongside feature development rather than treated as an afterthought before launch.