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.

Sign up for GitHub

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

Jump to bottom

Minor changes on constant-arrival-rate docs #1487

Merged
merged 3 commits into from
Feb 12, 2024
Merged

Minor changes on constant-arrival-rate docs #1487

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d2da7e5
Minor changes on constant-arrival-rate docs
joanlopez Jan 23, 2024
7e1b977
Merge branch 'main' into constant-arrival-rate-minor
joanlopez Feb 12, 2024
9d01bcb
Adjust constant-arrival-rate example and notes
joanlopez Feb 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 10 additions & 6 deletions docs/sources/next/using-k6/scenarios/executors/constant-arrival-rate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Besides the [common configuration options](https://grafana.com/docs/k6/<K6_VERSI
this executor has the following options:

| Option | Type | Description | Default |
| ------------------------------------ | ------- | ------------------------------------------------------------------------------ | ----------------------------------- |
|--------------------------------------|---------|--------------------------------------------------------------------------------|-------------------------------------|
| duration<sup>(required)</sup> | string | Total scenario duration (excluding `gracefulStop`). | - |
| rate<sup>(required)</sup> | integer | Number of iterations to start during each `timeUnit` period. | - |
| preAllocatedVUs<sup>(required)</sup> | integer | Number of VUs to pre-allocate before test start to preserve runtime resources. | - |
Expand All @@ -53,7 +53,7 @@ So it's unnecessary to use a `sleep()` function at the end of the VU code.
## Example

This example schedules a constant rate of 30 iterations per second for 30 seconds.
It allocates 50 VUs for k6 to dynamically use as needed.
It pre-allocates 2 VUs, and allows k6 to dynamically schedule up to 50 VUs as needed.

{{< code >}}

Expand All @@ -75,8 +75,12 @@ export const options = {
// Start `rate` iterations per second
timeUnit: '1s',

// Pre-allocate VUs
preAllocatedVUs: 50,
// Pre-allocate 2 VUs before starting the test
preAllocatedVUs: 2,

// Spin up a maximum of 50 VUs to sustain the defined
// constant arrival rate.
maxVUs: 50,
},
},
};
Expand All @@ -98,7 +102,7 @@ Based upon our test scenario inputs and results:

- The desired rate of 30 iterations started every 1 second is achieved and maintained for the majority of the test.
- The test scenario runs for the specified 30 second duration.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the allocated number. For this test, this ended up as 17 VUs.
- Exactly 900 iterations are started in total, `30s * 30 iters/s`.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the `maxVUs`. For this test, this ended up as 17 VUs.
- The number of VUs to achieve the desired rate varies depending on how long each iteration takes to execute. For this test definition, if it would take exactly 1 second, then 30 VUs would be needed. However, as it takes less than 1 second, then less VUs are needed.

> Using too low of a `preAllocatedVUs` setting will reduce the test duration at the desired rate, as resources need to continually be allocated to achieve the rate.
16 changes: 10 additions & 6 deletions docs/sources/v0.47.x/using-k6/scenarios/executors/constant-arrival-rate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Besides the [common configuration options](https://grafana.com/docs/k6/<K6_VERSI
this executor has the following options:

| Option | Type | Description | Default |
| ------------------------------------ | ------- | ------------------------------------------------------------------------------ | ----------------------------------- |
|--------------------------------------|---------|--------------------------------------------------------------------------------|-------------------------------------|
| duration<sup>(required)</sup> | string | Total scenario duration (excluding `gracefulStop`). | - |
| rate<sup>(required)</sup> | integer | Number of iterations to start during each `timeUnit` period. | - |
| preAllocatedVUs<sup>(required)</sup> | integer | Number of VUs to pre-allocate before test start to preserve runtime resources. | - |
Expand All @@ -53,7 +53,7 @@ So it's unnecessary to use a `sleep()` function at the end of the VU code.
## Example

This example schedules a constant rate of 30 iterations per second for 30 seconds.
It allocates 50 VUs for k6 to dynamically use as needed.
It pre-allocates 2 VUs, and allows k6 to dynamically schedule up to 50 VUs as needed.

{{< code >}}

Expand All @@ -75,8 +75,12 @@ export const options = {
// Start `rate` iterations per second
timeUnit: '1s',

// Pre-allocate VUs
preAllocatedVUs: 50,
// Pre-allocate 2 VUs before starting the test
preAllocatedVUs: 2,

// Spin up a maximum of 50 VUs to sustain the defined
// constant arrival rate.
maxVUs: 50,
},
},
};
Expand All @@ -98,7 +102,7 @@ Based upon our test scenario inputs and results:

- The desired rate of 30 iterations started every 1 second is achieved and maintained for the majority of the test.
- The test scenario runs for the specified 30 second duration.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the allocated number. For this test, this ended up as 17 VUs.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It kinda looks like a typo (because the script above has preAllocatedVUs: 50), but seems to correspond to the image (see here), so I'm wondering if we should update the image accordingly 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this example got a bit mangled (probably by accident, or due to a misundersanding of the parameters) when some language was updated.

See 7943760 where this was last changed (this was way more difficult to find due to all the moves around in the last few months ... long live -G ).

In this case the example used to ... and still should probably start with less VUs then it needs to hit the arrival-rate. THis is mostly to showcase that it can add more VUs up to the maximum.

I am not certain we have many examples of this to begin with so removing those doesn't seem like a good idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if I fully get you. I don't suggest to remove it, just to make it sure the explanation matches the script.
I'm also fine with setting preAllocatedVUs equals to 2. Or does preAllocatedVUs serve as a maximum amount and k6 starts from zero to whatever that's enough to satisfy the desired rate? 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

preAllocatedVUs is what it starts at - the amount it has preallocated.

And then there is a maximum settings fo maxVUs that is equal to the preallocated ones if missing.

The commit I linked removes the max and uses only the preallocated one.

Whcih means that

  1. the second sentecne of 'For this test, this ended up as 17 VUs." meanss nothing - k6 started with 50 and ended with 50, instead of starting with 2 and going up to 17.
  2. Doesn't showcase this behaviour of k6 allocating more VUs if hte max hasn't been hit and needs them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

k6 started with 50 and ended with 50 but the reader cannot guess that from the test definition, right? I guess it really depends on how long each iteration takes to execute, doesn't it?

instead of starting with 2 and going up to 17, but that's what the image displays, so I guess we'll need to re-generate it, right?

In any case, what would you suggest as fix for this? I'm happy to correct this example and add another one, if it does worth it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but the reader cannot guess that from the test definition

No - the definition says k6 will preallocate 50 Vus and there is no otehr maximum - so it will always will be with 50.

but that's what the image displays, so I guess we'll need to re-generate it, right?

I would argue that we should edit the script.

In any case, what would you suggest as fix for this? I'm happy to correct this example and add another one, if it does worth it.

My suggestion is to revert the example to start with 2 preallocatedVus and have a maximum of 50 (or w/e above 17). Touch the remaining of the text.

This keeps the example useful - showcasing that k6 can allocate Vus up to the maximum and how that looks. Instead of the current example - which doesn't showcase that.

The whole edit in the linked commit (on this example specifically) seems questionable. As it changed what the example is about from an example of how preallocated and max VUs work and how that looks, to just showcasing a "happy path" example of constant-arrival-rate and having some comments that are not illustrated IMO.

  • Exactly 900 iterations are started in total, 30s * 30 iters/s.

This line is also not true - or at least wasn't in the original example as k6 will not have enough VUs to hit that. So it will be some lower number.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another issue or PR, I can't remember right now, had the same confusion around this script and the image.

But your explanation makes a lot of sense @mstoykov (and thanks for digging out the last changes). So it seems like we need to:

  • Update the script to have the following lines:
...
      // Pre-allocate 2 VUs before starting the test
      preAllocatedVUs: 2,

      // Spin up a maximum of 50 VUs to sustain the defined
      // constant arrival rate.
      maxVUs: 50,

  • Change the paragraph after "Example" to:

    "This example schedules a constant rate of 30 iterations per second for 30 seconds.
    It pre-allocates 2 VUs, and allows k6 to dynamically schedule up to 50 VUs as needed."

  • Change this line back to mention maxVUs:

    "Having started with 2 VUs (as specified by the preAllocatedVUs option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the maxVUs. For this test, this ended up as 17 VUs."

  • Remove the last list item, "Exactly 900 iterations are started in total, 30s * 30 iters/s.".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the slow reply :(

Yes I think all of this will be great @heitortsergent

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you both @mstoykov, @heitortsergent! 🙌🏻 That makes lot of sense to me!
So, I have updated the changes accordingly.

- Exactly 900 iterations are started in total, `30s * 30 iters/s`.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the `maxVUs`. For this test, this ended up as 17 VUs.
- The number of VUs to achieve the desired rate varies depending on how long each iteration takes to execute. For this test definition, if it would take exactly 1 second, then 30 VUs would be needed. However, as it takes less than 1 second, then less VUs are needed.

> Using too low of a `preAllocatedVUs` setting will reduce the test duration at the desired rate, as resources need to continually be allocated to achieve the rate.
16 changes: 10 additions & 6 deletions docs/sources/v0.48.x/using-k6/scenarios/executors/constant-arrival-rate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Besides the [common configuration options](https://grafana.com/docs/k6/<K6_VERSI
this executor has the following options:

| Option | Type | Description | Default |
| ------------------------------------ | ------- | ------------------------------------------------------------------------------ | ----------------------------------- |
|--------------------------------------|---------|--------------------------------------------------------------------------------|-------------------------------------|
| duration<sup>(required)</sup> | string | Total scenario duration (excluding `gracefulStop`). | - |
| rate<sup>(required)</sup> | integer | Number of iterations to start during each `timeUnit` period. | - |
| preAllocatedVUs<sup>(required)</sup> | integer | Number of VUs to pre-allocate before test start to preserve runtime resources. | - |
Expand All @@ -53,7 +53,7 @@ So it's unnecessary to use a `sleep()` function at the end of the VU code.
## Example

This example schedules a constant rate of 30 iterations per second for 30 seconds.
It allocates 50 VUs for k6 to dynamically use as needed.
It pre-allocates 2 VUs, and allows k6 to dynamically schedule up to 50 VUs as needed.

{{< code >}}

Expand All @@ -75,8 +75,12 @@ export const options = {
// Start `rate` iterations per second
timeUnit: '1s',

// Pre-allocate VUs
preAllocatedVUs: 50,
// Pre-allocate 2 VUs before starting the test
preAllocatedVUs: 2,

// Spin up a maximum of 50 VUs to sustain the defined
// constant arrival rate.
maxVUs: 50,
},
},
};
Expand All @@ -98,7 +102,7 @@ Based upon our test scenario inputs and results:

- The desired rate of 30 iterations started every 1 second is achieved and maintained for the majority of the test.
- The test scenario runs for the specified 30 second duration.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the allocated number. For this test, this ended up as 17 VUs.
- Exactly 900 iterations are started in total, `30s * 30 iters/s`.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the `maxVUs`. For this test, this ended up as 17 VUs.
- The number of VUs to achieve the desired rate varies depending on how long each iteration takes to execute. For this test definition, if it would take exactly 1 second, then 30 VUs would be needed. However, as it takes less than 1 second, then less VUs are needed.

> Using too low of a `preAllocatedVUs` setting will reduce the test duration at the desired rate, as resources need to continually be allocated to achieve the rate.
14 changes: 9 additions & 5 deletions docs/sources/v0.49.x/using-k6/scenarios/executors/constant-arrival-rate.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ So it's unnecessary to use a `sleep()` function at the end of the VU code.
## Example

This example schedules a constant rate of 30 iterations per second for 30 seconds.
It allocates 50 VUs for k6 to dynamically use as needed.
It pre-allocates 2 VUs, and allows k6 to dynamically schedule up to 50 VUs as needed.

{{< code >}}

Expand All @@ -75,8 +75,12 @@ export const options = {
// Start `rate` iterations per second
timeUnit: '1s',

// Pre-allocate VUs
preAllocatedVUs: 50,
// Pre-allocate 2 VUs before starting the test
preAllocatedVUs: 2,

// Spin up a maximum of 50 VUs to sustain the defined
// constant arrival rate.
maxVUs: 50,
},
},
};
Expand All @@ -98,7 +102,7 @@ Based upon our test scenario inputs and results:

- The desired rate of 30 iterations started every 1 second is achieved and maintained for the majority of the test.
- The test scenario runs for the specified 30 second duration.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the allocated number. For this test, this ended up as 17 VUs.
- Exactly 900 iterations are started in total, `30s * 30 iters/s`.
- Having started with 2 VUs (as specified by the `preAllocatedVUs` option), k6 automatically adjusts the number of VUs to achieve the desired rate, up to the `maxVUs`. For this test, this ended up as 17 VUs.
- The number of VUs to achieve the desired rate varies depending on how long each iteration takes to execute. For this test definition, if it would take exactly 1 second, then 30 VUs would be needed. However, as it takes less than 1 second, then less VUs are needed.

> Using too low of a `preAllocatedVUs` setting will reduce the test duration at the desired rate, as resources need to continually be allocated to achieve the rate.
Loading