Load-Test Design Workbench
What is load testing?
Load testing applies controlled, representative traffic to a system so a team can measure capacity, latency, errors, queueing, and recovery before real users discover the limit.
Step 1
Model
Choose an open-loop arrival rate or closed-loop virtual-user model, set pacing and journey mix, describe tested service and dependency limits, then define acceptance thresholds and automatic stop conditions.
Step 2
Observe
Compare offered load with admitted and successful throughput, inspect concurrency and latency percentiles, find the saturated resource, and decide whether the plan should pass, fail, or abort.
Step 3
Challenge
Start with the planned ramp. Then inject a ramp spike, soak leak, dependency slowdown, retry storm, and capacity wall. Treat every result as a planning estimate until a controlled run produces measured telemetry.
Design the run before generating traffic
Shape arrivals, model service limits, inject failure, and decide whether the planned run should pass, fail, or stop.
Pressure-test the healthy plan
Shape traffic and workload
Choose how load is generated, then define journey cost.
Open-loop generators maintain arrivals even when responses slow.
Closed-loop users wait for a response and then apply pacing.
Used to estimate VU demand in both planning modes.
Excludes setup, data seeding, and cool-down.
Define the system envelope
Use limits measured in a controlled environment when available.
Set acceptance and stop limits
Acceptance defines success. Stop limits protect the test system.
Plan passes
The estimate stays inside every acceptance threshold and no stop condition fires.
1,800 RPS estimated successful
1,530 VUs estimated with pacing
78% app / 52% dependency
240 of 3,240,000 admitted requests
Offered load versus estimated ceiling
Trace pressure through the system
Latency percentiles
Percentiles are deterministic planning estimates derived from configured service time, queue pressure, retries, and scenario modifiers. Replace them with measured histograms after a real run.
Acceptance criteria
Automatic stop conditions
A real runner should stop new arrivals, retain diagnostics, and cool down when any safety condition fires.
This model helps expose contradictory targets and unsafe test plans. It is not telemetry and does not claim to predict production exactly. Calibrate per-instance capacity, service times, failure rates, and journey weights from controlled experiments before approving a real run.