Skip to main content
The constant-arrival-rate executor starts iterations at a fixed rate (iterations per second), independent of how long each iteration takes. This executor is ideal when you need to maintain a specific throughput or requests-per-second rate.

How It Works

With constant arrival rate:
  1. Iterations start at a fixed rate (e.g., 10 iterations/second)
  2. k6 automatically allocates VUs as needed to maintain the rate
  3. If iterations are fast, fewer VUs are needed
  4. If iterations are slow, more VUs are allocated (up to maxVUs)
  5. If maxVUs is reached and rate can’t be maintained, iterations are dropped

Configuration

string
required
Must be constant-arrival-rate
integer
required
Number of iterations to start per timeUnit period. Must be greater than 0.
duration
default:"1s"
Period over which the rate is calculated. Must be greater than 0.
duration
required
Total duration of the executor. Must be at least 1 second.
integer
required
Number of VUs to pre-allocate before test start. These VUs are immediately available.
integer
default:"preAllocatedVUs"
Maximum number of VUs allowed. If iterations require more VUs, they will be dropped. Cannot be less than preAllocatedVUs.

Example

Basic Throughput Test

API Rate Limit Testing

Different Time Units

When to Use

Use the constant arrival rate executor when:
  • You need to maintain a specific requests-per-second (RPS) rate
  • Iteration duration varies significantly or is unpredictable
  • You want to test system throughput capacity
  • You’re testing against rate limits
  • You need consistent load regardless of response times
  • You want to model realistic arrival patterns (Poisson distribution)
  • Response time degradation shouldn’t reduce load

Behavior Details

Dynamic VU Allocation

k6 automatically adjusts the number of active VUs to maintain the iteration rate:

Pre-allocated vs Max VUs

  • preAllocatedVUs: VUs initialized at test start (instant availability)
  • maxVUs: Maximum VUs that can be used (allocated on-demand)

Dropped Iterations

When maxVUs is reached and can’t maintain the rate, iterations are dropped:
Monitor the dropped_iterations metric to detect insufficient VU allocation.

Calculation: Rate to Iterations/Second

Common Patterns

Capacity Testing

Find maximum sustainable throughput:

Realistic Traffic Simulation

Combined with Ramping

Use multiple scenarios to ramp arrival rate:

Sizing VUs

Calculate required VUs:

Metrics

Key metrics for arrival rate testing:
  • iterations - Total completed iterations
  • iteration_duration - How long each iteration takes
  • dropped_iterations - Iterations dropped due to insufficient VUs
  • vus - Current number of active VUs
  • vus_max - Current number of allocated VUs (up to maxVUs)

Best Practices

  1. Set maxVUs generously: Allow 2-3x the expected VUs to handle variability
  2. Monitor dropped_iterations: Set thresholds to alert on dropped iterations
  3. Right-size preAllocatedVUs: Match expected steady-state requirements
  4. Consider iteration duration: Longer iterations need more VUs for same rate
  5. Test VU allocation: Run short tests to verify VU requirements
  6. Use for throughput testing: Better than constant-vus for testing capacity
  7. Watch for rate limiting: Monitor for 429 responses when testing limits

Comparison with Constant VUs

Troubleshooting

Too Many Dropped Iterations

VUs Not Fully Utilized

See Also