Load Testing to Target Concurrency
Load testing drives realistic traffic at an expected level to verify that latency and error rates hold at the concurrency the system must serve.
Definition
Load testing is a type of performance testing that exercises a system at a defined expected workload to measure response time, throughput, and error rate under that demand.
Context and scope
It validates capacity plans and catches regressions before they reach users, using models of real traffic mix.
Common misconceptions
- generating many requests from one client models real concurrency
- a single average latency hides nothing important
Anti-patterns
- testing with a uniform request mix unlike production traffic
- using closed-loop clients that cannot reveal queueing delays
Related concepts
Authoritative source
Definition
Load testing is a type of performance testing that exercises a system at a defined expected workload to measure response time, throughput, and error rate under that demand.
It validates capacity plans and catches regressions before they reach users, using models of real traffic mix. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.
When to use it
A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.
How it works
The generator must be able to apply real concurrency without becoming the bottleneck, or the results reflect the tester rather than the system under test.
Latency should be reported as percentiles, because an average hides the tail that real users on slow paths experience.
Trade-offs and alternatives
Open-loop generators that inject requests at a fixed rate reveal queueing behaviour that closed-loop clients, which slow down under load, conceal. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.
Common misconceptions
A persistent misconception is that generating many requests from one client models real concurrency. Another is that a single average latency hides nothing important. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.
Anti-patterns to avoid
Two recurring anti-patterns are to testing with a uniform request mix unlike production traffic and to using closed-loop clients that cannot reveal queueing delays. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Approval Testing, Test Parallelization and Sharding, Mock Objects and Behaviour Verification.