Explain the k6 architecture, what VUs are, the script limitations and why they exist

[mstoykov]

It is fairly common to get questions in the vain of:

1. I changed this variable here but this other VU didn't see it
2. I did some changes to this variable in setup/default but couldn't see it in default/teardown
3. Init code is executed multiple times
4. I want to do X in init code

Examples:
https://github.com/loadimpact/k6/issues/1008
grafana/k6#784
grafana/k6#1710
grafana/k6#693 <- why setup isn't modifiable between VUs
https://community.k6.io/t/token-is-not-passed-from-setup-to-general/495
https://community.k6.io/t/using-auth0-authentication/854

The https://k6.io/docs/using-k6/test-life-cycle does explain some of those but not directly enough in my opinion and given the number of questions we get it is probably better for this to be explained with examples of why it would not work and how to get what the user wants given that this approach doesn't work

[dafydd-t]

Related to my #1710 issue, I would recommend explicitly documenting the limitation of amending objects in the init scope in the setup VU. Thanks again for explaining.

[na--]

Forgot about this issue so I opened #512... 🤦‍♂️

We don't explain in enough details what the k6 VUs actually are, and how the whole test execution is structured. https://k6.io/docs/using-k6/test-life-cycle/ explains some things, but probably not in enough detail for advanced users, so they can get a good mental model of why things are the way they are, and why certain restrictions need to be in place.

grafana/k6#2267 is an example of this problem, but we've had many other similar questions and issues before. Not to mention that such a page might also be helpful for potential k6 contributors, extension writers, as well as people wanting to squeeze the maximum performance out of k6 itself and understand pages like https://k6.io/docs/using-k6/javascript-compatibility-mode/

[codebien]

https://community.k6.io/t/execution-order-question/2793/3

We should add a section in the test life cycle documentation explaining the __VU == 0 case where we process the code multi times for executing the different blocks/steps (setup, teardown, options resolution, handle summary, etc..).

[oleiade]

We have planned to move forward in this cycle of development: upcoming release 0.44.

[oleiade]

We have published a first blog post in a series of what will probably be four articles on the topic: https://grafana.com/blog/2023/08/10/understanding-grafana-k6-a-simple-guide-to-the-load-testing-tool/

[ppcano]

Also, I could not find an specific docs detailing the architecture of the k6 JS execution pipeline: JS - goja - go.

Explaining this could be really beneficial, as they are often questions about it. Also, documentation pages like Compatibility Mode, Extensions, and Performance comparison will cross-link for further reference.

But I am unsure the JS execution architecture should be included in the VU architecture guide or a different one. If the latter, I'd open a separated issue.