[Feat] add example to split logic across VUs #1179
Conversation
|
There's a version of the docs published here: https://mdr-ci.staging.k6.io/docs/refs/pull/1179/merge It will be deleted automatically in 30 days. |
src/data/markdown/docs/05 Examples/01 Examples/24 distribute-workloads.md
Outdated
Show resolved
Hide resolved
| } | ||
| ``` | ||
|
|
||
| ### Tip: reduce scenario boilerplate with `new` |
There was a problem hiding this comment.
For simplicity and less info overhead, I'd consider removing this section with the Tip.
There was a problem hiding this comment.
I also think this will probably be better off in the scenario docs or at least to be collapsed by default.
Also related to grafana/k6#974
There was a problem hiding this comment.
Yeah, now I see that this section distorts the docs purpose: show ways to split logic.
It's also more about general JavaScript practices, and I realized that the docs always trust that the reader can write tests according to their preferred JavaScript techniques. This is definitely a fair assumption, but, given that many k6 users don't otherwise use JavaScript in their daily operations, perhaps it'd be nice to have a blog post showing ways to use es6 tricks to refactor test scripts.
|
|
||
|
|
||
| To view granular results for a specific scenario, you can filter results by the built in scenario [tag](/using-k6/tags-and-groups). | ||
| For example, this command uses `jq` to filter only data points for the scenario with the name "news". |
There was a problem hiding this comment.
The jq instruction seems out of context.
There was a problem hiding this comment.
I think either delete it entirely or move it to the end of the scenarios section.
|
|
||
| For a more sophisticated example of randomizing, read this [forum post](https://community.k6.io/t/how-to-distribute-vus-across-different-scenarios-with-k6/49/17). | ||
|
|
||
| ## Inspect results by behavior |
There was a problem hiding this comment.
This section could include a little more explanations. For example:
- Mention that when splitting across scenarios, the Scenario assign automatically the scenario
tagto built-in metrics. - Provide or point an alternative for the other options/examples.
|
|
||
|
|
||
| One way to distribute traffic is to use scenarios to schedule different workloads for different functions. | ||
| 1. Define multiple scenarios in your `options.scenarios` object. |
There was a problem hiding this comment.
I will probably nto call it an object but will link to the configuraiton docs
| } | ||
| ``` | ||
|
|
||
| ### Tip: reduce scenario boilerplate with `new` |
There was a problem hiding this comment.
I also think this will probably be better off in the scenario docs or at least to be collapsed by default.
Also related to grafana/k6#974
| contactWorkload, | ||
| newsWorkload, |
There was a problem hiding this comment.
nit: I would guess most people will find this syntax confusing, so using "contact": contactWorkload is likely better idea.
Also you don't really need a constructor and using new to be honest - you can just have a function (which you do).
There was a problem hiding this comment.
you don't really need a constructor and using new to be honest - you can just have a function (which you do)
I'm going to remove this section, as I commented https://github.com/grafana/k6-docs/pull/1179/files#r1196400374 ,
But as an aside, my understanding is that new is never necessary, but it helps make behavior more explicit. That's how I understand this page, https://javascript.info/constructor-new .
And I've seen new used in a few modern JS libraries so I assumed it was considered good practice.
src/data/markdown/docs/05 Examples/01 Examples/24 distribute-workloads.md
Outdated
Show resolved
Hide resolved
src/data/markdown/docs/05 Examples/01 Examples/24 distribute-workloads.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Pepe Cano <[email protected]>
Co-authored-by: Mihail Stoykov <[email protected]>
The idea is to provide a quick set of examples to solve a common question.