InfyCalculator
💻

Requests Per Second Calculator

Requests per second four ways with Little's Law: a server's maximum throughput from response time and concurrency, load from concurrent users and think time, peak RPS from daily traffic, and the workers and servers needed for a target RPS — with queueing delay, headroom and bandwidth.

Calculate
Average response time
Concurrent workers / threads
Concurrent users (virtual users)
Think time between requests
Page views (or visits) per day
Server requests per page view
Peak-to-average ratio
Target throughput
Target utilization
Workers per server
Average response size
Loading calculator…

How it works

Little's Law: L = λ × W · Max throughput = concurrency ÷ response time · Closed-loop load = users ÷ (response time + think time) · Average RPS = daily requests ÷ 86,400; peak = average × peak ratio · Workers = ⌈RPS × response time ÷ target utilization⌉ · Bandwidth (Mbps) = RPS × KB × 8 ÷ 1,000

Little's Law says the average number of requests inside a system equals the arrival rate times the time each one spends there (L = λ × W). For a server that means three numbers are tied together: requests per second, response time and concurrency. Server capacity divides the number of workers by the response time to get the most a server can complete — one worker answering in 200 ms tops out at five requests a second. “From users” turns a load-test style scenario into RPS: each virtual user sends a request, waits for the response and pauses for a think time, so throughput is users divided by that cycle. “From daily traffic” converts page views a day into an average and a peak rate, and “Workers needed” sizes the concurrency for a target RPS. Every mode applies a target utilization so you plan with headroom, counts servers from workers per instance, estimates outbound bandwidth from the response size, and — where an arrival rate is known — uses the Erlang C queueing model to show how long requests wait. A table and chart show how the answer moves if the response time gets better or worse.

Worked example

With a 200 ms average response time, one worker does 1 ÷ 0.2 = 5 req/s; ten workers give 50 req/s, or 3,000 a minute, and at 75% utilization about 37.5 req/s is a safe sustained load. Going the other way, 1,000,000 page views a day is 1,000,000 ÷ 86,400 = 11.6 req/s on average; with a 4× peak that is 46.3 req/s, so 9.26 requests are in flight and you need ⌈9.26 ÷ 0.75⌉ = 13 workers — two servers of eight. And 2,800 users with 3 s of think time and 1 s responses send 2,800 ÷ 4 = 700 req/s.

Sources: Little, J. D. C. (1961). A Proof for the Queuing Formula L = λW. Operations Research 9(3)

Frequently asked questions

What is Little's Law?

Little's Law states that the average number of items in a system equals the arrival rate times the average time each spends there (L = λ × W). Rearranged, throughput = concurrency ÷ response time, which is how this calculator gets every result.

How do I convert concurrent users to requests per second?

Divide the number of users by the time between their requests — the response time plus the think time. 2,800 users who each wait 1 s for a response and pause 3 s produce 2,800 ÷ 4 = 700 req/s. Without think time the same users would generate far more load, which is why load tests must use realistic pauses.

How do I estimate peak RPS from daily traffic?

Divide daily requests by 86,400 to get the average per second, then multiply by a peak-to-average ratio. A ratio of about 4 assumes the day's traffic is squeezed into roughly six busy hours; launches, sales and news spikes can be 10× or more.

Why plan for 70–80% utilization instead of 100%?

Queueing delay grows sharply as workers get busier. With random arrivals a pool at 95% utilization makes many requests wait, while one at 75% absorbs bursts and slow requests. The queueing estimate in the results shows this effect for your numbers.

Why is my real throughput lower than the estimate?

The capacity figure is a theoretical maximum. In practice response times rise under load, workers wait on shared databases or locks, and requests queue — all of which pull real throughput below the ideal figure. Load-test to find the true number.

How do I increase requests per second?

Either lower the average response time (caching, faster queries, less work per request) or raise useful concurrency (more workers, async I/O), provided the downstream resources can keep up.

Related calculators

This calculator is for educational purposes. Double-check important results before acting on them.