This feature makes it easier for the tester to understand the limits of the target servers or the load engines when loading a certain scenario - providing more control.
With this feature, you can limit the RPS (Requests Per Second) of the load in order to avoid creating a bottleneck. For example: if you believe that 350 RPS will create a bottleneck on the app servers side, you can limit the RPS to 200. If it reaches 200 and everything goes smoothly, you can increase the RPS limit to 300 (and so on).
This enables you to test load at the maximum capacity without crashing the servers. This is a best practice for the following scenarios:
1. Running a soak test.
2. Running multi instance tests with maximum threads per engine.
Changing RPS Limits 'On The Fly'
You can click on the Run Time Control button in the top right corner of the reports section, and then choose Change RPS to change the RPS on the fly.
A dialog box will appear which lets you change the value. Set the value and click "Apply" to send the new value to the test engines.
An Example of the Limit RPS and Change RPS Features Used Together
In the above example, Limit RPS was set at 200 in the test configuration and the test was launched. After seeing that the system was still stable after the ramp had completed, we used Change RPS to set the new RPS value to 300 at 14:38:45.
Note: Limit RPS and Change RPS control RPS by imposing delays between requests made by your virtual users (VUs). If you plan to increase RPS after the test launch, be sure to launch enough virtual users to allow for "headroom" -- In other words, Change RPS cannot deliver more RPS than your running VUs are capable of.