Which executor to use for burst request scenario

Hi Team,
My test case is to send burst request to hit service endpoint within shortest possible timeframe with unique test data in each request
So I am planning to send 10k, 20k… up to 50k in different test run
These requests shouldn’t be send in longer duration (1,2,3… hrs.) but instead as fast as possible to hit the endpoint.
To simulate these condition which executor to use for burst request scenario
Can you please suggest.

Thanks

Hello @shailendrakumaromkar you can try using ramping arrival rate executor because you have RPS which increases depends on time.

1 Like

Hi @Elibarick

After going through k6 docs, I filtered down to below executors which can be used in my case:

  1. ramping-vus (variable VU, no Iteration config, only duration) :
    It’s not allowing to post more than 2 links → performed : ~300 iterations in 30 sec

  2. constant-arrival-rate (fix number of Iteration during time specify, variable VU till max VU) :
    constant-arrival-rate → performed : 900 iterations in 30 sec

  3. ramping-arrival-rate (variable Iteraion, variable VU till max VU based on time) :
    ramping-arrival-rate → performed : 4,020 iterations in 9 mins ~= 223.3 per 30 sec

  • If you see refer statistics which are taken from k6 docs “constant-arrival-rate” send more request in same time duration compare to other executors, does it mean this can be used to send burst request in shortest duration of time or I am missing something here ?
  • Also for my case as I do not want anything fixed (VU or Iterations) so I thought of using ramping-vus in my case ?

Can you please clarify on above ?

Thanks

Hey @shailendrakumaromkar if you don’t have fixed VUs or iteration you can use ramping vus by increase number of users at each stages and number of iteration also increases.
In #1. Ramping VUs allows to post more than one API/links.

1 Like

Hi @Elibarick

I am hitting single endpoint each time with different set of test data as parameter for each requests

Below is my script:

ramping: __ENV.RAMPING || 0,
virtualUsers: __ENV.VU || refer snap for each test run,
duration: __ENV.DURATION || refer snap for each test run,

‘ramping-vus’: {
executor: ‘ramping-vus’,
gracefulRampDown: ‘0s’,
gracefulStop: ‘0s’,
stages: [
{ duration: ${options.ramping}s, target: options.virtualUsers },
{ duration: ${options.duration}s, target: options.virtualUsers },
{ duration: ${options.ramping}s, target: 0 },
],
},

Refer attached snap for each test run configuration

Question:

  1. Even though I am increasing virtualUsers (200,300) but http_reqs count is not going beyond approx 6000-7000 which is around ~100-120 requests/sec, how can I increase this, any modification I need to do ?

  2. why some of the iterations interrupted how can I solve ?

Thanks

Hey @shailendrakumaromkar interrupted iteration appear because some request were not sent by load generators because duration is small try to increase duration time at each stage.

1 Like

Hi @Elibarick

I will retest interrupted iteration as per your suggestion.

In the meanwhile can you please check below issue & suggest solution ?

  1. Even though I am increasing virtualUsers (200,300) but http_reqs count is not going beyond approx 6000-7000 which is around ~100-120 requests/sec, how can I increase this, any modification I need to do ?

Thanks

Hi @Elibarick

To retest interrupted iteration issue, I modified script as below
but still facing problem

Run#1 : running (30.0s), 000/100 VUs, 3082 complete and 98 interrupted iterations

stages: [
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
],


Run#2 : running (1m00.0s), 000/100 VUs, 6128 complete and 100 interrupted iterations

stages: [
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
{ duration: ‘10s’, target: 100 },
],

Thanks

Hello @shailendrakumaromkar try to increase duration taken by scripts to run, also try to check maximum RPS can process at once, because when maximum RPS reaches from server can not handle more request at defined duration.

1 Like

You can increase duration to minimize interrupted iterations
{ duration: ‘1m’, target: 100 },
{ duration: ‘1m’, target: 100 },
{ duration: ‘1m’, target: 100 },
{ duration: ‘1m’, target: 100 },
{ duration: ‘1m’, target: 100 },
{ duration: ‘1m’, target: 100 },

1 Like

Hi @Elibarick ,

I increased duration & run test for 2 min, 4 mins with constant 200 VU

  1. With this http_reqs count got increased (2 min = 12632, 4 min = 27511) but req/sec remains same around 100-115 req/sec, how can I increase this ?

  2. From attached snap which field to refer as RPS


  3. Who is sending this error is it k6 or host server ? I saw in k6 console → WARN[0044] Request Failed error=“http2: server sent GOAWAY and closed the connection; LastStreamID=47, ErrCode=NO_ERROR, debug=""”

  4. In this k6 console log what is the 2nd IP address pointing to is it k6 or host server ? → WARN[0047] Request Failed error=“read tcp 1st IP address->2nd IP address: An existing connection was forcibly closed by the remote host.”

Hi @shailendrakumaromkar

  1. RPS is amount of request server can process at seconds. When host server reaches maximum RPS it can not server more request remaining constant RPS, To confirm more this you need to monitor server resources CPU, RAM usage tracing http error request.
  2. Http Error were sent by host server because more request were okay and few were failed
  3. IP address host server
1 Like