Segmentation issues

[na--]

I'll use this issue to note some minor issues with the execution segmentation I've stumbled upon while testing #1007

1. This 1% segment will execute half the test run:

k6-1007 run --vus 2 --iterations 2 --execution-segment 0:1/100 --execution-segment-sequence=0,1/100,1 github.com/loadimpact/k6/samples/http_get.js

2. This test run:

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

export let options = {
    vus: 0,
    stages: [
        { target: 100, duration: "10s" },
        { target: 0, duration: "10s" },
    ],
}

export default function () {
    http.get('https://test.k6.io');
    sleep(1);
}

will have a discrepancy between the description and actual execution:

  scenarios: (33.33%) 1 executors, 34 max VUs, 50s max duration (incl. graceful stop):
           * default: Up to 33 looping VUs for 20s over 2 stages (gracefulRampDown: 30s, gracefulStop: 30s)

running (04.1s), 00/34 VUs, 14 complete and 14 interrupted iterations
default ✗ [======>-------------------------------] 01/34 VUs  04.0s/20s

Notice it say 33 looping VUs in the description, but in reality we'll run 34 (as it says in 2 other places above) - we probably use the old scaling algorithm for the description and the striping algorithm for the actual implementation... If that's the case, we should probably fix #1499 / #1427 first

[na--]

3. Found another minor bug with the ramping-vus execution plan 😭 Or, depending on how you look at it, our executor descriptions output. If you have the following script:

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

export let options = {
    vus: 0,
    executionSegment: "1/3:2/3",
    executionSegmentSequence: "0,1/3,2/3,1",
    stages: [
        { target: 60, duration: "10s" },
        { target: 0, duration: "10s" },
    ],
}

export default function () {
    http.get('https://test.k6.io');
    sleep(1);
}

you'd see something like this in the UI:

  scenarios: (33.33%) 1 executors, 20 max VUs, 49.833333334s max duration (incl. graceful stop):
           * default: Up to 20 looping VUs for 20s over 2 stages (gracefulRampDown: 30s, gracefulStop: 30s)

^C
running (02.5s), 00/20 VUs, 1 complete and 5 interrupted iterations
default ✗ [===>----------------------------------] 02/20 VUs  02.4s/19.833333334s

Notice how the times are formatted... My gut feeling is that the execution plan for this segment is correct, i.e. we don't have any work to do after t=19.833333334s, since we'd have hit 0 VUs. But it might be a bit confusing to users, who have specified 20s... Regardless if we consider this a scheduling bug, we for sure should truncate the seconds to at most 3 decimals after the dot...

[na--]

Points 2 and 3 of this issue should have been fixed by #1535, but the first point might have to wait until #1499 / #1427 😭 The current lack of config+tuple abstraction is just making fixing this a huge error-prone PITA when it comes to the constant-arrival-rate 😞 Also, #1386 (comment) is making me question the need for re-segmentation in the constant-arrival-rate executor in the first place...

So, yeah, this should probably be left for v0.28.0, after we refactor the above issues. I've started some of the work ee17425, but I'll probably leave it at that, for now... 😞

[na--]

Closing this, since 2/3 of the issues were fixed and remainder is mentioned in #1427 (comment)