A variable number of iterations are started in specified periods of time. This is similar to the ramping VUs executor, but for iterations instead. k6 will attempt to dynamically change the number of VUs to achieve the configured iteration rate.
See the arrival rate section for details.
In addition to the common configuration options this executor also adds the following options:
|stages(required)||array||Array of objects that specify the target number of iterations to ramp up or down to.|||
|preAllocatedVUs(required)||integer||Number of VUs to pre-allocate before test start to preserve runtime resources.||-|
|startRate||integer||Number of iterations to execute each timeUnit period at test start.||0|
|timeUnit||string||Period of time to apply the startRate to the stages' target value. Its value is constant for the whole duration of the scenario, it is not possible to change it for a specific stage.||"1s"|
|maxVUs||integer||Maximum number of VUs to allow during the test run.||If unset, same as preAllocatedVUs|
If you need your tests to not be affected by the system-under-test's performance, and would like to ramp the number of iterations up or down during specific periods of time.
In this example, we'll run a four-stage test. We initially stay at the defined rate of starting 300 iterations per minute over a minute period. Then, ramping up the iteration rate from 300 to 600 iterations started per minute over the next two minutes period, and staying at this rate for four more minutes. Finally, down to starting 60 iterations per minute over the last two minutes period.
The following graph depicts the performance of the example script:
Based upon our test scenario inputs and results:
- We've defined 4 stages for a total test duration of 9 minutes.
- Stage 1 maintains the startRate iteration rate at 300 iterations started per minute for 1 minute.
- Stage 2 ramps up the iteration rate linearly from the stage 1 of 300 iterations started per minute, to the target of 600 iterations started per minute over a 2-minute duration.
- Stage 3 maintains the stage 2 iteration rate at 600 iterations started per minute over a 4-minute duration.
- Stage 4 ramps down the iteration rate linearly to the target rate of 60 iterations started per minute over the last two minutes duration.
- Changes to the iteration rate are performed by k6, adjusting the number of VUs as necessary from preAllocatedVUs to a maximum of maxVUs.
- The script waits for a period of time (defined by the gracefulStop option) for iterations to finish. It won't start new iterations during the gracefulStop period.
- The script will run the teardown() function (if specified) before exiting.
- Our example performed, 4020 iterations over the course of the test.
To get the current running stage index, use the getCurrentStageIndex helper function from the k6-jslib-utils library. It returns a zero-based number equal to the position in the shortcut stages array or in the executor's stages array.
Using this feature, it is possible to automatically tag using the current running stage. Check the Tagging stages section for more details.