In virtual user mode, Performance Testing Service (PTS) uses a closed model: each virtual user sends a request, waits for the response, and then sends the next request. Transactions per second (TPS) therefore depends on both the number of virtual users and how fast the server responds.
Relationship between TPS, virtual users, and response time
TPS is calculated by the following formula:
TPS = Number of virtual users / Average response time (in seconds)When the number of virtual users stays constant, TPS is inversely proportional to the average response time (RT). A slower server response directly reduces throughput.
Example
Suppose you run a test with 1,000 virtual users:
| Average RT | TPS |
|---|---|
| 1 second | 1,000 |
| 2 seconds | 500 |
The concurrency setting did not change, but TPS dropped by half because the server took twice as long to respond.
Why this happens
In a closed model, each virtual user follows a sequential cycle:
Send a request.
Wait for the server to respond.
Send the next request.
A virtual user cannot start a new request until the current one completes. When the server slows down, each user spends more time waiting and completes fewer transactions per second. Throughput is inherently coupled to response time -- slower responses mean longer iteration cycles and lower TPS.
What to do about it
If TPS fluctuates during a test, check the average RT of the server under test. An increase in RT is the most common cause of TPS variation at constant concurrency.
Fluctuating TPS is expected. In virtual user mode, TPS reflects the server's actual processing speed. A drop in TPS typically means the server is under strain and responding more slowly.
To maintain a fixed request rate, switch to TPS mode. In TPS mode, PTS sends requests at a constant rate regardless of response time, decoupling throughput from server performance.