I’ve been assisting some users with using unique data across multiple k6 instances in the LoadImpact cloud. Since each instance will have overlapping
__VU IDs. This adds some complexity to determining our unique number, so I will share some of the required thinking to solve this issue. As mentioned in my last point above we can use the
LI_INSTANCE_ID to help here. However, you’ll need to do some testing to determine how many rows each VU will consume during your test (or at least a maximum). I think in most cases this should be equal to the number of iterations you expect each virtual user to make which will vary based on test duration.
Let’s consider the following, we expect each virtual user to need up to 400 rows from our JSON or CSV file. To make our script reusable, define this in the Init context. If you want to get fancy, maybe you’ll set it as an ENV variable so you can adjust it per run
let maxIter = 400 // you'll want to define this in the init context!!!
Previously with a single instance of k6, we could do something like this in our default function to generate a unique value on each run:
let uniqueNum = ((__VU * maxIter) - (maxIter) + (__ITER));
However, as stated earlier, when dealing with multiple k6 instances in the LoadImpact cloud we will encounter some collisions as each instance will have overlapping
If we make the following adjustment, we can ensure each VU gets a unique value by using their
LI_INSTANCE_ID in the equation.
First, you need to know that the LoadImpact cloud currently will put a maximum of ~200~ 300 VUs per load generator. With that in mind, this means that
_VU 300 in the above case at
__ITER 400 will be at line 120,000 in our source file.
With that in mind we can rather simply do the following, so that each instance, will start in their appropriate “block” of the source data:
let uniqueNum = ((__VU * maxIter) - (maxIter) + (__ITER) + (120000 * __ENV["LI_INSTANCE_ID"]));
Edits: updated due to changes in load generator limits in LI Cloud. 200 ->300 max VUs