Document how VUs are cycled in arrival-rate executors

[na--]

Prompted by grafana/k6#1623 (comment), we should make sure to explain that the arrival-rate executors are going to cycle over all of the initialized VUs, given enough time, even if they only need a small fraction of them at any given point to run their allotted iterations per second.

[mstoykov]

I guess I have to comment here instead of at #1016 (comment).

I am not certain documenting the specificity of the VUs being cycled is a good idea. This is an implementation detail that might change in the future.

It also has close to zero actionable things you can do with that. Even the linked example is arguably not great because it depends on the data and each iteration being uniformly taking time.

This seems to be based on the usual "misconception" that you should map 1 user to 1 VU for the whole duration of the test/scenario. Which IME is not great and does not scale either way.

As such I prefer if instead of documenting the specific cycling of VUs to more or less say "there is no guarantee on which number of VU will run which number of iteration for any given scenario. A uniform distribution of the iterations over the VUs is guaranteed and should not be depended on. "

[na--]

Good points, I agree that we shouldn't document the current state, since it is indeed an implementation detail that we might decide to change in the future, e.g. to optimize the executor for higher throughput. Documenting the current implementation will almost prevent us from doing that, or at least make it an unnecessary breaking change. 👍 for something like this:

There is no guarantee which VU will run which iteration for any given scenario. A uniform distribution of the iterations over the VUs is guaranteed and should not be depended on.

[MattDodsonEnglish]

Thanks to both of you for pointing this out. I've added this which I think is more useful and general than the original: 79c10d6