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

Scenarios documentation #49

Merged
merged 25 commits into from
Jul 14, 2020
Merged

Scenarios documentation #49

merged 25 commits into from
Jul 14, 2020

Conversation

imiric
Copy link
Contributor

@imiric imiric commented Jun 26, 2020

This is an initial draft of the scenarios / new executors documentation, with likely many things missing, so just to get the ball rolling.

@imiric imiric requested review from mstoykov and na-- June 26, 2020 16:25
@mstoykov
Copy link
Contributor

mstoykov commented Jun 29, 2020

I would prefer if we move the default column commit in a separate PR that gets merged earlier and then this get rebased on it? saw the PR right after I commented, sorry ;) good job :P

Copy link
Contributor

@mstoykov mstoykov left a comment

Choose a reason for hiding this comment

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

Looks good, still needs more work :)
Things that I think are important:

  1. have a section explaining new concepts
  • arrival rate
  • gracefulStop/RampDown
  1. Have examples with probably what each executors is good for.
  • "If you want and then using this is good idea."

Comment on lines 143 to 153
Note that in order to reliably achieve a fixed request rate, it's recommended to keep
the function being executed very simple, with preferably only a single request call,
and no additional processing or `sleep()` calls.
Copy link
Contributor

Choose a reason for hiding this comment

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

While I agree having sleep is contra-productive in this case. Having complex functions with multiple requests isn't the problem - the problem is that the user needs to understand that a VU still needs to execute the iteration and they still can only execute 1 at time. So if there is a complex iteration taking 30seconds that isn't a problem if the requested iterations per second are 1 and we have 30-40 VUs.

So IMO we need to have a section on arrival rate and how it differs specifically from the other executors

Copy link
Contributor Author

Choose a reason for hiding this comment

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

👍 for the separate arrival rate section.

Would you or @robingustafsson volunteer for that? 😄 I could copy or paraphrase what Robin wrote in grafana/k6#550, but you guys have a better grasp of this and will probably explain it better.

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 added a placeholder for the arrival rate section in 95f1187.

Comment on lines 155 to 168
constant_arr_rate: { // arbitrary scenario name
executor: 'constant-arrival-rate',
rate: 200,
timeUnit: '1s',
duration: '1m',
preAllocatedVUs: 50,
maxVUs: 100,
Copy link
Contributor

Choose a reason for hiding this comment

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

  • can you drop the timeUnit as this is its the default value (maybe add a comment next to the rate)
  • can we give the scenario an arbitrary name? and then still have the comment. This way it is more obvious :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hah I thought this one is obviously arbitrary but maybe not :)

Let me know if f99fbf3 is an improvement.

executor: 'constant-vus',
exec: 'scenario1',
vus: 50,
duration: '30s',
Copy link
Contributor

Choose a reason for hiding this comment

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

There will need to be gracefulStop:0s here in order for the 50VUs to stop executing at exactly 30s

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 would rather not introduce gracefulStop here since this example already showcases a couple of features, and gracefulStop would need a more thorough explanation. And it wasn't meant to stop at exactly 30s. :)

So let's use gracefulStop in a separate example in that new gracefulStop/RampDown section you mentioned.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

See the gracefulStop section added in 72d17e4.

Comment on lines 278 to 279
tags: { scenario: '2' },
env: { SCENARIO: '2' },
Copy link
Contributor

Choose a reason for hiding this comment

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

if we are going to be setting those in k6 it's probably not a good idea to give examples like that ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hah true, though I wrote this before the default scenario tag feature, and well, because of lack of imagination :)

I changed it slightly in f99fbf3, but let me know if you have a better idea.

@imiric imiric force-pushed the docs/new-executors branch from 4b34af0 to f99fbf3 Compare July 1, 2020 10:00
Copy link
Member

@robingustafsson robingustafsson left a comment

Choose a reason for hiding this comment

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

This is a really good start @imiric! As I wrote in one of my comments I can take a stab at the arrival rate section.


## Arrival rate

TODO (expand on https://github.com/loadimpact/k6/issues/550)
Copy link
Member

Choose a reason for hiding this comment

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

I can take a stab at writing this section intro if you want.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks, I think that would be best as you have more knowledge about the topic. I'd just be paraphrasing :)

Copy link
Member

Choose a reason for hiding this comment

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

Ok, have pushed a first draft of content for the arrival rate section now :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That looks great, the examples make it very easy to understand. Just fixed a couple of typos :)

@@ -0,0 +1,535 @@
---
title: Executors
Copy link
Member

Choose a reason for hiding this comment

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

I think we should either call this guide "Scenarios" and rework the page a little bit to first talk about scenarios as a concept and explaining multi-scenario tests before going into the details of each executor which is a setting for a scenario, or we should introduce a new guide called "Scenarios" that is introduced before this guide that talks about scenarios as a concept etc. linking to this guide for more details.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense. The feature as a whole is "scenarios", and "executors" are a (crucial) part that make them possible, so we should mention and list them, but not make it the focal point of the article.

I'll see what I can add in the intro, and we can expand it to a standalone article if needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@robingustafsson Let me know if 17b520a is sufficient for what you had in mind. I think this is a gentler introduction, focusing on the benefits of scenarios and a general configuration example before going into details with executors. I'm not sure what else we can mention there, so maybe it doesn't need a separate article?


</div>

Note that by default a `scenario` tag with the name of the scenario as value is
Copy link
Contributor

Choose a reason for hiding this comment

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

This should probably be added to the list of tags somewhere else in the documentation

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 added it to the default list of --system-tags on the Options page. Or do you mean somewhere else?

Copy link
Contributor

Choose a reason for hiding this comment

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

in the tags and groups ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, see 8c0ee99.

k6 v0.27.0 introduces the concept of _executors_: configurable modes of executing a
JavaScript function that can model diverse traffic scenarios in load tests.

Multiple executors can be used in the same script, they can be scheduled to run
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
Multiple executors can be used in the same script, they can be scheduled to run
Multiple executors can be used in the same script, they can be scheduled to run in

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 reworked the intro somewhat to focus on scenarios, and now it's "run in sequence or parallel". Not sure if a second "in" is needed before "parallel", but DRY? 😄

@imiric
Copy link
Contributor Author

imiric commented Jul 10, 2020

@mstoykov See the "When to use" sections added in ee1e8aa, to address your original suggestion, which is a good idea. Not sure if it's detailed enough, but let me know.

@imiric imiric changed the title [WIP] New executors documentation [WIP] Scenarios documentation Jul 10, 2020
Ivan Mirić added 2 commits July 10, 2020 16:27
This is already explained in the first example.
Copy link
Member

@na-- na-- left a comment

Choose a reason for hiding this comment

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

I have quite a bit of minor nitpicks as inline comments and code suggestions, but overall I think the new docs are awesome ❤️

@imiric
Copy link
Contributor Author

imiric commented Jul 10, 2020

I think we're missing an article about the --execution-segment/--execution-segment-sequence options (or "Distributed execution" in general) in addition to what's mentioned on the Options page, with more examples, etc. Unless we shouldn't advertise that much? 😄

@na-- Would you volunteer to write that? :) It can probably wait after v0.27.0 is released, don't think a lot of people will notice or use it at first.

@na--
Copy link
Member

na-- commented Jul 13, 2020

I can write it, but it's definitely something for after 0.27.0. It will probably only matter when we also have data segmentation for most people, so for now the brief mention in the options page should be enough. If anyone wants more details, they can read through the issues and PRs, for now 😅

@imiric imiric changed the title [WIP] Scenarios documentation Scenarios documentation Jul 13, 2020
@imiric imiric marked this pull request as ready for review July 13, 2020 13:17
@na--
Copy link
Member

na-- commented Jul 14, 2020

Making a final skimming read through the docs, so far LGTM, but noticed we lack dropped_iterations in https://github.com/loadimpact/k6-docs/blob/master/src/data/markdown/docs/01%20guides/02%20Using%20k6/02%20Metrics.md

Its description should be something like "Introduced in k6 v0.27.0, the number of iterations that could not be started due to lack of VUs (for the arrival-rate executors) or lack of time (due to expired maxDuration in the iteration-based executors)."

Copy link
Member

@na-- na-- left a comment

Choose a reason for hiding this comment

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

LGTM. We probably should include more (and more varied) examples and maybe some more advice to users, but that can come in the form of blog posts, or future PRs here.

@imiric imiric merged commit cb7c3ea into develop Jul 14, 2020
@imiric imiric deleted the docs/new-executors branch July 14, 2020 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants