Optimize the ramping-arrival-rate executor
#1944
Labels
evaluation needed
proposal needs to be validated or tested before fully implementing it in k6
performance
refactor
Milestone
Comments
na--
added
performance
refactor
evaluation needed
This was referenced Apr 2, 2021
mstoykov
added a commit
that referenced
this issue
May 21, 2021
…ion (#1957) Create a dedicated goroutine to process iterations when a new ActiveVU is created for the Ramping arrival rate. It changes the previous behaviour where instead a new goroutine was created for every new iteration. The previous solution was impacting the expected rate (iterations/s) using a number of PreAllocatedVUs around thousand. Added a Benchmark to check the rate with a set of PreAllocatedVUs cases. Closes #1944 Co-authored-by: Mihail Stoykov <MStoykov@users.noreply.github.com> Co-authored-by: Ivan Mirić <ivan@imiric.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, the
ramping-arrival-rateexecutor spawns a new goroutine for every iteration it has to make: https://github.com/k6io/k6/blob/abce5d835c294c77e4a1a880d73171bf6be62d96/lib/executor/ramping_arrival_rate.go#L445This is in contrast to most of our other executors, which usually spin up a single goroutine per VU and execute iterations inside of it, for example
shared-iterations: https://github.com/k6io/k6/blob/abce5d835c294c77e4a1a880d73171bf6be62d96/lib/executor/shared_iterations.go#L274We have noticed some performance issues with the
ramping-arrival-rateexecutor and we think this excessive goroutine spawning is a big part of the problem: #1386 (comment)So, we'd like to have a benchmark for the
ramping-arrival-rateexecutor, measuring how it currently behaves with different combinations ofpreAllocatedVUsandrateoptions, and also want to to rewrite the executor to spawn just a single goroutine per VU and see if that makes a substantial performance difference.The text was updated successfully, but these errors were encountered: