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
Currently, the
ramping-arrival-rate
executor 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-rate
executor 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-rate
executor, measuring how it currently behaves with different combinations ofpreAllocatedVUs
andrate
options, 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: