SharedArray improvements and add userInit

[ft6502]

What?

• Add the ability to call SharedArray in any context.
• Add a userInit function called once per VUser. Its default name is userInit but can be changed in every executor.

Why?

Fix #2043.

Checklist

• I have performed a self-review of my code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added tests for my changes.
• I have run linter and tests locally (make check) and all pass.

Checklist: Documentation (only for k6 maintainers and if relevant)

Please do not merge this PR until the following items are filled out.

• I have added the correct milestone and labels to the PR.
• I have updated the release notes: link
• I have updated or added an issue to the k6-documentation: grafana/k6-docs#NUMBER if applicable
• I have updated or added an issue to the TypeScript definitions: grafana/k6-DefinitelyTyped#NUMBER if applicable

Related PR(s)/Issue(s)

#2043

yes

#2043

[CLAassistant]

All committers have signed the CLA.

[joanlopez]

Hi @ft6502,

Thanks for sharing your initial approach.

At first glance, I detected that it doesn't take into account what's expressed first in #2043, which is that we cannot enable SharedArray to be used anywhere as-is (instead of only the init context, as-is now), but we need to consider some aspects, like for instance that setup might be executed in a distributed fashion, where it's only executed in a single instance and where the returned data is later distributed across the instances.
So, I'd suggest you to start thinking about this and try to take it into consideration as part of your changes.

Besides that, and more generally speaking, I'd recommend you to split that pull request, as it seems to be introducing two concepts that aren't necessarily tied, like being able to use SharedArray beyond the init context and this new userInit function that you introduced. Smaller and isolated PRs have higher chances of making some progress.

Thanks!

[ft6502]

Hi @joanlopez ,
My idea here is not to download the test data in the "setup" function once per test-run, return it and then share it using k6 internal methods. Instead the idea is that every VUser is calling SharedArray and the lambda is basically called once per instance. Which is fine for data download, but not for environment setup (which is the purpose of setup() ). So this just has two improvements that are somehow related. So if I would just lift the limit of SharedArray on the initContext, you would need to check in the exec-function of each VUser in each iteration if it's the first iteration. Or you would call SharedArray in each iteration. Which may not be that bad. Or use "if (data == null) { data = new SharedArray...}". But the downside of all these approaches is, that this happens in the iteration-function which means that the first call will be much slower and I fear that this would lead to a bump in the load of the system under test (for example for constant-arrival-rate) as all new VUsers will be blocked until the first has downloaded the test data. So although each feature is a bit useless without the other, I could nevertheless split this into two PRs if that would help.