Configuration Ramping arrival rate

Grafana k6 OSS Support
,
1

Hello! Could you help me with configuring a scenario for K6 options? I believe that ramping-arrival-rate might meet the requirements I describe below, but I’m unsure if it would be the best solution.

I need to prepare a scenario where, initially, 50 (fifty) iterations are executed simultaneously. Every minute, a new round should be executed, increasing the number of iterations by 50, until reaching a maximum of 500 (five hundred) iterations.

With each new round, I cannot interrupt the processes from the previous round. It will be a gradual increase, and I need to wait for the results of all the iterations. I have prepared the scenario below. Would this be the best configuration for this case?

export const options = {
    discardResponseBodies: true,
  
    scenarios: {
      contacts: {
        executor: 'ramping-arrival-rate',
        startRate: 0,   
        timeUnit: '1m',
        preAllocatedVUs: 50,
        gracefulStop: '25m',
  
        stages: [
          { target: 50, duration: '1m' },  
          { target: 100, duration: '1m' }, 
          { target: 150, duration: '1m' }, 
          { target: 200, duration: '1m' }, 
          { target: 250, duration: '1m' }, 
          { target: 300, duration: '1m' }, 
          { target: 350, duration: '1m' }, 
          { target: 400, duration: '1m' }, 
          { target: 450, duration: '1m' }, 
          { target: 500, duration: '20m' },
        ],
      },
    },
  };
5

Hi @rodrigogrigoleto,

Welcome to our community, thanks for sharing your question here :tada:

First of all, sorry for the delayed answer, I think it got mixed across other threads and we lost track of it.

That said, I’ve been looking at the requirements you described, and the test definition you wrote, and I think it looks pretty accurate. However, there’s a couple of things I’d like to revisit/mention:

  • First, I see you specified a gracefulStop of 25m, but that seems to be a too much. Note that this is the period at the end of the test in which k6 lets iterations in progress finish (docs).

    So, although it’s true that it shouldn’t hurt, because I’d expect all iterations to finish much faster than in 25m, in case something gets stuck (e.g. an iteration stuck at a operation without a timeout), you test will wait up to 25m to finish, which in practice wouldn’t make sense, I think.

  • Second, I’d recommend you to pay attention to the preAllocateVUs. Because, although 50 might be enough for rates of 200, 300… up to 500 iterations per minute (timeUnit: '1m') if you’re just hitting a single, considerably fast endpoint, depending on what you do on each iteration (e.g. if it implies doing multiple HTTP requests, or even browser-related operations), it could be not enough. So, I suggest you to do some tests, check what’s the achieved rate, and adjust the preAllocateVUs accordingly with the results.

  • Finally, I see you last stage is { target: 500, duration: '20m' }, does that mean that after the “ramp up”, you want to keep the test running for 20m at a rate of 500 iterations per minute, is that correct? I just want to make sure, and remind you that, the target is the rate of iterations per minute, not the total amount of iterations that will be performed on the stage - and I don’t fully get if that’s what you want, from what you described.

I hope that helps! :pray:
Otherwise, feel free to reach me again with the doubts you still have.
I’ll be happy to try to help you :bowing_man:

Cheers!