Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refresh access token during soak test #3268

Open
schurmann opened this issue Aug 14, 2023 · 5 comments
Open

Refresh access token during soak test #3268

schurmann opened this issue Aug 14, 2023 · 5 comments
Labels

Comments

@schurmann
Copy link

Feature Description

I need a way to refresh an access token that is used for authorization during a soak test. It is important that is token is refreshed asynchronously and outside the VU loop to not skew the metrics.

Suggested Solution (optional)

Enable setInterval usage in init context.

Already existing or connected issues / PRs (optional)

No response

@mstoykov
Copy link
Collaborator

Hi @schurmann, sorry for the slow reply.

Unfortunately what you propose have ... a few problems ... and actually already works.

import { setInterval } from "k6/experimental/timers";

setInterval(() => {
	console.log("in interval");
}, 100);

This will continously print "in interval".

The current event loop will not continue executing the next part of the test until all jobs are finished. This allows you to make a request for example and not start an new iteration or the test to just finish, until the response is actually returned.

In this case this means that we won't continue after the init as ... we have a function that is to be exectued each 100ms. If you clear the interval after sometime the execution will continue.

In theory k6 can have "special" treatment for something. But IMO this will be:

  1. confusing
  2. hard to use correctly for anything but the easiest example like here. Just an FYI VUs are reused between scenarios if possible. And some of them can be created in the middle and so on and so on.

The usual proposal here is to just check that the token was generated soon enough on iteration start as explained here.

Some other notes:

asynchronously and outside the VU loop to not skew the metrics.

Seems to me like you are not understanding that each VU is a separate JS VM which willl run the init code once - so it loads it source and knows what actually to do. And then k6 will instruct it when to run the default funciton in some manner (depending on the executor).

There is no actual way for you to run code that doesn't run on the VU loop as ... JS is single threaded and we want to run in the same VU.

skew the metrics

This might be doable once we have a way to not emit metrics with certain calls - but it is not doable currently. See #1321 which to be honest should be picked up, but is unlikely to happen soon, given current priorities.

@mstoykov mstoykov added the awaiting user waiting for user to respond label Aug 21, 2023
@schurmann
Copy link
Author

Thanks for the detailed answer! I have decided not to pursue this further since the current K6 architecture isn't flexible enough for our needs. I might come back to K6 in the future when native histograms are no longer experimental in prometheus and there is a way to update a shared state asynchronously (e.g. the access token). Feel free to close this.

@nk-tedo-001
Copy link

Hey, Team!

Is there any update on this topic? I will be looking for this feature soon, how to refresh token during long run test.

@mstoykov mstoykov removed their assignment Jan 10, 2024
@mstoykov mstoykov removed the awaiting user waiting for user to respond label Jan 10, 2024
@LewisCowlesMotive
Copy link

Uncertain if this is solved by https://community.grafana.com/t/periodically-refreshing-a-token-aside-a-script/99736/3, but it is a result I came to; and we now have a ticket in backlog at work to solve, so would be happy to share what we come up with if it is not the grafana community forum solution.

@mstoykov
Copy link
Collaborator

Hi @LewisCowlesMotive - yes this is the alternative which I apperantly didn't mention while I was explaining why having timeouts between iterations is not really compatible 🤦

But yes - you cna have code that checks (either before every request or usually at iteration beginning) if the token will expire in X amount of time and ... relogin.

@mstoykov mstoykov removed the triage label Feb 19, 2024
@mstoykov mstoykov removed their assignment Feb 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants