LOAD TEST · ADMISSION AND TIMEOUTS
Load testing: throughput and admission outcomes
Drive an agent endpoint with a traffic ramp and see whether overload is rejected at the door, queued, or served after the client has already given up.
Your experiment
Arrivals jump from 2 to 8 requests per second for 30 seconds against an endpoint that serves 4 per second, with a 20-request queue and a 10-second client timeout. Watch rejections absorb the overload, then lengthen the queue, shorten the timeout and switch to a closed workload.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Discrete one-second model, not a load-testing tool: every request holds a worker for exactly 2 s; arrivals are deterministic; the server does not know when a client gives up, so an abandoned request is still served (wasted work). Closed users wait 1 s after each reply, rejection or timeout. Requests still queued or running at 60 s are reported as unfinished.
Capacity, queue and timeout
The endpoint has Concurrent workers, and every request holds one for 2 modeled seconds, so 8 workers serve 4 requests per second. A request that finds every worker busy waits in a queue of at most Queue limit requests; one that finds the queue full is rejected at once, like an HTTP 429. The client gives up after Client timeout seconds, but the server does not know that and still serves the request if it is queued. A load test should report all four outcomes: on time, rejected, served too late, unfinished; the Admission lane shows each one.
The opening run: overload shed at admission
The open generator sends 2 requests per second, then 8 per second from 10 to 40 seconds, then 2 again: 300 requests in 60 seconds. At 10 seconds requests start queueing; the 20-request queue is full at 15 seconds, and from then on the extra 4 per second are rejected, 100 in total. A full queue drains in about 20 / 4 = 5 seconds, so admitted requests wait a few seconds plus 2 seconds of service, well inside the timeout: 196 requests finish on time, none too late, with a p95 latency of 8 seconds. The queue is empty again at 48 seconds.
Failure boundary: a longer queue
Raise Queue limit to 50: fewer requests are rejected (70), but a request at the back now waits 12.5 seconds, longer than the 10-second timeout. 116 admitted requests are served after their clients gave up, 232 worker-seconds of wasted work, and only 96 finish on time. A queue longer than throughput × (timeout − service time) converts rejections into timeouts. Set the timeout to 30 seconds with the same queue and the timeouts disappear: 212 on time, p95 15 seconds. A 4-second timeout with the opening queue fails the same way (126 too late).
Capacity and closed workloads
At a Peak arrival rate (open) of 4 per second, or with 16 workers, the endpoint keeps up with no rejections and a p95 of 2 seconds. A queue of 0 rejects 120 requests but keeps every accepted latency at 2 seconds. Switch Load generator to the closed generator: 16 Virtual users (closed) each wait for a reply before sending again, so the offered load adapts to the server and the run looks healthy (231 on time, p95 3 seconds). From 31 users upward the closed test does fill the queue and reject requests (56 at 31 users). A closed generator cannot show what happens when users keep arriving regardless of how slow the service is.
Reading the run and its limits
Play replays the ramp, first queueing, first rejection, first late response (when there is one), the drain and the outcome over sixty inspection seconds, while the chart shows the complete computed arrivals, on-time responses and queue length. Next event, Restart, Speed and Inspection time control the replay, and any input change recomputes it. The model uses one-second steps, a fixed 2-second service time and deterministic arrivals; real services have variable latency, retries that add load, and autoscaling, so use it to reason about the outcomes, not to predict a real endpoint.