-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Optimize ramping-vus #1499
Comments
I think part of what is said here is basically #1427 |
Something else to fix with this: #1496 (comment) |
This was an initial attempt to solve the first point from #1514, but there were a few blockers: - #1499 - #1427 - #1386 (comment)
A potentially bigger problem is the requirements calculations when we have |
Another way to optimize the requirement calculations would be to combine steps. If we have to rapidly increase/decrease the number of active VUs (e.g. more than 1 VU starting/stopping in under 50ms), we probably should combine the steps in a single one. |
While writing #2256 (comment) I thought about this somewhat and I think it might be better to completely rewrite it to work more like
This definitely will need more research. |
Unfortunately this probably won't help... 😞 The problem is that you can have something like this: export let options = {
scenarios: {
up: {
executor: 'ramping-vus',
startVUs: 0,
stages: [
{ target: 10, duration: '10s' },
],
gracefulRampDown: 0,
gracefulStop: 0,
},
down: {
executor: 'ramping-vus',
startVUs: 10,
stages: [
{ target: 0, duration: '10s' },
],
gracefulRampDown: 0,
gracefulStop: 0,
},
},
}; |
yes @na-- and this can be calculated as the first having the function f(x)=x for x between 0 and 10 and the second being f(x)=10-x for x between 0 and 10 and so when you combine them it is f(x)=10 |
You've probably forgotten how the calculation of the execution requirements for k6/lib/executor/ramping_vus.go Lines 298 to 308 in 02dee67
|
I haven't forgotten how it works, I just didn't want into explaining how those need to be modelled if we decide to try this approach. All that gracefulRampDown/shutdown does is that it makes the function change a bit "later" - you obviously drew something in this graph so we can fit a function on it ;). The bigger problem that I just realized is that while this seems to work really nicely with continuous functions, but in reality, they are step functions. Although given that they have a name I would expect there are also really nice ways to define and add multiple step functions that will also work, but again this will need to be looked into. |
As mentioned in #1496 (comment), currently the
ramping-vus
executor needlessly generates its raw execution steps twice.Or rather, it generates them at least 4 times...
GetFullExecutionRequirements()
: https://github.com/loadimpact/k6/blob/0839be833a912e89e64eef97dbc277d0cdc4ed9f/lib/executors.go#L260HasWork()
internally callsGetExecutionRequirements()
https://github.com/loadimpact/k6/blob/0839be833a912e89e64eef97dbc277d0cdc4ed9f/lib/executor/variable_looping_vus.go#L514-L516Run()
method: https://github.com/loadimpact/k6/blob/0839be833a912e89e64eef97dbc277d0cdc4ed9f/lib/executor/variable_looping_vus.go#L537-L543This is a problem, because the execution requirements of this executor can easily contain thousands of steps...
With a little effort, we can probably combine the first 2 uses (by splitting up
GetFullExecutionRequirements()
and keeping the individual scenario requirements, and the last 2 uses (by having a few more private helper methods, so we can reuse data).So while that would reduce the number of requirement generation to 2, I feel like even that's unnecessary. It seems to me that the problem is that we pass around the
ExecutionTuple
way too much... That is, despite us knowing what its value would be pretty early in the k6 execution, and that value being a complete constant, we don't "give" it to executor/scenarios configs to keep. So they can't pre-calculate all of these heavy-duty calculations in advance and just reuse them. Instead, we just pass it to the various functions all of the time, for no apparent benefit...The text was updated successfully, but these errors were encountered: