From 98081501e125a94f78a294261a2ffa9cc339d27b Mon Sep 17 00:00:00 2001
From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com>
Date: Tue, 6 Dec 2022 08:49:55 -0300
Subject: [PATCH 01/17] scenarios, clean up arrival rate doc
- General edits and sentence shortening
- mention coordinated omission to close #231
---
.../14 Scenarios/04 Arrival Rate.md | 50 +++++++++++--------
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md
index 6b0bbf0e8b..04c6ceaa6a 100644
--- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md
+++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md
@@ -3,15 +3,22 @@ title: 'Arrival rate'
excerpt: 'In k6, we have implemented this open model with our two arrival rate executors: constant-arrival-rate and ramping-arrival-rate.'
---
+Different k6 executors have different ways of scheduling VUs.
+Some executors use the _closed model_, while the arrival rate executors use the _open model_.
+
+In short, in the closed model, VU iterations start only when the last iteration finishes.
+In the open model, on the other hand, VUs arrive independently of iteration completion.
+Different models suit different test aims.
+
## Closed Model
-> In a closed model, the execution time of each iteration dictates the actual
-> number of iterations executed in your test, as the next iteration won't be started
-> until the previous one is completed.
+In a closed model, the execution time of each iteration dictates the
+number of iterations executed in your test.
+The next iteration doesn't started until the previous one finishes.
-Prior to v0.27.0, k6 only supported a closed model for the simulation of new VU arrivals.
-In this closed model, a new VU iteration only starts when a VU's previous iteration has
-completed its execution. Thus, in a closed model, the start rate, or arrival rate, of
+Prior to v0.27.0, k6 supported only a closed model to simulate new VU arrivals.
+In this closed model, a new VU iteration starts only when a previous iteration finishes.
+Thus, in a closed model, the start or arrival rate of
new VU iterations is tightly coupled with the iteration duration (that is, time from start
to finish of the VU's `exec` function, by default the `export default function`):
@@ -53,32 +60,35 @@ closed_model ✓ [======================================] 1 VUs 1m0s
```
-## Drawbacks of using the closed model
+### Drawbacks of using the closed model
-This tight coupling between the VU iteration duration and start of new VU iterations
-in effect means that the target system can influence the throughput of the test, via
-its response time. Slower response times means longer iterations and a lower arrival
-rate of new iterations, and vice versa for faster response times.
+When the duration of the VU iteration is tightly coupled to the start of new VU iterations,
+the target system's response time can influence the throughput of the test.
+Slower response times means longer iterations and a lower arrival rate of new iterations—and vice versa for faster response times.
+In some testing literature, this problem is known as _coordinated omission._
-In other words, when the target system is being stressed and starts to respond more
-slowly a closed model load test will play "nice" and wait, resulting in increased
+In other words, when the target system is stressed and starts to respond more
+slowly, a closed model load test will wait, resulting in increased
iteration durations and a tapering off of the arrival rate of new VU iterations.
-This is not ideal when the goal is to simulate a certain arrival rate of new VUs,
+This effect is not ideal when the goal is to simulate a certain arrival rate of new VUs,
or more generally throughput (e.g. requests per second).
## Open model
-> Compared to the closed model, the open model decouples VU iterations from
-> the actual iteration duration. The response times of the target system are no longer
-> influencing the load being put on the target system.
+Compared to the closed model, the open model decouples VU iterations from
+the iteration duration.
+The response times of the target system no longer
+influence the load on the target system.
-To fix this problem we use an open model, decoupling the start of new VU iterations
-from the iteration duration and the influence of the target system's response time.
+To fix this problem of coordination, you can use an open model,
+which decouples the start of new VU iterations
+from the iteration duration.
+This reduces the influence of the target system's response time.
![Arrival rate closed/open models](../images/Scenarios/arrival-rate-open-closed-model.png)
-In k6, we've implemented this open model with our two "arrival rate" executors:
+k6 implements the open model with two __arrival rate_ executors:
[constant-arrival-rate](/using-k6/scenarios/executors/constant-arrival-rate) and [ramping-arrival-rate](/using-k6/scenarios/executors/ramping-arrival-rate):
+ +By default, a `scenario` tag with the name of the scenario as value is +applied to all metrics in each scenario. +You can combine these tags with thresholds, +or use them to simplify metric filtering in [result outputs](/get-started/results-output). + +You can disable scenario tags with the [`--system-tags` option](/using-k6/options#system-tags). + ++ +## Run multiple scenario functions, with different thresholds -## Multiple exec functions, tags, environment variables, and thresholds +You can use scenario names to run multiple VU [lifecycle functions](/using-k6/test-lifecycle). +What's more, you can set different thresholds for different scenario functions. +To do this: +1. Set scenario-specific tags +1. Set thresholds for these tags. -A test with 3 scenarios, each with different `exec` functions, tags and environment variables, and thresholds: +This test has 3 scenarios, each with different `exec` functions, tags and environment variables, and thresholds:
-By default, a `scenario` tag with the name of the scenario as value is +By default, a `scenario` tag, whose value is the scenario name, is applied to all metrics in each scenario. You can combine these tags with thresholds, or use them to simplify metric filtering in [result outputs](/get-started/results-output). From a78d686b7ccc4bb54473223d81ea9cf41f6e0af6 Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Tue, 6 Dec 2022 09:37:24 -0300 Subject: [PATCH 05/17] scenario example, shorten text --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 589a342dc0..645acd42cc 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -114,7 +114,7 @@ applied to all metrics in each scenario. You can combine these tags with thresholds, or use them to simplify metric filtering in [result outputs](/get-started/results-output). -You can disable scenario tags with the [`--system-tags` option](/using-k6/options#system-tags). +To disable scenario tags, use the [`--system-tags` option](/using-k6/options#system-tags).From fe8c6199487006fb63059fbe5efdd4c98f5d5a94 Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Tue, 13 Dec 2022 07:57:33 -0300 Subject: [PATCH 06/17] Scenario examples, language clean up --- .../02 Using k6/14 Scenarios/02 Advanced Examples.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 645acd42cc..7916c8a0f6 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -3,12 +3,14 @@ title: 'Advanced Examples' excerpt: 'Advanced Examples using the k6 Scenario API - Using multiple scenarios, different environment variables and tags per scenario.' --- -Besides making it easier to model workloads, scenarios have a second benefit of adding separation of test logic. -As you can split scenarios across in different VU [lifecycle functions](/using-k6/test-lifecycle), -you can use scenarios to: +You can use multiple scenarios in one script, and these scenarios can be run in sequence or in parallel. +So besides helping you model workloads, scenarios can also help you make more flexible and composable test logic. +Some ways that you can use scenarios include the following: - Sequence workloads - Add per-scenario tags and environment variables - Make scenario-specific thresholds. +- Run scenarios in different VU [lifecycle functions](/using-k6/test-lifecycle), + ## Sequence multiple scenarios @@ -60,8 +62,8 @@ export function news() { ## Use different environment variables and tags per scenario. -The previous example set tags on individual HTTP request metrics, but this -can also be done per scenario, which would apply them to other +The previous example set tags on individual HTTP request metrics. +But, you can also set tags per scenario, which applies them to other [taggable](/using-k6/tags-and-groups#tags) objects as well.
-By default, a `scenario` tag, whose value is the scenario name, is -applied to all metrics in each scenario. -You can combine these tags with thresholds, -or use them to simplify metric filtering in [result outputs](/get-started/results-output). +By default, k6 applies a `scenario` tag to all metrics in each scenario (the value is the scenario name. +You can combine these tags with thresholds, or use them to simplify results filtering. To disable scenario tags, use the [`--system-tags` option](/using-k6/options#system-tags). diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md index 366e9d7792..2f73a2f2bd 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/04 Arrival Rate.md @@ -14,7 +14,7 @@ Different models suit different test aims. In a closed model, the execution time of each iteration dictates the number of iterations executed in your test. -The next iteration doesn't started until the previous one finishes. +The next iteration doesn't start until the previous one finishes. Thus, in a closed model, the start or arrival rate of new VU iterations is tightly coupled with the iteration duration (that is, time from start @@ -80,13 +80,12 @@ The response times of the target system no longer influence the load on the target system. To fix this problem of coordination, you can use an open model, -which decouples the start of new VU iterations -from the iteration duration. +which decouples the start of new VU iterations from the iteration duration. This reduces the influence of the target system's response time. ![Arrival rate closed/open models](../images/Scenarios/arrival-rate-open-closed-model.png) -k6 implements the open model with two __arrival rate_ executors: +k6 implements the open model with two _arrival rate_ executors: [constant-arrival-rate](/using-k6/scenarios/executors/constant-arrival-rate) and [ramping-arrival-rate](/using-k6/scenarios/executors/ramping-arrival-rate):From bfb7dcccecba668f294217f51144fdd4e6c7f276 Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Thu, 15 Dec 2022 12:24:32 -0300 Subject: [PATCH 12/17] typo fix Co-authored-by: na-- --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 901efb9fb1..35f54c8909 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -59,7 +59,7 @@ export function news() { ## Use different environment variables and tags per scenario. -The previous example set tags on individual HTTP request metrics. +The previous example sets tags on individual HTTP request metrics. But, you can also set tags per scenario, which applies them to other [taggable](/using-k6/tags-and-groups#tags) objects as well. From 150d401d621ff5af11cbadb5bd0a24c51ffe304b Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Thu, 15 Dec 2022 15:57:23 -0300 Subject: [PATCH 13/17] Update src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md Co-authored-by: na-- --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 35f54c8909..2142957a48 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -5,7 +5,7 @@ excerpt: 'Advanced Examples using the k6 Scenario API - Using multiple scenarios You can use multiple scenarios in one script, and these scenarios can be run in sequence or in parallel. Some ways that you can combine scenarios include the following: -- Sequence workload start times +- Have different start times to sequence workloads - Add per-scenario tags and environment variables - Make scenario-specific thresholds. - Run scenarios in different VU [lifecycle functions](/using-k6/test-lifecycle). From 3c8c0f332225d3df1e5c62cda49d1be04522bc00 Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Fri, 16 Dec 2022 11:57:33 -0300 Subject: [PATCH 14/17] Scenario, more precise description --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 2142957a48..4012015ac4 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -8,7 +8,7 @@ Some ways that you can combine scenarios include the following: - Have different start times to sequence workloads - Add per-scenario tags and environment variables - Make scenario-specific thresholds. -- Run scenarios in different VU [lifecycle functions](/using-k6/test-lifecycle). +- Export multiple scenarios as functions in [VU code](/using-k6/test-lifecycle) ## Combine scenarios From 79e817bd4653ba92c0068ceb355bf5b833542c1b Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Fri, 16 Dec 2022 12:02:16 -0300 Subject: [PATCH 15/17] Formatting fixes --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 4012015ac4..2de270bf19 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -8,7 +8,7 @@ Some ways that you can combine scenarios include the following: - Have different start times to sequence workloads - Add per-scenario tags and environment variables - Make scenario-specific thresholds. -- Export multiple scenarios as functions in [VU code](/using-k6/test-lifecycle) +- Export multiple scenarios as functions in [VU code](/using-k6/test-lifecycle). ## Combine scenarios From 2f0a52c5daeac49425bba0239f776277421180cc Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Fri, 16 Dec 2022 13:32:59 -0300 Subject: [PATCH 16/17] Improve description of splitting logic Co-authored-by: na-- --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 2de270bf19..2abf2ea860 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -8,7 +8,7 @@ Some ways that you can combine scenarios include the following: - Have different start times to sequence workloads - Add per-scenario tags and environment variables - Make scenario-specific thresholds. -- Export multiple scenarios as functions in [VU code](/using-k6/test-lifecycle). +Use multiple scenarios to run different test logic, so that VUs don't run only the `default` function](https://k6.io/docs/using-k6/test-lifecycle/). ## Combine scenarios From a2d3c45bbfeb1516bdbc75e4c2bb5c629be8d70d Mon Sep 17 00:00:00 2001 From: Matt Dodson <47385188+MattDodsonEnglish@users.noreply.github.com> Date: Mon, 19 Dec 2022 07:47:30 -0300 Subject: [PATCH 17/17] formatting fix Co-authored-by: na-- --- .../en/02 Using k6/14 Scenarios/02 Advanced Examples.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md index 2abf2ea860..5f193a7025 100644 --- a/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md +++ b/src/data/markdown/translated-guides/en/02 Using k6/14 Scenarios/02 Advanced Examples.md @@ -8,7 +8,7 @@ Some ways that you can combine scenarios include the following: - Have different start times to sequence workloads - Add per-scenario tags and environment variables - Make scenario-specific thresholds. -Use multiple scenarios to run different test logic, so that VUs don't run only the `default` function](https://k6.io/docs/using-k6/test-lifecycle/). + - Use multiple scenarios to run different test logic, so that VUs don't run only the `default` function](https://k6.io/docs/using-k6/test-lifecycle/). ## Combine scenarios