Hi, can we run distributed load test using more than 1 local machines (load generators). And how to implement it?
k6 doesn’t natively support distributed tests yet, sorry. We intend to, in the future, and we’re slowly working towards it. You can follow Clustering and distributed execution · Issue #140 · loadimpact/k6 · GitHub for updates. For example, since k6 v0.27.0, k6 supports execution segments and it’s relatively easy to split tests between multiple machines and generate load in a distributed manner, see this comment for details. But things like thresholds and the end-of-test summary are missing in this ad-hoc distributed execution for now - you can get around most of that by using an external output to save the generated metrics, but it’s still not a turnkey solution.
If you’re in a Kubernetes environment, you’d also be more than welcome to give the k6 operator a try!
While still very alpha, it already has basic support for distributing the load generation across multiple nodes, although without threshold synchronization and VU orchestration.
This is what I set up for our testers to easily scale their k6 executors across all nodes in kubernetes. The reason behind is most of them have very limit of kubernetes knowledge nor familiar with kubectl commands. Hope this can help you too ~
The k6 operator seems promising! I am concerned about internal k6 support for the operator given the repo’s code commit frequency. Any specific plans for the operator? We have a team of engineers willing to contribute if it’s the right fit for us.
I read Clustering and distributed execution · Issue #140 · k6io/k6 · GitHub. Is official support for “clustered” execution independent of the k6 operator? In other words, do you see the k6 operator continuing to exist once clustered execution is officially supported?
Copying the answers from slack for completeness:
As of right now, the operator is a community project that we’re maintaining from the developer relations team, hence the varying change cadence. Reg. future plans, @robin might be better suited to answer.
There are no decided plans yet in regards to the operator or other distributed execution functionality in k6 OSS besides that we want to implement it at some point, so not likely to see any major push from us in the next 6 months.
We have a whole host of other big and foundational projects that we intend to implement before getting to distributed execution from a k6 dev team perspective, incl. data segmentation (Data segmentation API framework · Issue #1539 · k6io/k6 · GitHub), event-loop/async support (Global JS event loops in every VU · Issue #882 · k6io/k6 · GitHub), metrics changes (Refactor the current way metrics are defined · Issue #572 · k6io/k6 · GitHub, Add explicit tracking and ignoring of metrics and sub-metrics · Issue #1321 · k6io/k6 · GitHub, Common metrics registry · Issue #1832 · k6io/k6 · GitHub, etc.), config/options refactoring (which has seen some great progress recently as part of work done during an internal Grafana hackathon: GitHub - k6io/croconf: A flexible and composable configuration library for Go that doesn't suck).