4

I have a api endpoint that each request need to be a different id , but how to make a id global and sequentual increment for each iteration shared for all VU, like a primary key on database table.

Ex:

request 1 : <id>400</id> VU :1
request 2 : <id>401</id> VU :1

request 1 : <id>402</id> VU :2

request 3 : <id>403</id> VU :1
request 4 : <id>404</id> VU :1

request 2 : <id>405</id> VU :2
request 3 : <id>406</id> VU :2

Is there any way to declare a variable that is shared by the entire test? Setup and Init are for each VU and cannot share data according to the documentation.

J.Sperandio
  • 87
  • 1
  • 10

2 Answers2

10

For anyone looking for a way to generate sequential numbers. Since version v0.0.34, k6/execution has been introduced that has a property iterationInTest that is an integer described as:

The unique and zero-based sequential number of the current iteration in the scenario. It is unique in all k6 execution modes - in local, cloud and distributed/segmented test runs. However, while every instance will get non-overlapping index values in cloud/distributed tests, they might iterate over them at different speeds, so the values won't be sequential across them.

This can be used in your test code to generate sequential numbers such as:

import exec from 'k6/execution':

export default function () {
  const url = `https://foo.bar/${exec.scenario.iterationInTest}`;
  http.get(url)
}

I was able to use to increment a number for each iteration of the test.

cigien
  • 57,834
  • 11
  • 73
  • 112
Alexander Staroselsky
  • 37,209
  • 15
  • 79
  • 91
3

This is not easily possible because each VU runs in a separate JavaScript VM and memory is not shared between them. See the Test life cycle documentation for details. This is done to allow test runs to be distributed across k6 instances, so synchronizing data across them will require an external solution.

One approach you could take is to keep track of and increment the ID in a web service that your k6 script can query to get the next ID from. Redis could serve this purpose well, see this related answer for ideas. But note that any such solution will impact your end-of-test test metrics and the performance of the test itself, so it's not ideal, but I don't see a better approach.

imiric
  • 8,315
  • 4
  • 35
  • 39