Capacity planning: find the saturation point

Current snapshot

Count actual jobs in a bounded queue

This experiment routes individual synthetic requests through a waiting room and a fixed set of workers. An offered request starts immediately if a worker is free, waits in first-in-first-out order if a queue slot is available, or is rejected if both are full. Each job has an identifier, arrival time, service start and completion time. Workers finish existing jobs before admitting arrivals at the same instant. Older queued requests start before the new arrival. The history shows these decisions, while the snapshot exposes all active and waiting identifiers. No service, agent, network or operating-system thread runs in this model.

Compare arrival rate and service capacity

Arrival rate offers one, two, four or eight requests per second at evenly spaced instants. Worker count selects one, two, four or eight independent workers. Service duration selects half, one or two seconds of exclusive worker occupancy per request. Ideal capacity is workers divided by service duration, measured in requests per second. It is a ceiling for sustained completions under these assumptions, not a benchmark or a promise about an ADK deployment. The first arrival occurs after one interarrival interval, so the initial idle period and unfinished final jobs prevent a finite sixty-second completion count from simply equaling capacity times sixty.

Find saturation with exact experiments

Use two workers, one-second service and four waiting slots. At one request per second, sixty requests have arrived by the end: fifty-nine have completed, one is active, none wait and none are rejected. Increase the arrival rate to four. The same workers cannot sustain that load; the final snapshot has 240 offered, 118 completed, two active, four waiting and 116 rejected requests. Now increase workers to four: 236 complete, four remain active and no request is rejected. Alternatively keep two workers and halve service duration: 238 complete, two remain active and none are rejected. These results depend on the fixed arrival and completion ordering stated above.

A longer queue is not more compute

Waiting capacity selects zero, four or sixteen queued requests, excluding active workers. Zero still permits immediate service when a worker is free; it simply provides no waiting room. With the overloaded four-request-per-second example, changing four slots to sixteen admits twelve more waiting jobs but leaves 118 completions in the same sixty-second window. The longer queue raises waiting time for jobs that have started. It postpones rejection without increasing the workers service rate. Rejected jobs are dropped once: no retry, backpressure, deadline expiry or hidden deferred demand is added.

Read latency and utilization honestly

Completed latency averages completion time minus arrival time only for jobs that finished. Started wait averages start time minus arrival time only for jobs that have begun service; maximum wait uses the same started cohort. A waiting job is excluded from these statistics, so the reported means do not summarize unfinished requests. Busy utilization integrates occupied workers over inspected time and divides by worker count times time. It is null-free and zero at time zero, but latency and wait means are unavailable until their cohorts exist. All selected times align exactly to an eighth-second grid. Results are deterministic; there is no random service time, burstiness, batching, cache effect, token quota, autoscaling, cancellation or contention between workers.

Inspect time and preserve comparisons

Play advances a sixty-second inspection and becomes Pause. Pause freezes the view; Next event pauses at the next arrival or completion boundary. Restart retains configuration and speed while rewinding. Time seeks and pauses; Speed selects quarter, half, normal or double pace. Changing a capacity input rewinds without autoplay, and hiding the tab pauses playback. Export events JSON includes the complete computed workload and the current prefix as separate fields. Capture baseline stores current results and inputs; Replace baseline updates the comparison and Clear baseline removes it. Notebook observations persist in this browser and Export notes downloads them. Expand experiment and Exit full screen adjust the view. Active and queued identifiers are readable in text, and event history supports keyboard scrolling.