No results for

Powered byAlgolia

Constant arrival rate


A fixed number of iterations are started in a specified period of time. This executor will continue to start iterations at the given rate as long as there are VUs available to run them. 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 VUsincluding potentially initializing more in the middle of the testto meet the configured iteration rate. This approach is useful for a more accurate representation of RPS, for example.

For explanations about how this executor works, refer to Open and Closed models and Arrival-rate VU allocation.

Iteration starts are spaced fractionally

Iterations do not start at exactly the same time. At a rate of 10 with a timeUnit of 1s, each iteration starts about every tenth of a second (that is, each 100ms).


Besides the common configuration options, this executor has the following options:

duration(required)stringTotal scenario duration (excluding gracefulStop).-
rate(required)integerNumber of iterations to start during each timeUnit period.-
preAllocatedVUs(required)integerNumber of VUs to pre-allocate before test start to preserve runtime resources.-
timeUnitstringPeriod of time to apply the rate value."1s"
maxVUsintegerMaximum number of VUs to allow during the test run.If unset, same as preAllocatedVUs

When to use

When you want to maintain a constant number of iterations without being affected by the performance of the system under test.

Don't put sleep at the end of an iteration

The arrival-rate executors already pace the iteration rate through the rate and timeUnit properties. So it's unnecessary to use a sleep() function at the end of the VU code.


In this example, we'll start a constant rate of 30 iterations per second for 30 seconds, allowing k6 to dynamically schedule up to 50 VUs.

1import http from 'k6/http';
2import { sleep } from 'k6';
4export const options = {
5 discardResponseBodies: true,
6 scenarios: {
7 contacts: {
8 executor: 'constant-arrival-rate',
10 // Our test should last 30 seconds in total
11 duration: '30s',
13 // It should start 30 iterations per `timeUnit`. Note that iterations starting points
14 // will be evenly spread across the `timeUnit` period.
15 rate: 30,
17 // It should start `rate` iterations per second
18 timeUnit: '1s',
20 // It should preallocate 2 VUs before starting the test
21 preAllocatedVUs: 2,
23 // It is allowed to spin up to 50 maximum VUs to sustain the defined
24 // constant arrival rate.
25 maxVUs: 50,
26 },
27 },
30export default function () {
31 http.get('');
32 // We're injecting a processing pause for illustrative purposes only!
33 // Each iteration will be ~515ms, therefore ~2 iterations/second per VU maximum throughput.


The following graph depicts the performance of the example script:

Ramping VUs

Based upon our test scenario inputs and results:

  • The desired rate of 30 iterations started every 1 second is achieved and maintained for the majority of the test.
  • The test scenario runs for the specified 30 second duration.
  • Having started with 2 VUs (as specified by the preAllocatedVUs option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the maxVUs; for our test, this ended up as 17 VUs.
  • Exactly 900 iterations are started in total, 30s * 30 iters/s.

As in our example, using too low of a preAllocatedVUs setting will reduce the test duration at the desired rate, as resources need to continually be allocated to achieve the rate.