How to reuse __ITER in multiple unique scenarios?

Grafana k6 OSS Support
1

New to k6 - so maybe this is a dumb question.

I’m trying to compose a test that uses 2 scenarios.

  1. a create scenario that creates a series of instances.
  2. a delete scenario that (after a period of time) deletes the instances created in 1.

the code in the test is something like this:

import http from 'k6/http';
import {sleep} from 'k6';

export let options = {
  scenarios: {
    "createInstance": {
      exec: 'create',
      executor: "shared-iterations",
      vus: 1,
      iterations: 2,
      maxDuration: '2s',
      startTime: "0s"
    },
    "deleteInstance": {
      exec: 'delete',
      executor: "shared-iterations",
      vus: 1,
      iterations: 2,
      maxDuration: '2s',
      startTime: "60s"
    }
  }
};

export function create() {
  //Code executed for the userA workflow
  http.post('https://create_instance_${__ITER}');
  sleep(1);
}

export function delete() {
  //Code executed for the userB workflow
  http.get('https://delete_instance_${__ITER}');
}

The create function works as expected, it creates 2 instances:
instance_0
instance_1

But, delete function is trying to delete the next 2 instances:
instance_2
instance_3

But i want it to delete the instances:
instance_0
instance_1

Any suggestions as to what i’m doing wrong?

(btw this works as expected IF the delete scenario startTime is 5s. but not when it’s 60s…

3

Hi there, welcome to the forum :slight_smile:

What you’re trying to do is tricky in k6, because VUs and scenarios don’t share state between them. And in this case you do want to know exactly which instances were created, so that you can delete them later.

__ITER won’t help you with this, since it’s an increasing iteration number per VU, and you would get collisions as soon as you use more than 1 VU. The reason this appears to work if you start the second scenario at 5s, but not at 60s, is that after 60s the VUs from the first scenario are returned to the global VU pool, and the second scenario is reusing them, so __ITER from these original VUs are then incremented. Whereas with 5s both scenarios use different VUs.

BTW, the use of __ITER is discouraged, and you should use the k6/execution module instead. There you have more variables, such as iterationInInstance and iterationInTest, which wouldn’t cause collisions, but would still be unsuitable for what you want to do.

Take a look at this similar question. There are several solutions mentioned there. One approach that would work for you is to use Redis with our experimental module. You could use the RPUSH command to keep track of all created instances, and then do an LRANGE to get the list in the teardown() function and delete them all. If you need to keep track of a monotonically increasing counter across all VUs and scenarios, consider using the xk6-counter extension.

Hope this helps!

1 Like
4

Great - thanks for the really detailed response @imiric.

I think xk6-counter extension looks like my best bet - i’ll give it a try.

Thanks again.

2 Likes