K6: Update the README and repo wiki after v0.27.0

Created on 15 Jul 2020  路  4Comments  路  Source: loadimpact/k6

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

docs

Most helpful comment

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

All 4 comments

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.

@bbsbb, at the moment, startTime is the only way to control it... :sweat_smile: 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 (https://github.com/loadimpact/k6/issues/1342), so users don't have to manually calculate time offsets, but there are some serious implementation hurdles to overcome before it can happen (https://github.com/loadimpact/k6/issues/1342#issuecomment-630607456).

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

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

Was this page helpful?
0 / 5 - 0 ratings