-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[Feature Request]: Add stepped-arrival-rate #2252
Comments
Basically I've added "bad" PR just to explain the idea. If the idea will be approved by the dev team, I will prepare clean PR/docs and tests. |
Hmm, I think I understand what you want to achieve, but I am not sure a completely new executor is the right solution here 🤔 It doesn't significantly change the actual script execution (i.e. how iterations are executed by VUs), it is just a change in how the iteration rate is "ramped" between the stages. Besides, I can see how someone could want a Right now, the We already want to change this, since linear progression is not always what people want. In fact, @oleiade is about to open a new issue for supporting custom non-linear interpolation/progression functions in scenarios: {
contacts: {
executor: 'stepped-arrival-rate',
startRate: 10,
timeUnit: '1s',
preAllocatedVUs: 50,
maxVUs: 1000,
stages: [
{target: 100, duration: '5m', progression: 'instant' },
{target: 300, duration: '5m', progression: 'instant' },
{target: 600, duration: '10m', progression: 'instant' },
{target: 1000, duration: '30m', progression: 'instant' },
],
}, There is some repetition here, but that can be easily taken care of by a small helper function to generate the whole stages: [
{target: 100, duration: '5m', progression: 'logarithmic' }, // gradually ramp up to 100 iters/s
{target: 300, duration: '5m', progression: 'instant' }, // immediately spike to 300 iters/s
{target: 600, duration: '10m', progression: 'linear' }, // linearly ramp up to 600
{target: 1000, duration: '30m', progression: 'instant' }, // another spike to 1000
], @LaserPhaser, @oleiade, what do you think about this? |
For me it's even better and much more clear than a new executor. |
@LaserPhaser, sure, a PR with this will be very welcome! We weren't planning to work on this ourselves for now, we just wanted to open a new issue about it, to see if there was interest in the funcitonality, so I'm happy to see that, indeed, there is 😅 We'll close this issue when we write up the one for a stages progression function. We'll also try to help out if you have any issues with the implementation, there is going to be some complexity here. Also, thinking a bit more about this, we should probably also open another new issue for gauging interest in adding xk6 extension support for custom executors. Even if this specific case would be better handled another way, there might be other very valid use cases for custom executors that we might not want to (immediately) merge into the k6 core 🤷♂️ Since the |
Added an ability to control how the arrival rate will be added Linear - default instant - optional Closes grafana#2252
@na-- could you please comment my PR (of cause I will add tests little bit later) |
Added an ability to control how the arrival rate will be added Linear - default instant - optional Closes grafana#2252
Hi @LaserPhaser, As @na-- mentioned it, I have now created a dedicated issue referencing this one: #2256. I also took the liberty to reference you #2255 PR. I'm on board with @na-- on this one, and assume we wouldn't need a dedicated executor. Not being an expert of the codebase nor of how scheduling works yet, I'm assuming, there should indeed be a way to control the interpolation between stages by using a dedicated function taking some starting point, end point, and delta duration (from the beginning of the ramping stage). |
Your PR should stay open, we'll review it in the next few days and discuss any changes that might be required to merge it in there. We didn't plan to work on this now ourselves, but we'll try and support your effort. However, I'll close this issue in favor of #2256, no point in having two different issues for the same thing. |
Feature Description
In addition to the ramping-arrival-rate
one of the most common features in loadtesting is stepping.
For example when you know that your system must hold up to 1000RPS.
You want to test it step by step in the following manner:
100 rps for 5 minutes
up to 300 rps for 5 minutes
up to 600 rps for 10 minutes
up to 1000 rps for 30 minutes.
Right now it's possible to configure such steps with the following scenarios
For me right now it's looks like woraround.
Suggested Solution (optional)
My suggestion is to add "stepped-arrival-rate":
Where target will mean not the final target of this stage but the RPS which we should hold during the 'duration'.
With such configuration, the scenarios will looks like
Which is more clear to read and understand in my opinion
The text was updated successfully, but these errors were encountered: