RPS is the number of requests per second, which usually indicates the load works under the JMeter engine. It is preferable in testing API performance. The topic describes how to control RPS in JMeter-based scenarios.
Configure RPS limits
To reuse the existing JMeter script, PTS supports JMeter testing. By default, the JMeter engine runs under concurrent mode. RPS is determined by the concurrency and response time. Excessive low concurrency may result in unexpected RPS. The server may be overwhelmed due to high concurrency. Therefore, JMeter provides the Constant Throughput Timer component to limit RPS.
You can add Constant Throughput Timer node to the thread group in JMeter script to limit the RPS for this thread group by performing the following steps. The following figure shows how to control RPS in JMeter scenarios.
Usage notes:
Take note of the following items when configuring Constant Throughput Timer nodes:
The Calculate Throughput based on must be set to this thread only. Then, triggered operations are performed by using a single thread. PTS automatically starts multiple JMeter engines in different scenarios based on concurrency. Other configurations are valid only for a single engine. Therefore, you can obtain global maximum RPS by setting maximum RPS and maximum concurrency.
The Target throughput of Constant Throughput Timer is expressed in minutes. You can use __jexl3 to multiply the RPS by 60 seconds (1 minute = 60 seconds). To obtain
0.5RPS for a single thread, you can set the Target throughput to${__jexl3(0.5 x 60)}. You can divide the global RPS limits by the concurrency to obtain the RPS limit for a single thread.
Sample configurations:
In summary, the control over RPS during JMeter test depends on configured concurrency that cannot be adjusted accordingly and may not support the desired functions. We recommend that you create a PTS scenario to implement testing over RPS. This scenario supports RPS configuration and adjustment in seconds. For more information, see Configure load models and levels.