CODEWITHSUNDEEP
load-testingk6
An old man in the sea.
An old man in the sea.

Reputation: 1508

How to create the following test scenario in k6?

My default function is just an http post request.

I would like to test if my app is able to deal with the following scenario:

I'm not sure whether to use ramping-arrival-rate, or ramping-vus

Here's an example of what I used for the first option.

export const options = {
  scenarios: {
    contacts: {
      executor: 'ramping-arrival-rate',
      timeUnit: '1s',
      preAllocatedVUs: 10,
      maxVUs: 200,
      stages: [
        { target: 5, duration: '2s' },
        { target: 15, duration: '10s' },
        { target: 20, duration: '5s' },
        { target: 0, duration: '10s' },
      ],
    },
  },
  thresholds: {
    http_req_duration: ['p(95)<60000'], //units in miliseconds 60000ms = 1m 
    http_req_failed: ['rate<0.01'], // http errors should be less than 1%
    checks: ["rate>0.99"]
  },
};

The strange thing is that I'm not exactly sure if I'm doing something wrong, in light of the results I get:

http_reqs......................: 4       0.070166/s
     iteration_duration.............: avg=41.13s   min=24.94s   med=42.3s    max=54.98s   p(90)=53.5s    p(95)=54.24s  
     iterations.....................: 4       0.070166/s
     vus............................: 126     min=10     max=126
     vus_max........................: 126     min=10     max=126

Why did I only have 4 http requests? I was expecting to have 5 * 2 + 15 * 10 + 20 * 5 = 260

Upvotes: 2

Views: 2010

Answers (1)

knittl
knittl

Reputation: 265211

"ramping-arrival-rate" should be okay, it defines how often your test function is started per time unit (e.g. per second).

Note however that there seems to be a small misunderstanding how stages work.

{ target: 5, duration: '2s' },
{ target: 15, duration: '10s' },

Does not mean "run 5 rps for 2 seconds, then run 15 rps for 10 seconds", but rather "go from 5 rps to 15 rps over the duration of 10 seconds". So after 1 second, you will have 6 rps, after 2 seconds, you will have 7 rps and so on. In other words: the rate will be interpolated linearly.

This gives you a request rate similar to the following diagram:

    /
  /
/

If you want your rate to "jump" immediately to the next value, you need to sprinkle 0-length stages between your regular stages, e.g.

{ target: 5, duration: '0s' },
{ target: 5, duration: '2s' },
{ target: 15, duration: '0s' },
{ target: 15, duration: '10s' },

This gives you a request rate similar to the following diagram:

   __
 _|
|

But even with your current setup, you should get more than 4 iterations. I see that your P(95) is very high (1 minute!) and 40 seconds average response time, so perhaps most of the requests are still running and have not finished when your test terminates? You can set the gracefulStop property in your scenario to a high-enough value, e.g. '2m'.

To further debug, I'd suggest to add console.log statements to check if your function is actually called with the desired rate.

You might also be interested in the official k6 example about instant load increase.

Upvotes: 6

Related Questions