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

> Requests per second, transactions per second, and concurrent users measure different things. Here's how they relate and how to convert between them.

Source: https://loadster.com/faqs/rps-tps-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](https://loadster.com/faqs/calculating-v-users-needed-for-a-load-test/) 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](https://loadster.com/manual/load-test-scenarios/) 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](https://loadster.com/faqs/think-time-wait-time/) 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.