Response time tells you how fast. Throughput tells you how much. These two metrics together define your system's capacity. A system with 50ms response time but only 10 requests per second has a bottleneck. A system handling 10,000 requests per second but with 5-second response times is overloaded. You need both numbers.
Throughput is the number of requests the system processes per unit of time. It is usually measured in requests per second (RPS) or transactions per second (TPS). A transaction might be a single HTTP request or a multi-step user flow (login + search + add to cart = 1 transaction with 3 requests).
Think of a highway. The speed limit (response time) might be 100 km/h. But if the highway has only 2 lanes, it can only handle 3,000 cars per hour (throughput) no matter how fast each car goes. Adding more lanes (servers, workers) increases throughput without changing the speed of individual cars.
As you add users, throughput follows a predictable pattern. It rises linearly at first -- more users means more requests being processed. Then it plateaus -- the system is at maximum capacity. After that, it may actually decrease -- the system is so overloaded that it spends more time managing contention than processing requests.
These are NOT the same thing. If your website has 10,000 registered users, maybe 1,000 are online at any given time. Of those 1,000, maybe 200 are actively clicking something at the exact same second. Those 200 are your concurrent users.
| Concept | Definition | Example |
|---|---|---|
| Registered Users | Total accounts | 100,000 people signed up |
| Active Users | Users with an open session | 5,000 are browsing right now |
| Concurrent Users | Users sending requests simultaneously | 500 are clicking at this exact second |
| Virtual Users (VUs) | Simulated users in a load test | 500 JMeter threads |
There is a mathematical relationship between throughput, concurrent users, and response time. It is called Little's Law and it is the most useful formula in performance testing.
Concurrent Users = Throughput × Average Response Time
Or rearranged:
Throughput = Concurrent Users / Average Response Time
Example:
- 100 concurrent users
- Average response time: 0.5 seconds
- Throughput = 100 / 0.5 = 200 requests per second
Another example:
- You need 500 RPS throughput
- Average response time is 200ms (0.2 seconds)
- Concurrent users needed: 500 × 0.2 = 100 usersLittle's Law helps you calculate the number of virtual users for your load test. If your goal is 1,000 RPS with an expected response time of 500ms, you need: 1000 × 0.5 = 500 concurrent virtual users. This is much more accurate than guessing "let us try 500 users and see what happens."
Q: What is the relationship between concurrent users, throughput, and response time?
A: They are related by Little's Law: Concurrent Users = Throughput × Response Time. This means if you have 100 concurrent users with 500ms average response time, your throughput is 200 requests per second. This is critical for test planning -- to achieve a target throughput of 1,000 RPS with 200ms response time, you need 200 concurrent virtual users. Throughput follows a curve: it rises linearly with users, plateaus at system capacity, and may actually decrease beyond the saturation point due to contention. The plateau is your system's maximum capacity.
Key Point: Throughput measures capacity (how many requests per second). Little's Law connects it to users and response time: Users = Throughput × Response Time. Use it to calculate the right number of virtual users for your tests.
Key Point: Throughput = capacity. Little's Law: Users = Throughput × Response Time. Use it to plan test user counts accurately.