Gatling thread-pool saturation and latency spikes under concurrency

Short answer

There is no universal usersPerSec threshold at which Gatling's scheduler begins introducing significant queuing latency. Saturation starts when the offered load, arrival rate multiplied by average step duration, exceeds what the bounded scenario executor can sustain on your hardware. Gatling virtual users are lightweight messages scheduled on a bounded dispatcher, not one OS thread per user, so usersPerSec controls arrival rate while concurrency is approximately rate times response time.

In the final HTML report, compare the active-users chart to the injection profile. If active users plateau while usersPerSec keeps rising and response times spike, suspect internal scheduler saturation. If response times rise proportionally with active users and errors remain low, suspect the target application.

Likely explanation and confirmed facts

Likely explanation

When the dispatcher queue fills, virtual users wait inside Gatling before executing their next action. That wait is added to measured response time even though the application never received the request. A sequential CSV feeder can add irregular pre-request delays because concurrent virtual users serialize on shared file I/O, which is different from network jitter.

Confirmed facts

• The standard Gatling HTML report does not expose a separate scheduler queue-wait metric; reported response time includes client-side wait, network time, and server time.
• No fixed thread-pool size should be assumed; Akka dispatcher configuration and Gatling version affect saturation behavior.
• Feeder contention typically appears as irregular delays before a request starts or feeder-exhausted errors, not as uniformly elevated server response times.

Assumption: the spikes are caused by executor saturation rather than garbage collection or network issues. Mark for review until the verification steps are run.

Verification steps

1. Run a smoke test against a local dummy endpoint that returns immediately, for example python3 -m http.server 8080 serving an empty file. If latency spikes persist at high usersPerSec, the overhead is internal to Gatling.
2. Compare the HTML report active-users curve to the injection rate. A flat active-users ceiling with rising response times indicates scheduler saturation.
3. Switch the feeder from sequential csv to random or eager, or preload the data. If the spikes disappear, feeder contention was the cause.
4. Enable extraInfo or custom logging to capture request start and end timestamps, then look for gaps before the first byte is sent.

Missing diagnostic detail

Which Gatling version are you using? Dispatcher configuration and saturation characteristics differ across versions, so the version changes how you tune the executor.