Sleep isn't needed at end of arrival rate iter #1008
Conversation
| @@ -40,7 +39,15 @@ this executor has the following options: | |||
| ## When to use | |||
|
|
|||
| When you want to maintain a constant number of iterations without being affected by the | |||
| performance of the system under test. | |||
| performance of the system under test. To reliably achieve a fixed request rate, try to keep test function simple, with preferably only a single request call, | |||
There was a problem hiding this comment.
I don't think that recommending to only have 1 request is a good thing. While this will simplify calculating how many VUs you need in normal cases it :
- in practice makes it seem like the executor can't handle anything more complicated, which is far from the truth
- again in the case that the SUT is failing the "request should take no more than 1s" thinking is still not going to fix anything when it is taking 1m ;)
There was a problem hiding this comment.
Yeah I just moved that from the old section; it struck me as pretty much invalidating all complex uses of arrival rate. Will delete.
|
There's a version of the docs published here: https://mdr-ci.staging.k6.io/docs/refs/pull/1008/merge It will be deleted automatically in 30 days. |
...kdown/translated-guides/en/02 Using k6/14 Scenarios/01 Executors/05 constant-arrival-rate.md
Outdated
Show resolved
Hide resolved
|
One other thing to note, I wrote "It's unneeded" whereas @sniku wrote "It's a bad idea". We can make the wording a little stronger if the reason it is a bad idea is something more than "It's unnecessary." But if we do that, we should also explain a bit more. |
...kdown/translated-guides/en/02 Using k6/14 Scenarios/01 Executors/05 constant-arrival-rate.md
Outdated
Show resolved
Hide resolved
…s/01 Executors/05 constant-arrival-rate.md Co-authored-by: Mihail Stoykov <[email protected]>
I forgot to remove the comments in #1008, causing incoherence.
From discussion in #900