Performance testing relies on three core metrics: concurrent users, requests per second (RPS), and transactions per second (TPS). Understanding how these metrics relate helps you choose the right load model, estimate capacity, and evaluate system performance.
Metric definitions
Virtual users
In Performance Testing (PTS), a concurrent user is a virtual user (VU) -- a simulated user that actively runs operations against your system. Each VU follows a scripted workflow (such as logging in, browsing, or submitting an order) and generates real load on the server.
VUs differ from two other user categories:
| User type | Definition | Generates server load? |
|---|---|---|
| Registered users | Accounts stored in the database | No |
| Online users | Users connected to the system but not necessarily active | No |
| Concurrent users (VUs) | Users actively running operations | Yes |
Concurrent users are always a subset of online users. A system might have 100,000 online users but only 10,000 generating actual load.
Transactions per second (TPS)
TPS measures how many transactions your system completes each second. A higher TPS indicates better system throughput.
Requests per second (RPS)
RPS measures the rate of incoming requests. Use RPS for capacity planning and throttling.
Response time (RT)
Response time is the duration from when a request is sent to when the client receives the complete response.
Open and closed load models
PTS supports two load modes that correspond to a fundamental distinction in how systems handle traffic:
| Load mode | Model type | Controls | Typical use case |
|---|---|---|---|
| Concurrent mode | Closed model | Number of concurrent VUs | Websites and H5 pages where users maintain sessions |
| RPS mode | Open model | Rate of incoming requests | Stateless APIs such as login endpoints or order submission |
Concurrent mode fixes the number of VUs and measures performance from the client perspective. When a VU finishes one transaction, it immediately starts the next, so the request rate depends on server response time. This model works well when your system queues excess traffic (for example, a session-based web application).
RPS mode fixes the request arrival rate and measures TPS from the server perspective. The request rate stays constant regardless of response time. Use this mode when your system cannot queue excess traffic -- most stateless API endpoints behave this way.
Convert between VUs and TPS
The relationship between VUs and TPS is:
TPS = VU / RTwhere RT is in seconds.
Example calculations:
| Scenario | VUs | RT | TPS |
|---|---|---|---|
| Fast transactions | 1 | 1 ms (0.001 s) | 1,000 |
| Slow transactions | 1,000 | 1 s | 1,000 |
| Single user, single transaction | 1 | 1 s | 1 |
Both 1 VU with 1 ms RT and 1,000 VUs with 1 s RT produce 1,000 TPS -- but the user experience differs significantly. TPS alone, without RT context, tells an incomplete story.
Estimate VU and TPS targets
Estimate VUs
Existing system: Select a representative peak period. Count the users actively connected to the system (online users), then take 10% as concurrent users.
Example: 100,000 online users during a 30-minute peak window --> approximately 10,000 concurrent users for testing.
New system: Work with your business team to estimate expected concurrent load, since no historical data is available.
Estimate TPS
Existing system: Select a 3-to-10-minute window during peak hours. Calculate the average transactions per second, then multiply by 2 to 5 to estimate peak TPS.
Example: 180,000 transactions in 3 minutes = 1,000 average TPS --> target 2,000 to 5,000 peak TPS for your load test.
New system: Work with your business team to estimate expected transaction volume, since no historical data is available.
Evaluate system performance
TPS is the primary metric for server-side performance. Concurrent user count is an auxiliary metric that only has meaning when paired with RT.
Why concurrent users alone are unreliable:
If the number of concurrent users is required, RT must be considered as a precondition.
If system load is low and think time (which equals RT) is factored into the business session, the number of concurrent users can be doubled -- making VU count alone misleading.
Different systems with different TPS values produce different concurrent user requirements.
Bottom line: Define your performance targets in TPS. Use VU count as a secondary reference, always alongside RT.
Load test strategy in PTS
Performance tests must be standardized and orderly. PTS uses TPS-based targets with configurable start and maximum load levels to maximize test efficiency. Rather than specifying a raw number of VUs, define the desired TPS and let PTS gradually ramp up load from the start level to the maximum. This avoids sudden traffic spikes that cause high failure rates and inflated response times, and produces more reliable results.
Use a short think time to simulate worst-case conditions. This produces conservative performance estimates that better reflect real-world traffic spikes.
Key takeaways
| Principle | Detail |
|---|---|
| TPS determines performance | System performance is determined by TPS, not by the number of concurrent users |
| Maximum TPS is bounded | For a given system, peak TPS falls within a fixed range |
| Concurrent users are adjustable | The same TPS target can be reached with different VU and RT combinations |
| Worst-case testing | Use short think times to apply load pressure as in the worst case |
| Typical VU ranges | Large systems: 10,000--50,000 VUs. Small to mid-size systems: around 5,000 VUs |