In requests per second (RPS) mode, Performance Testing Service (PTS) controls throughput instead of the number of concurrent connections. The load generator dynamically adjusts virtual users to sustain the target RPS based on how fast the system under test responds. Slower responses automatically trigger more virtual users to maintain the same throughput, because the send rate is decoupled from response time.
Formula
Virtual users = RPS x response time (RT) in secondsThis is an instantaneous value. PTS recalculates it continuously during the test based on the current RPS and RT, not as an average over a time window.
Example: RPS set to 1000
| RT | Virtual users |
|---|---|
| 0.1 s | 100 |
| 2 s | 2,000 |
As RT increases, PTS spins up more virtual users to keep the request rate steady. In practice, RT fluctuates throughout a test and tends to increase under heavier load, so the virtual user count rises accordingly.
What happens when the system under test degrades
When the system under test slows down, RT spikes and request failures increase. Because PTS keeps adding virtual users to meet the target RPS, this creates a feedback loop: rising RT drives more virtual users, which further overloads the system.
PTS does not monitor the health of the system under test. If you observe any of these symptoms, stop the test immediately:
RT climbs sharply or exceeds expected baselines
Request failure rate increases
Backend resource utilization (CPU, memory, or network) saturates
Prevent runaway load
Set a realistic target RPS. Base it on capacity estimates or prior benchmark results. For details, see Configure load models and levels.
Ramp up gradually. Start with a low RPS and increase it in steps while monitoring system metrics. This helps you identify the breaking point before the system fails completely.