Requests per second:
requests ÷ seconds

How to calculate requests per second

Requests per second (RPS) is the number of requests divided by the time in seconds. If your server logged 90,000 requests in one hour, that is 90,000 ÷ 3,600 = 25 requests per second. Convert the time window to seconds before you divide.

The number tells you how busy your service is. Developers use it to compare load against what a server, database or API can handle, and to set limits so that a traffic spike does not take the system down.

The RPS formula and an example

Peak load, not the average, sets the capacity

A day of 2,160,000 requests averages 25 req/s, but real traffic is lumpy. A shop's site may see much more at 8 pm than at 4 am, and a sale or a message to your mailing list can multiply it for a few minutes.

Count the busiest minute in your logs, divide by 60, and size for that. If peak traffic is four times the 25 req/s average, plan for 100 req/s. A server that copes with the average but not the peak will fail exactly when it matters most.

From RPS to servers and concurrent requests

If one server can safely handle 30 req/s, a peak of 100 req/s needs 100 ÷ 30 = 3.33, so you round up to 4 servers. The 30 is only an example; measure your own with a load test, since it depends on your code and hardware.

Concurrency follows from a simple relation: requests in progress at once ≈ RPS × average response time in seconds. At 250 req/s with a 0.2 s response time, about 50 requests are in flight at any moment.

Add some headroom on top. Running a server near its limit leaves no room for a sudden surge, a slow database query or a failed machine, so many teams aim to stay well below the tested maximum.

Reading RPS from real logs

Most web servers and load balancers write one log line per request, so counting lines in a time window gives the request total. Divide that by the window length in seconds to get RPS, then repeat for several windows to see how traffic changes through the day.

Monitoring dashboards usually plot this for you, but doing the sum by hand is a good check on what a chart is showing. If a graph says 25 req/s and your log shows 90,000 requests in an hour, the two agree.

Common mistakes with requests per second

• Dividing by minutes or hours instead of seconds.
• Planning for the average and ignoring peaks.
• Counting page views instead of requests. One page often triggers many requests for images, scripts and data.
• Using one test result for every endpoint. Heavy routes cost far more than light ones.
• Forgetting that bots and health checks add to the count.