We have 10 scripts, running in stages as below, total users are 1000vus.
For the registration script there are 100 vus. The registration script needs unique data for each user and each iteration. The registration script will iterate 20 times for each user, so a total of 2000 registrations will be completed in 1 hour.
In a csv data file(/Registration.csv), we will keep 2000 rows of registration.
Is this the correct number of rows in csv file? How do we pick unique data for each user out of these 2000 rows of data?
k6 has two built-in variables for tracking the virtual user number and iteration number (per user): __VU and __ITER. You could use a combination of these to ensure each user is allocated to a unique block of records in your data file.
Let’s assume you import the data to a Javascript array called users. Given your statement that each user will run 20 iterations of the script, the below formula should work:
let user = users[((__VU - 1) * 20) + __ITER];
Note, I subtracted 1 from __VU as it is one-based, where both __ITER and the Javascript array your data is stored in are zero-based. The result is that the first VU is assigned records 0-19 in the array, the second user assigned records 20-39, etc.
By the way, given your requirement that each user run 20 iterations, you may wish to use the per-vu-iterations executor in k6 rather than the ramping-vus. If you use ramping-vus you may run into situations where a user runs more or less than 20 iterations due to variations in how long iterations take to complete.
In our case registration script runs 10% of total user load that is 100users of total 1000users. If we use:
let user = users[((__VU - 1) * 20) + __ITER];
then __VU will be number from 1-1000, is my understanding correct?
if yes then I need to keep 1000 set of unique data for all users but use only 10% by registration script.
I did a bit more testing and my solution looks like it works well for single-scenario tests, but runs into some issues in multi-scenario tests. I didn’t realize until I tried it in a multi-scenario test that the VU numbers assigned to each scenario are not always going to be predictable.
I think it could still work if you kept unique data for your total number of users, as you suggested (so 20 unique records each for 1000 users). But I don’t know how realistic that is for you in terms of the types of data you use, and it does mean only 10% of the actual data values would be used each test run.
Has anyone else on the forum come up with a better solution for this?
Your case is similar, though even more tricky. With ramping-vus you can’t know how many iterations each VU will complete, so if it’s a strict requirement to not re-use the same elements out of the array, it’s impossible to use __VU and __ITER to accurately select elements. A per-vu-iterations executor would make this easier as @dan_nm mentioned above.
Something like xk6-counter might be the only way to handle this if ramping-vus and unique data are a requirement.