Read elements from an array using constant_request_rate

Hi! I need to create a load test where huge, ~1GB size data files have to be used as input for POST request payload. Each line in these file would be a JSON object and pre-read into an array and the test should run the following way:

  • requests have to be sent at a constant rate, so constant_request_rate scenario will be used
  • each request should send the next JSON object from the array as a payload

As i understand every VU will share the data so this will also add to the complexitiy.

How would you solve the problem to read the next item from the array and use it as a payload for the current request? Maybe it’s a JS question, but im new to k6 and JS as well and as i see the default function cannot store state, like index of an array defined outside of it.

I got this far :slight_smile:

import http from "k6/http";
import { SharedArray } from "k6";

export let options = {
    scenarios: {
      constant_request_rate: {
        executor: 'constant-arrival-rate',
        rate: 10,
        timeUnit: '3s',
        duration: '60s',
        preAllocatedVUs: 10, 
        maxVUs: 20,

const data = new SharedArray("some data name", function() { return open("./payload.txt").split(/\r?\n/); });

export default function () {



Thinking it through again, probably the best solution for my use case is to not use scnearios, but the default mode with VUs, iteration and duration. So this way i can utilize the execution context variables and with their help i can distribute the array indexes properly inbetween VUs.
So this should fulfill the not that strict fixed request rate with the help of sleep().

Although im still interested, how would anyone solve the problem with constant_request_rate.

__VU and __ITER are the best we have now, though that’s far from sufficient for complex cases like yours:

Alternatively, you use xk6 and run your tests only on a single local machine, then you can use something like this counter extension that works across all VUs: GitHub - MStoykov/xk6-counter

Finally, we’re working on a better alternative built into k6 that would be especially useful for arrival-rate executors, though I can’t give a firm ETA yet:
And we have even more flexible

1 Like

Thanks ned, will try these out.