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

Reworks "life cycle" explanation page #624

Closed
wants to merge 15 commits into from
Closed

Reworks "life cycle" explanation page #624

Changes from 1 commit
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
931ba19
Reworks "life cycle" explanation page
MattDodsonEnglish Apr 18, 2022
9c5cd2f
life cycle, makes list consistent and parallel
MattDodsonEnglish Apr 18, 2022
3784c54
life-cycle, restructures section and table
MattDodsonEnglish Apr 18, 2022
a1fb10c
Makes table more accurate
MattDodsonEnglish Apr 19, 2022
9508949
life-cycle, removes unnecessary details
MattDodsonEnglish Apr 19, 2022
9638337
life-cycle, more informative intro
MattDodsonEnglish Apr 19, 2022
85bef48
fixes nested bullets
MattDodsonEnglish Apr 19, 2022
534db8c
lifecycle, restructure, adds diagram and def list
MattDodsonEnglish Apr 22, 2022
09a9bb7
small text fixes
MattDodsonEnglish Apr 22, 2022
5201831
life cycle; removes unneeded info
MattDodsonEnglish Apr 25, 2022
0bdedcf
better init code example
MattDodsonEnglish Apr 25, 2022
894e68d
Better summary of how performance improves
MattDodsonEnglish Apr 25, 2022
6ce0d9e
Merge branch 'main' into lifecycle-edits
MattDodsonEnglish Apr 25, 2022
72712b9
Merge branch 'lifecycle-edits'
MattDodsonEnglish Apr 25, 2022
e86434d
Merge branch 'main' into lifecycle-edits
MattDodsonEnglish Apr 25, 2022
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
15 changes: 3 additions & 12 deletions src/data/markdown/translated-guides/en/02 Using k6/06 Test life cycle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,9 +38,9 @@ The rest of this page goes into deeper technical detail.

| Test stage | Used to | Example | Called | Required? |
|-----------------|------------------------------------------------------------|-----------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|-----------|
| **1. init** | Load local files, import modules, declare global variables | Open JSON file, Import module | Once per VU\* | Optional |
| **1. init** | Load local files, import modules, declare global variables | Open JSON file, Import module | Once per VU\* | Required |
| **2. Setup** | Set up data for processing, share data among VUs | Call API to start test environment | Once | Optional |
| **3. VU code** | Run the test function, usually the `default` one | Make https requests, validate responses | Once per iteration, as many times as the test options required | Required |
| **3. VU code** | Run the test function, usually `default` | Make https requests, validate responses | Once per iteration, as many times as the test options require | Required |
| **4. Teardown** | Process result of setup code, stop test environment | Validate that setup had a certain result, send webhook notifying that test has finished | Once per script | Optional |

\* In cloud scripts, init code might be called more often.
Expand Down Expand Up @@ -132,8 +132,6 @@ But unlike the `default` function, k6 calls `setup` and `teardown` only once per
* `setup` is called at the beginning of the test, after the init stage but before the VU stage.
* `teardown` is called at the end of a test, after the VU stage (`default` function).

The VU number is 0 while the `setup` and `teardown` functions execute.

Again, let's have a look at the basic structure of a k6 test:

<CodeGroup labels={["Setup/Teardown"]} lineNumbers={[true]}>
Expand All @@ -160,11 +158,8 @@ You might have noticed the function signatures of the `default` and `teardown` f
take an argument, referred to here as `data`.

This `data` is whatever the `setup` function returns.
Having a mechanism for passing data from the setup stage to the subsequent VU and teardown stages is compatible with our goal of supporting local, cloud, and clustered execution modes without requiring script changes when switching between them.
In cloud and clustered modes, the node that runs the setup code might not be the node that runs the teardown code.

To support these modes, you can pass only data (i.e. JSON) between `setup()` and the
other stages.
You can pass only data (i.e. JSON) between `setup()` and the other stages.
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe a note that it's a copy of what setup returns. So that it:

  1. uses more memory if it's big
  2. you can't actually change it in the VU code and see the changes in the teardown. Although any VU will see it's changes to the data. This though is likely to change as we might freeze the whole object just to make it less obvious that it won't work

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Although any VU will see it's changes to the data. This though is likely to change as we might freeze the whole object just to make it less obvious that it won't work

@mstoykov

Sorry, I'm a bit confused here. So, VU code can manipulate data from setup, but it can't pass that data to teardown. Is that correct?

And, in the table, I note that setup code can be used to " share data among VUs". How is this data shared. Is it from one VU to the next VU? Or does each VU grab "clean" data from the setup code?

However it works, it seems like, if VU code can manipulate data that doesn't end up in the teardown stage, then the data is not really "passed" from Setup to VU to Default.

Rather, setup passes data in two places. Once, directly to teardown. And once (or many times??) directly to default.

I've made a small diagram to illustrate how I conceive this. Excuse me, I'm sure said some inaccurate things here, but I thought it may be easier to correct than to explain :-) .

image

Copy link
Contributor

@mstoykov mstoykov Apr 20, 2022 •
edited
Loading

Choose a reason for hiding this comment

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

more or less -yes to all of those :).

In practice implementing data being modified and all that modifications being visible by :

  1. all VUs
  2. teardown

Will be ... extremely complicated and (computationally) expensive especially in distributed execution. Which is why we haven't even discussed it ever. But long long time ago I made fixes so that they have separate copies - previous to that this was sometimes panicking as multiple VUs were writing to the same not thread safe structure.

edit: the data is passed to each VU separately - but that shouldn't really be depended upon or documented. We do in general really want if it's a singel copy that is just unmodifiable.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Haha, this sounds pretty complicated. I think I'm just going to just suggest that it's a "copy," and leave it at that. Especially since it sounds like this data may get "frozen" in the VU stage in some later k6 version anyway.

For the people who are motivated enough to actually use this implementation in some advanced way, well they can look at the source code (and find this discussion). 🙂

You cannot pass functions.

Here's an example of passing some data from setup to VU and teardown stages:
Expand Down Expand Up @@ -213,10 +208,6 @@ export default function (data) {

</CodeGroup>

Note that the [the end-of-test summary](/results-visualization/end-of-test-summary/#summary-export-to-a-json-file) includes requests made in the setup and teardown stages.
These requests are tagged appropriately with the `::setup` and `::teardown` values
for the `group` metric tag, so that you can filter them in JSON output or InfluxDB.

## Skip setup and teardown execution
MattDodsonEnglish marked this conversation as resolved.
Show resolved Hide resolved

You can skip the execution of setup and teardown stages using the options `--no-setup` and
Expand Down