K6 spike test scenario

Grafana k6 OSS Support
1

How can I reliably send 100 requests in 1 second using k6 without dropped iterations?

Hi everyone,

I’m trying to run a k6 test scenario to send exactly 100 requests within 1 second to an endpoint (extract service). My goal is to fire 100 requests simultaneously or as close to that as possible, but I’m running into issues.

export const options = {
scenarios: {
spike_100_at_once: {
executor: “ramping-arrival-rate”,
startRate: 0,
timeUnit: “1s”,
preAllocatedVUs: 150,
stages: [
{ duration: “10s”, target: 0 },
{ duration: “1s”, target: 100 },
{ duration: “5s”, target: 0 },
],
},
},
};

executor: “constant-arrival-rate”,
rate: 100,
timeUnit: “1s”,
duration: “1s”,
preAllocatedVUs: 150,
maxVUs: 1000,
gracefulStop: “0s”

  • This gives me warnings like:
  • “No script iterations fully finished, consider making the test duration longer”
  • “Dropped iterations” if the duration is too short
  • Ramp-up scenarios with staged VUs, but the actual request count and timing don’t match 100 requests in 1 second consistent,
  • What I want:

To simulate 100 requests hitting the service all within 1 second, as part of a short, intense load spike.

Questions:

  1. What is the recommended approach in k6 for this kind of short burst testing?
  2. Is there a workaround to the duration-too-short problem for small window load tests?
2

Hi @malitthh,

I would not use arrival rate execution for a case like this.

To me this seems like a good case for per-vu-iterations with 100 VUs and 1 iterations for each - it will probably start teh 100 requests way before the end of the 1second. Just make certain to put big enough maxDuration.

This very likely is your problem here as well - you make 100 iterations and then you stop the test. Given that this is a spike I expect your service just takes longer than the shutdown timeout which is why you do not get any iterations finished.

Hope this helps you!

1 Like