I have a problem statement where i need to call token api every hour to generate the token and pass it on to the next api , As token expires every hour
I saw many solutions on community but none of them are helping .
Some solutions i tried doing :
Using elapsed time …but when i use this concept in default function …then also after every hour token api will be called not once but equal to the number of virtual users am running . And i want to call token api once and want all vusers to use that generated token .
I thought of storing the token value in csv file and read it dynamically every hour . But seems like even papa parse works on static files [ open the file once and read the data ]
setup function only runs once during the tenure of test duration so cant use it .
Not sure how i can achieve this . Please suggest on how we can do this .
Hi, not an elegant (more like very ugly) but working solution that we used is such case.
It is a combination of the approach you mention as solution #1 + some additional logic.
So, there is no way to manage the flow you have in mind with just k6. (or at least we haven’t found such).
Considering this, we created a simple service that calls for new token once the previous expires and exposes only one GET endpoint that returns this token.
So now our k6 script is calling this helper service once an hour to get fresh token. But although each VU is going to make such call, but real call for new token is made only once when the first VU reaches out for new token. After that call, the same token is returned by helper service to all subsequent calls.
This solution obviously has a lot of downsides (starting from the need to build and spin new service), but it worked for us.
Thanks @hbadger for the reply . If it worked its not ugly . Either way i see no other solution apart from the one you proposed . Waiting to hear from others …any other ideas if we can achieve this . In jmeter it was possible using different thread groups , not sure if we can introduce such functionality in k6 as well or any such thing like setting a global variable value dynamically and fetching from there .
Hi @Shabd Instead of developing a service for this purpose as @hbadger proposes, you can also consider using redis store the token. You can then create a separate function in k6 that refresh this token periodically.
Discussing this further with the k6 oss team, what we recommend is usually asking “How will this actually work?”. What we are usually trying to achieve with load testing is doing what users will do:
If the users login independently, it would be ok to have VUs each use their own token and refresh it once it expired. If the login API cannot handle that load with the test, something to fix as this might be a real scenario?
Or are all your users sharing the same token until it expires? If so, how do they refresh it, do you have a centralized service?
Also, users not always stay on the site for hours. If that is your case, rotating users and logging in and out will be replicating the behavior.
If you can further describe the scenario, providing more context, we might be able to help further. From what we understand at this point, “doing what the users will do” if they need to re-login would allow you to implement a realistic-enough test.
Thanks @eyeveebe for the reply and apology for late reply . I agree with the above points but some time tokens are generated by third party/out of box api and they may not provide that much scalability in lower environment …in those cases we focus mainly on the performance of our services and try not to test there services more because there could be rate limit set in lower environment because of cost and all .