free_tool
Throughput & Concurrency Calculator
How many instances does your traffic actually need? Enter requests per second and latency and Little's Law gives you the in-flight concurrency to support, plus the fleet size to serve it with headroom, instead of guessing and over-provisioning.
Instances needed
12@ 70% util
actual utilization ≈ 66.7% once rounded up
- Required concurrencyL = λ·W
- 400
- Throughput / instance
- 625 rps
- Capacity at this fleet
- 7,500 rps
Sizing a fleet or chasing a scaling cliff? I'll pressure-test the numbers against your real traffic shape and autoscaling config.
Size it with me: book a callA first-order model (L = λ·W). Real fleets also see queueing, GC pauses and connection limits, but this is the number every capacity plan starts from. Share the link to compare scenarios.
how_it_works
One identity behind every capacity plan
Little's Law says the average number of requests in flight equals arrival rate × time in system: L = λ·W. At 5,000 req/s and 80ms latency you always have ~400 requests in flight, no matter how you slice it.
From there it's division: a single instance holding 50 concurrent requests clears 50 ÷ 0.08s ≈ 625 req/s, so you need enough instances to cover 5,000 req/s at your target utilization. The lever that moves it most isn't more boxes; it's cutting W. Halve latency and you halve the fleet.
faq
Questions & answers
- What formula does the Throughput and Concurrency Calculator use?
- It applies Little's Law: required concurrency equals throughput in requests per second times average latency in seconds. At 5,000 requests per second and 80ms latency, you always have about 400 requests in flight.
- How does it decide how many instances I need?
- It divides required concurrency by the concurrency one instance can handle at your target utilization, then rounds up to whole instances. It also reports the actual utilization once that rounding is applied.
- Why does latency matter more than throughput for fleet size?
- Because concurrency is throughput times latency, cutting latency cuts the number of in-flight requests one for one. Halving 80ms to 40ms roughly halves the concurrency and the instance count you need.
- Is this an exact capacity model?
- No. It is a first-order model that assumes uniform load and does not account for queueing, garbage-collection pauses, connection pool limits, or traffic spikes. Use it for sizing and headroom, then confirm with a load test.
- Does it send my traffic numbers anywhere?
- No. All the math runs in your browser and nothing leaves the page. Your inputs only appear in the URL when you copy a shareable link.
Want these numbers pressure-tested on your stack?
I'll review your inputs and tell you where the real cost and risk are. Book a call, or leave your email and I'll reach out.
Prefer proof first? See how this plays out in real case studies →