Gatling thread-pool saturation and latency spikes under concurrency

When executing high-concurrency simulations in Gatling, latency spikes often appear that do not correlate with the target application's response time. This behavior is observed when the HighRes scenario executor reaches its bounded thread pool limit, causing virtual users to be queued before execution.

The interaction between usersPerSec and the feeder mechanism further complicates this. Since the default CSV feeder reads rows sequentially, concurrent access from multiple virtual users can introduce non-deterministic I/O overhead and session state contention. It becomes difficult to distinguish between network-level jitter and internal overhead caused by the Gatling scheduler during the ramp-up phase.

What is the specific threshold for usersPerSec where the Gatling scheduler begins introducing significant queuing latency? How can one differentiate between feeder-induced contention and application-side performance degradation in the final HTML reports?