Control Goroutine Explosion During Load Tests Using a Fixed Worker Pool

[Naganathan05]

The load testing engine currently executes requests using multiple clusters, where each worker is spawned as an independent Go routine. While this approach works for small loads, it causes unbounded goroutine creation under higher configurations.

As a result:

• Memory usage spikes significantly during load tests
• The tool fails to execute the configured number of requests reliably
• Request rates and concurrency limits are not respected deterministically

This issue aims to address these problems by introducing bounded concurrency and controlled execution across clusters.

Proposed Solution (by Maintainer)

The execution model should be refactored to use a fixed-size goroutine pool shared across all clusters.

Key changes include:

• Introduce a global worker pool with a fixed number of goroutines
  • Pool size should be derived from machine capacity (CPU cores / memory) or a safe upper bound
• Replace per-cluster goroutine spawning with a job-queue-based model
  • Clusters should enqueue request jobs instead of spawning goroutines directly
• Implement a centralized scheduler that:
  • Enforces configured rate and concurrency limits
  • Dispatches request jobs to available workers in the pool
• Preserve the existing logical cluster model while decoupling it from execution mechanics

NOTE: The above mentioned solution is just a proposal, any other different solution that addresses the issue is highly encouraged.