Testing each group with different throughput

Grafana k6 OSS Support
1

I have an API which contains 6 endpoints. My target is to reach 10x throughput for all endpoints, but the issue is that each endpoint has its own target, as follows:

  • api/Get > current rpm 2k > targeted rpm is 20k
  • api/GetMany > current rpm 800 > targeted rpm 8k

Because it doesn’t make any sense to put all endpoints/groups in one single file/script and all gets the same throughput, I had to separate them each in a separate file.

What I wanna do is having all groups in one script, but all runs and stops based on specific stage

2

What you need can currently be approximated roughly with the __ITER and/or __VU execution context variables. Have a single default function that has something like this:

if (__ITER % 3 == 0) {
  CallGetManyUsers(); // 33% of iterations
} else {
  CallGetUser(); // 66% of iterations
}

In the very near future we plan to also add a more elegant way of supporting multi-scenario tests in a single script: https://github.com/loadimpact/k6/pull/1007

What I wanna do is having all groups in one script, but all runs and stops based on specific stage

I don’t quite understand what you mean by this, sorry. Can you elaborate a bit more?

3

Hi,
What I meant is:
Let’s assume that I am targeting separate traffic for each of 2 different endpoints I have in my API as follows:

  • api/Get > 5k request/second
  • api/GetMany > 1k request/second

To achieve this now, I have to write both in different scripts and setup the stages with proper duration along with the proper ramp up to get this done.

What I aim to do is writing both tests in one single script and give each one the stages which can lead to have the targeted RPSs, or in other words, how can I check and stop calling a method (endpoint under test) when it reached specific count of calls/executions/invocations?

Hope this clarifies my question!

4

Yes, I think I understand your use case now. Unfortunately, both of the features you require (arrival-rate based execution and multiple scenarios/endpoints in the same script but with different scaling) are currently under active development in https://github.com/loadimpact/k6/pull/1007.

You can use some of the currently available k6 features (the aforementioned execution context variables and the rps script option) to somewhat approximate these, but your script is going to end up very hacky and probably not exactly right…

5

After a long delay, k6 v0.27.0 was just released and it includes arrival-rate based execution: