Workload Modeling
Workload modeling designs load tests around realistic traffic mix, arrival patterns, and data distributions — because synthetic average-rate floods predict nothing about production behavior.
Definition
Workload modeling is the construction of representative load: endpoint mix weighted by production traffic, arrival processes (open versus closed systems, Poisson versus fixed pacing), think times, and data distributions matching cardinality and hot-key structure. Load test validity flows from the model — an unrealistic mix finds unrealistic bottlenecks.
Context and scope
Applied before load testing with k6, Gatling, JMeter: mine production logs for endpoint weights and parameter distributions, then replay shapes rather than volumes.
Common misconceptions
- More requests per second means a better load test — arrival pattern and mix dominate; a closed-model hammer distorts queueing behavior entirely
- Uniform random parameters stress the system like production does — production has hot keys and skewed cardinalities; uniform loads hide the real hotspots
- The load environment can be smaller than production — scaled environments can work with calibrated extrapolation, but the model must then account for which bottlenecks shift
Anti-patterns
- Hammering one endpoint at maximum rate and declaring capacity based on a workload that never occurs
- Load testing with a fixed thread count (closed model) a system that faces open arrivals, missing queue buildup entirely
- Generating test data with uniform keys and missing the 80/20 production skew that breaks caches and shards
Related concepts
Authoritative source
What it is
A load test answers a question about a system under a specific demand. Workload modeling is choosing the demand: which requests, in what proportion, arriving how, touching what data. The answer is only as valid as the question.
How it works
Mine production telemetry for the mix — endpoint weights, payload sizes, parameter cardinalities, temporal patterns like morning ramp and batch windows. Open-model generators fire arrivals on schedule regardless of completion; closed models wait for responses and thus mask queueing collapse. Data shaping reproduces hot keys, long-tail ids, and cache hit dynamics.
When to model
Before every capacity decision: scaling events, migration cutover, Black-Friday readiness. Revalidate the model after product changes shift traffic mix.
Pitfalls
Test data volume changes everything: index behavior, cache hit rates, and query plans diverge between a toy dataset and production scale. Test clients themselves saturate and become the bottleneck — distribute generators. Soak behavior — memory growth, compaction — needs hours, not the minutes a spike test runs.