I have a script that runs hundreds of calls and with 1 VU and 1 iteration, the iteration duration is 23s. With 50 VUs and 50 iterations, the iteration duration is 7min.
I have read the documentation but just need clarification on what exactly this means. My understanding is that with the 50 users all the requests being called will take 7 minutes with just 1 iteration through the requests as opposed to 23s if only I were the one calling the requests. Is this right?
also a second question: why can’t you do 50 VUs and 1 iteration, meaning 50 concurrent users are going through the same requests step by step simultaneously?
iteration_duration means the time the default function (or whatever you specified in exec, if you use scenarios) took to execute.
with 1 VU and 1 iteration, the iteration duration is 23s. With 50 VUs and 50 iterations, the iteration duration is 7min.
If the screenshot in your other topic was from the 1-iteration test run, then I think you simply overloaded the system you were testing with the 50 somewhat concurrent iterations. See how p(95) (the 95th percentile) of http_req_duration is 7 seconds here, much more than the 0.228s in your single iteration test run.
And your max http_req_duration value is 60 seconds, which was probably caused by some requests timing out. The default Params.timeout value is 60000 (60 seconds), but you can adjust it.
My understanding is that with the 50 users all the requests being called will take 7 minutes with just 1 iteration through the requests as opposed to 23s if only I were the one calling the requests. Is this right?
Yes, it seems that 50 concurrent users overwhelmed something (likely the system under test, but it could also be the system you were testing from or your network connection, I can’t tell just from the end-of-test summary).
also a second question: why can’t you do 50 VUs and 1 iteration, meaning 50 concurrent users are going through the same requests step by step simultaneously?
You can. For historical reasons, when you configure options.vus and options.iterations directly, k6 will run them in a so-called “shared iterations” execution mode - the VUs are competitively trying to execute the same “pool” of iterations. If one VU finishes an iteration early and there are more unexecuted iterations remaining in the shared “pool”, it will “take” another one from it and immediately start executing it. So, {iterations: 50, vus: 50} will generally mean that each VU will execute a single iteration, unless they are super short, but there was absolutely no guarantee that if you had {iterations: 500, vus: 50}, each VU will execute precisely 10 iterations. For example, if the iteration_duration varies a lot, some VUs can execute 11 or 12 or even more iterations, while others might only manage 9 or 8 or even fewer.
Starting with k6 v0.27.0, we added the scenarios feature, which allows you to specify different executors in each scenario. So while export let options = {iterations: 500, vus: 50} will still result in a shared-iterations executor, you can now also manually specify a per-vu-iterations one. This code will mean that each VU executes precisely 10 iterations:
export let options = {
scenarios: {
some_scenario_name: {
executor: 'per-vu-iterations',
vus: 50,
iterations: 10,
maxDuration: '1h30m',
},
},
};
Thanks that was a big help in wrapping my head around everything. I do have one last question.
If your bottom coding snippet left out the “iterations: 10” part then would 50 vus be executing 1 iteration each simulatenously?
Yes, if you don’t specify iterations in a per-vu-iterations scenario, the default value is 1, so the 50 VUs will each run 1 iteration simultaneously, and k6 will wait for them - the test run will end when the longest iteration finishes (up to maxDuration).