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

Update the README and repo wiki after v0.27.0 #1556

Closed
na-- opened this issue Jul 15, 2020 · 7 comments
Closed

Update the README and repo wiki after v0.27.0 #1556

na-- opened this issue Jul 15, 2020 · 7 comments
Labels

Comments

@na--
Copy link
Member

na-- commented Jul 15, 2020

There are probably quite a few things that need updates after https://github.com/loadimpact/k6/releases/tag/v0.27.0

@na-- na-- added the docs label Jul 15, 2020
@na-- na-- added this to the v0.27.1 milestone Jul 15, 2020
@bbsbb
Copy link

bbsbb commented Jul 15, 2020

Piggybacking on this, there is a line in the Readme that states: These scenarios can run both sequentially and in parallel . I would be quite interested in how is sequential execution of scenarios controlled, as I assumed a configuration switch but am not finding it in the codebase. Thank you!

Edit: I am assuming the idea is not to control it with startTime.

@na--
Copy link
Member Author

na-- commented Jul 15, 2020

@bbsbb, at the moment, startTime is the only way to control it... 😅 It'd be a bit finicky if you want to chain many scenarios, since you'd have to calculate the time offsets manually (or write a small JS helper function to do it), but it should look somewhat like this:

import http from 'k6/http';
import { sleep } from 'k6';

export let options = {
    scenarios: {
        stages_up_down: {
            executor: "ramping-vus",
            startVUs: 0,
            stages: [
                { duration: "10s", target: 20 },
                { duration: "10s", target: 0 },
            ],
            gracefulRampDown: "10s",
            gracefulStop: "10s", // this also has to be taken into account
            exec: 'webtest',
        },
        stages_down_up: {
            executor: "ramping-vus",
            startVUs: 20,
            stages: [
                { duration: "10s", target: 0 },
                { duration: "10s", target: 20 },
            ],
            gracefulRampDown: "10s",
            gracefulStop: "10s",
            exec: 'webtest',

            startTime: "30s", // this is the important part, 2nd sequential scenario
        },
        api_test: {
            executor: 'constant-arrival-rate',
            rate: 3,
            timeUnit: '1s',
            duration: '30s',
            preAllocatedVUs: 20,
            exec: 'apitest',

            startTime: "60s", // 3rd sequential scenario
        },
    },
};

export function webtest() {
    http.get('https://test.k6.io/');
    sleep(Math.random() * 5);
}

export function apitest() {
    http.get(`https://test-api.k6.io/`);
}

Notice how the startTime option of each scenario is equivalent to the time the previous scenario is going to finish (essentially the startTime + max duration, including any gracefulStop, of the previous scenario. k6 is smart enough to reuse VUs between scenarios that don't overlap, so this whole test run is going to require only 20 VUs instead of 60:

  scenarios: (100.00%) 3 executors, 20 max VUs, 2m0s max duration (incl. graceful stop):
           * stages_up_down: Up to 20 looping VUs for 20s over 2 stages (gracefulRampDown: 10s, exec: webtest, gracefulStop: 10s)
           * stages_down_up: Up to 20 looping VUs for 20s over 2 stages (gracefulRampDown: 10s, exec: webtest, startTime: 30s, gracefulStop: 10s)
           * api_test: 3.00 iterations/s for 30s (maxVUs: 20, exec: apitest, startTime: 1m0s, gracefulStop: 30s)

We have some plans to add a startAfter: "otherExecutorName" scenario option in the future (#1342), so users don't have to manually calculate time offsets, but there are some serious implementation hurdles to overcome before it can happen (#1342 (comment)).

@bbsbb
Copy link

bbsbb commented Jul 15, 2020

Our scenarios are generated so this was easy to implement. Still, I do believe that sequential execution mode for scenarios as a control switch would be a good addition. Will consider if I can write a good justification for it in a separate issue, but off the top of my head, with some executor types parallel would be almost undesirable.
Anyway, thanks for the great work;o)

Edit: I will actually see if I can contribute my thoughts to #1342

@na-- na-- modified the milestones: v0.27.1, v0.28.0 Jul 27, 2020
@mstoykov
Copy link
Contributor

Can we also drop the Installation section as well, as it basically repeats the docs, but as has been shown we have some issues with the windows install link, which we need to update ... also I doubt users will have problems clicking one more link ;)

On a related note, I DO think that the README is overly long and probably most of it should go in the docs and just to have links from the README as well

@na-- na-- modified the milestones: v0.28.0, v0.29.0 Sep 8, 2020
@na-- na-- modified the milestones: v0.29.0, v0.30.0 Nov 3, 2020
@na-- na-- removed this from the v0.30.0 milestone Jan 13, 2021
@marooncoder09
Copy link
Contributor

Is this issue still open

@na--
Copy link
Member Author

na-- commented Oct 11, 2021

It is, though keep in mind that it might not be suitable for people who are new to k6, it requires some fairly in-depth knowledge of how executors and scenarios work in k6...

@na--
Copy link
Member Author

na-- commented Nov 23, 2022

This is no longer relevant after #2769 / #2746

@na-- na-- closed this as completed Nov 23, 2022
This issue was closed.
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