Docs improvement to help interpret test outputs and how that estimate VUs required to reach a certain rate

[immavalls]

Based on https://community.k6.io/t/getting-very-low-rps/5649/, https://community.k6.io/t/load-test-using-one-user-id-at-a-time-for-each-user-and-iteration/5626, and https://community.k6.io/t/k6-and-the-k6-reporter-do-not-log-accurately-highly-concurrent-requests/5600, help to interpret why the iterations/s or VU/s are not the expected, and how to estimate the preAllocatedVUs (to avoid having to define a maxVUs - except in cloud?) would be useful.

We might benefit from making it easier for k6 to allocate the required VUs for a constant-arrival-rate. It might not be easy as the number of VUs will depend on the URLs under test latency, how this also varies with increasing load...

For ramping arrival rate I think we could add what we have in k6-learn about the ramping effect.

In the meantime:

• In https://community.k6.io/t/getting-very-low-rps/5649/3, based on the latency and the test outputs, we could help users realize when the number of VUs is too low, and/or the test duration too small.
  • There is a warning in the logs when there will not be enough VUs (WARN[0000] Insufficient VUs, reached 2 active VUs and cannot initialize more executor=constant-arrival-rate scenario=k6_workshop). However, the user might only be looking at the final report. And miss that warning.
• In https://community.k6.io/t/k6-and-the-k6-reporter-do-not-log-accurately-highly-concurrent-requests/5600/10 the user (and myself) was also not interpreting the ouput

  The main signal of that is the slow iteration_duration average time, which is 40 seconds.

• https://community.k6.io/t/load-test-using-one-user-id-at-a-time-for-each-user-and-iteration/5626/ probably points to something we can clarify in the docs.

I'm not sure what we are missing in the docs, if we are. I'm just opening this to start the discussion in case we can improve something.

[MattDodsonEnglish]

#974 Should help clear up this info (I hope!). One way to avoid running the test with insufficient VUs would be to add an add a threshold to dropped_iterations with abortOnFail set to true.