A fixed number of iterations are executed in a specified period of time. Since iteration execution time can vary because of test logic or the system-under-test responding more slowly, this executor will try to compensate by running a variable number of VUs—including potentially initializing more in the middle of the test—in order to meet the configured iteration rate. This approach is useful for a more accurate representation of RPS, for example.
See the arrival rate section for details.
In addition to the common configuration options this executor also adds the following options:
|duration(required)||string||Total scenario duration (excluding gracefulStop).||-|
|rate(required)||integer||Number of iterations to execute each timeUnit period.||-|
|preAllocatedVUs(required)||integer||Number of VUs to pre-allocate before test start in order to preserve runtime resources.||-|
|timeUnit||string||Period of time to apply the rate value.||"1s"|
|maxVUs||integer||Maximum number of VUs to allow during the test run.||-|
When you want to maintain a constant number of requests without being affected by the performance of the system under test.
In this example, we'll execute a constant rate of 200 RPS for 1 minute, allowing k6 to dynamically schedule up to 100 VUs.
Note that in order to reliably achieve a fixed request rate, it's recommended to keep the function being executed very simple, with preferably only a single request call, and no additional processing or sleep() calls.