See where the waiting happens.
Explore how worker capacity, concurrency, and workload shape a request queue. Every number here is derived from a deterministic virtual model—not a benchmark of Rust, Tokio, or this website.
Your experiment starts here.
Run the model to inspect simulated throughput, latency, and request outcomes. No backend is called.
A transparent model, with clear limits.
Sync, async, and blocking.
A synchronous caller waits for an operation to return before continuing. Async execution can yield while waiting. The blocking model holds a worker for dispatch plus the full service duration; the async model releases it during I/O waits. CPU-bound work holds a worker in both models.
A closed-loop request model.
Each client sends its next request only after its previous request finishes. A fixed 2 ms dispatch cost precedes work. Seeded, per-client samples determine service jitter and failures. This is not an open-loop traffic generator or a real Tokio scheduler.
Virtual time, declared denominators.
Latency is finish minus arrival, including queue time. p50/p95/p99 use nearest-rank percentiles over all completed requests, including failures. Successful throughput is successes divided by configured virtual seconds; error rate is failures divided by completed requests.
No completion, no percentile.
Requests unfinished at the cutoff are counted separately and excluded from latency and error-rate samples. Empty samples show a dash. The model omits network overhead, database behavior, memory pressure, and runtime costs. It cannot establish production capacity.
A declared hardware and deployment environment, versioned workload, warm-up policy, raw request observations, error categories, and a collection window. Real endpoint measurements should remain separate from these simulated results.
Read the concurrency implementation note →