we need to run multiple request per second for 10 min
e.g. 20,000 request per seconds
stages: [
{ duration: "10m", target: 20000 },
However im not sure what does it mean the virtual users combination with the rate we need to simulate 20,000 different request per seconds for specific API
I try like this
scenarios: {
constant_request_rate: {
executor: ‘constant-arrival-rate’,
rate: 20000,
timeUnit: ‘1s’, // 1000 iterations per second, i.e. 1000 RPS
duration: ‘120s’,
preAllocatedVUs: 100, // how large the initial pool of VUs would be
maxVUs: 3000, // if the preAllocatedVUs are not enough, we can initialize more
}
}
};
But not sure I understand what does it mean to add to the rate 20000 with additional VU 3000, what is actually simulate ?
Thanks!
Virtual users are still the driver of traffic, even if you are specifying your scenario based on arrival rates.
preAllocatedVUs is the number of virtual users k6 will allocate in memory at the start of the test. If this number of virtual users is unable to achieve the target arrival rate (say, for instance if your application starts to slow down), k6 can dynamically initialize more, up to the number defined as maxVUs.
Thanks for the answer, it a bit confusing as I saw this concept of VU for the first time. So how you suggest to do run against one http endpoint 20000 request per second , like this ?
The rate and timeUnit settings configure the desired arrival rate, so in your case, having a rate of 20000 and a timeUnit of 1s is correct.
The number of users required to achieve that rate ultimately depends on how long it takes a user to complete each iteration through the script. If an iteration takes 1 second to complete, you would require 20,000 users to achieve your desired target of 20,000 iterations/sec. However, if an iteration only takes 100 milliseconds to complete, then 2,000 users would achieve your target (as each user could complete 10 iterations/sec).
As the article you linked in the original thread states, you want to allocate enough virtual users to achieve the desired rate. Keep in mind though that each user consumes system resources on the load testing host, so you wouldn’t want to allocate 20,000 users to a scenario if 2,000 would be enough to achieve your desired load.
That is where the preAllocatedVUs and maxVUs settings come into the picture. You can pre-allocate the number that should be enough based on how the application normally performs, then configure a higher maximum to allow k6 to scale up additional users if necessary.
I’d suggest running a lower volume of requests against the application initially to get a sense for how long iterations take to complete on average. The test summary provided by k6 includes an iteration_duration metric which shows you this. Once you have this information, you can fine tune how many users need to be allocated to achieve your desired arrival rate.