Why vus Change the number?

export let options = {
    discardResponseBodies: true,
    scenarios: {
        'million_hits': {
            executor: 'per-vu-iterations',
            vus: 100,
            iterations: 200,
            maxDuration: '1h',

export default function () {


this is my script to ask the request to the website. I knew I was trying to request about 20.000 requests with a maximum 100 vus and not more 1 hour for 200 iterations each time.

i generate some good results

if we can see in the last two-line there is a number of vus, which is 1 there, somehow it is changing to 1, 2 or 4 vus. I do not even know why it was changed as the script wants. what makes the vus change actually and how to make the vus stay in the same number let say 4 or 10. i think the bigger vus is the short running time needed, which i dont think it was fair.

Hi @machine4dx,

The configured scenario as you have mention will use 100 VUs each of which will make 200 iterations and the scenario and the test will end.

vus is a Gauge which means that it takes the latest value emitted. As the test ends and each VU finishes their 200 iterations it is fairly expected that they will not all end at the same time (or even close together at 200 iterations).

So near the end of the test just before it finishes when k6 emits the vus metrics one last time it will be some number between 100 and 0. It’s really unlikely that it will be those exact values for this case as vus is emitted each 2s. Which makes it unlikely that it will be emitted right when all VUs have ended, but not before the processes has ended.

100 is somewhat more plausible, but even that is unlikely especially as your iteration_duration fluctuate between 425 microseconds and 44s.

You can see this issue for a different user who wants it to go to 0 at the end of the execution.

Do you have a particular problem with these values as in … you use them for something and this is a problem or is it just a curiosity question?

Hope this helps you

I am trying to compare some methods by seeing the running time. I don’t know if it is "apple to apple " if we can compare two methods with the same number of VUS. because once the higher is vus the short running time will spend to execute 20000 requests.

It seems to me this is not a problem for you - we do run 20000 requests with 200 VUs each doing 100 iterations.

As I mentioned in your case just the value you see is a value within the last 2 seconds of the test when it’s ending.

If you really want to have 200 VUs more of the time you can do shared-iterations executor and then the VUs with faster iterations will do more. This still means that at the end the last few iterations will take a bit more than all the other, and you will end with some VUs working a few seconds more.

I would expect that for any tool this will be the same … they just likely don’t report it :person_shrugging:

1 Like