Gatling HTML report limits in separating injector saturation from target latency

Question

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?

Tasadduq Burney · Answer

Direct AnswerNone. The standard Gatling OSS HTML report contains no documented field or metric that explicitly flags injector-side saturation—such as CPU exhaustion, file-descriptor limits, or ephemeral-port pressure—versus genuine target-side delay. Gatling OSS also provides no supported mechanism inside the standard report to correlate virtual-user response timestamps with injector OS-level counters. Assertions validate response times and status codes only; a passing assertion does not prove the load generator was healthy.Confirmed Facts vs. Likely ExplanationsConfirmed: the report aggregates request-level response times, percentiles, throughput, and status codes. Likely but not definitive: rising connect timeouts, connection-reset errors, or a widening gap between response latency and total response time may hint at client-side queuing or resource limits, but the target system or intermediate network can produce identical patterns.Attribution Steps for This CasePin your Gatling version and inspect the shipped gatling.conf. Gatling 3.x uses a Netty-based client whose connection-pool, keep-alive, and timeout defaults differ materially from the AsyncHttpClient engine in 2.x. Outdated assumptions can mask or create artificial bottlenecks.Run a short smoke test while capturing injector OS metrics—CPU utilization, socket summaries (ss -s), protocol error counters (netstat -s), and file-descriptor usage—and align them with simulation.log timestamps.Scale the load down or add a second injector. If response times fall proportionally, the constraint is likely injector-side; if they remain flat, the target is the more probable source.Compare the report's latency and full response-time series. A divergence that coincides with OS socket pressure suggests client-side queuing, but it is not proof.Version-Sensitive Design ConsiderationsBecause Gatling 3.x replaced the AsyncHttpClient engine with Netty, connection-pool sizing, keep-alive behavior, and timeout handling changed. Before attributing latency to the injector, verify the exact defaults in your version's gatling.conf rather than relying on legacy 2.x settings. High connection churn or many distinct hosts can still exhaust local ports even when keep-alive is enabled.One missing detail changes the recommendation: which Gatling version is in use, and does the simulation rely on persistent keep-alive connections or high connection churn across many hosts? That determines whether ephemeral-port exhaustion or pool contention is plausible and which gatling.conf keys to verify.

Gatling HTML report limits in separating injector saturation from target latency

1 answer

Direct Answer

Confirmed Facts vs. Likely Explanations

Attribution Steps for This Case

Version-Sensitive Design Considerations

Your perspective belongs here.

0 question comments