TheDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/grafana/k6/llms.txt
Use this file to discover all available pages before exploring further.
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:- Iterations start at a fixed rate (e.g., 10 iterations/second)
- k6 automatically allocates VUs as needed to maintain the rate
- If iterations are fast, fewer VUs are needed
- If iterations are slow, more VUs are allocated (up to
maxVUs) - If
maxVUsis reached and rate can’t be maintained, iterations are dropped
Configuration
Must be
constant-arrival-rateNumber of iterations to start per
timeUnit period. Must be greater than 0.Period over which the
rate is calculated. Must be greater than 0.Total duration of the executor. Must be at least 1 second.
Number of VUs to pre-allocate before test start. These VUs are immediately available.
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
WhenmaxVUs is reached and can’t maintain the rate, iterations are dropped:
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 iterationsiteration_duration- How long each iteration takesdropped_iterations- Iterations dropped due to insufficient VUsvus- Current number of active VUsvus_max- Current number of allocated VUs (up to maxVUs)
Best Practices
- Set maxVUs generously: Allow 2-3x the expected VUs to handle variability
- Monitor dropped_iterations: Set thresholds to alert on dropped iterations
- Right-size preAllocatedVUs: Match expected steady-state requirements
- Consider iteration duration: Longer iterations need more VUs for same rate
- Test VU allocation: Run short tests to verify VU requirements
- Use for throughput testing: Better than constant-vus for testing capacity
- Watch for rate limiting: Monitor for 429 responses when testing limits
Comparison with Constant VUs
| Feature | Constant Arrival Rate | Constant VUs |
|---|---|---|
| Load model | Fixed iterations/sec | Fixed VUs |
| VU count | Dynamic (auto-scaled) | Static |
| Throughput | Constant (if possible) | Variable |
| When response slows | More VUs allocated | Throughput decreases |
| Complexity | Higher | Lower |
| Best for | Throughput/capacity tests | User simulation |
Troubleshooting
Too Many Dropped Iterations
VUs Not Fully Utilized
See Also
- Ramping Arrival Rate - Variable arrival rate over stages
- Constant VUs - Fixed VU count instead of fixed rate