What’s the difference between requests per second, transactions per second, and concurrent users?

Requests per second (RPS) measures the number of individual HTTP requests that reach your servers each second. Transactions per second (TPS) measures completed business operations, such as checkouts or signups, and concurrent users measures how many people or bots are active at the same time.

These measurements are related, but they aren’t interchangeable. It’s worth understanding which one your requirements refer to before designing a load test.

Requests per Second (RPS)

RPS describes load from the server’s perspective. A single page load might send dozens of requests when you count images, scripts, stylesheets, and API calls, while a single REST API call is just one request. For this reason, 1,000 RPS might come from a relatively small number of users browsing a resource-heavy site or from 1,000 API clients each calling an endpoint once per second.

Concurrent connections is a related but somewhat different measurement. It counts the number of TCP connections that are open at once. A connection can remain open between requests, so concurrent connections and RPS usually won’t be the same, and web servers often have separate limits for each.

It’s definitely possible to hit a bottleneck in requests per second before running out of concurrent connections, or vice versa!

Transactions per Second (TPS)

TPS describes load in terms of completed business operations. For example, if the requirement is to process 6,000 orders per hour, you’re dealing with a transaction rate rather than a request rate. Each order might involve several pages and many individual HTTP requests.

In Loadster, the iterations counter tracks completed script runs. If one complete script iteration represents one purchase transaction, the number of iterations per hour is equivalent to your hourly transaction rate. The FAQ on calculating how many bots you need explains how to work backwards from a target number of iterations.

Concurrent Users

Concurrent users measures how many users are active in the middle of a session at the same time. This is different from the total number of users over an hour, day, or month. For example, a site with 50,000 daily visitors might only have a few hundred users active at any given moment.

In Loadster, the number of bots in your test scenario is closely analogous to concurrent users. Each bot represents one active user and repeats your script for as long as that bot group runs. To the extent that your script is realistic, how your site performs with a certain number of concurrent bots is very similar to how it will perform with that many concurrent users.

Converting Between Users, Transactions, and Requests

You can estimate concurrency with Little’s Law: concurrency equals the arrival rate multiplied by the average session duration. For example, 5,000 visits per hour is about 83 visits per minute. If each visit lasts around 3 minutes, you’ll need roughly 250 concurrent users on average to simulate 5,000 visits per hour.

The number of requests those 250 users generate depends on how many requests each page makes and how long the users pause between actions. That’s why realistic wait times are so important. The same number of concurrent users can produce drastically different request rates depending on the script cadence: what they do and how quickly they do it.

Which Should Your Load Test Target?

Which one to target in your load test depends in part on how your requirements are structured.

Generally, it makes sense to model concurrent users when you’re simulating human traffic on a website or web application, because each user is active for a period of time and pauses between actions. Report RPS when you’re testing an API used by machines and the request rate is the most useful measurement. Focus on TPS when your requirements are expressed in business operations such as orders or signups per hour.

Loadster scenarios express load in bots, which represent concurrent users. The resulting request and transaction rates are downstream of that and also depend on the behavior and timing in your scripts.