So in the docs for “open()” it says we should use SharedArray since it’s less memory intensive because VU’s can share the data instead of re-opening for each VU.
However in the test lifecycle docs it mentions this should be maybe done in setup()?
Im wanting to know the best way to basically load a JSON data file to use (In this case it’s specific to the UL) IE: a guid that gets loaded and put in the URL.
But same thing for other cases (such as a body payload). If I am only really needing it once for the URL shouldn’t I be able to use it in the setup() lifecycle function? Or will VU’s not have access to it then?
Hopefully my question makes sense. But this is for 2 cases (1 where I need to read from a json file for the URL and 1 where I need to read from a json file for a body payload). I am just wondering where in the test lifecycle these should go?
At this time Shared Array can only be used in the init stage. So you will not be able to use it in the setup.
There is an on-going GH issue that explains the underlying reasons at this time, and what the team is working on to make it usable at setup. Feel free to add a there to help prioritize the issue, and comment if there is something you want to add to the thread.
In terms of options, you could use a simple open file in the init stage without the SharedArray. However, if the files you need to read are big, it’s probably best to use a SharedArray to reduce the memory consumption and prevent an OutOfMemory.
So do people typically load JSON files (payloads) in the setup or Init then? I would assume Init but that runs for every VU…so if I want to load a JSON payload what is the “ideal” way to do it then? (or how most people do it).
FWIW some of the .json files are relatively large (for a JSON payload at least).
Typically we see more the case of [retrieving unique data](Data Parameterization. However, your use case seems different, so if you can confirm the details (is it the same JSON payload for all VUs that you have in a file) I’ll ask internally if there is a better way to load the payload.
The JSON file would “probably” be the same for all VU’s. Im mainly trying to load test a POST endpoint, and im using a JSON file as the payload. I guess still using SharedArray is the right way to go here.
another possibly however is to be able to load a JSON file, then maybe adjust a parameter per request (This is probably more difficult). IE: like an ID might increase by +1 for each request for example (since the POST request will get blocked in some cases if there are duplicate values). Not sure the best way to go about that either (Although this is a less common case)
Although I guess that can just use the example in the link you posted above. In the example though I can’t quite tell (Data Parameterization) if that data file is being read every single time per VU? Im guessing no since it is INSIDE the shared array callback?
Im really curious also what people typically use setup() for even then? Since it’s only called once and not shared among VU’s. From what I gather what we return from setup can then be called into the main function correct?
If you need to to use different values, data parameterization is the way to go. And SharedArray will take care of this being optimal. Under performance characteristics we describe a bit more the gains.
Obtain an authentication token in the setup and have all VUs use it. In situations where you are not testing the token/authentication endpoint, but your API endpoints. E.g. Unique login for each virtual User - #3 by immavalls2
When you want to test the system that needs some previous data loaded, that is not part of the test. You can create the data using the setup and delete it in the teardown. E.g. with the sql extension, create records in a database that will be used in the test, and then delete the records at teardown to leave the system as it was.
In the setup function you can use most k6 APIs, just not open a local file at this time.
there to help prioritize the issue, and comment if there is something you want to add to the thread.