Gatling HTML report limits in separating injector saturation from target latency

Gatling's asynchronous engine allows a single injector to sustain high request rates, yet the standard HTML report aggregates response-time percentiles and request counts without providing a definitive signal that distinguishes client-side queuing or resource exhaustion from genuine server-side latency. When an injector approaches its own limits—CPU saturation, file-descriptor exhaustion, ephemeral-port pressure, or network interface throughput—rising response times may reflect load-generator constraints rather than target-system behavior. Assertions evaluate observed response times and status codes against thresholds, but they do not assert on injector health, so a passing assertion can still mask a load-generator bottleneck. Connection reuse via keep-alive reduces ephemeral-port pressure, but simulations with high user churn, connection resets, or many distinct hosts can still exhaust local ports or file descriptors. Because Gatling timestamps responses at the virtual-user level, OS-level network counters and injector CPU utilization are necessary to confirm whether rising latency originates on the client or the server. Because configuration defaults vary across versions, this attribution problem requires verification against the specific Gatling version in use.

Which documented Gatling report fields or metrics, if any, explicitly indicate injector-side saturation versus target-side delay? Is there a supported mechanism in Gatling OSS to correlate virtual-user response timestamps with injector OS-level counters within the standard report? How should simulation design account for version-sensitive connection-pool and protocol defaults when attributing observed latency to the injector rather than the target?