When a Gatling scenario wraps requests in group(...), what timing does the group's row in the report's Stats table show by default, and when is that figure the misleading one?

## Two clocks, one group When a virtual user enters a `group(...)`, Gatling starts recording two independent things about it: - **Cumulated response time** — a running sum. Every request that completes while the user is inside the group adds its own response time to the group's total, and to the total of every enclosing group as well when groups are nested. - **Duration** — a single subtraction: the timestamp the user left the group minus the timestamp it entered. The two answer different questions. Cumulated response time answers *how much request time did this journey spend*; duration answers *how long did this journey take*. They diverge by exactly the time the user spent in the group without a request in flight — `pause`, `pace`, session functions, loop bookkeeping — so on a scenario with realistic think time the duration can be several times the cumulated figure. ## What the report shows, and what the flag moves By default the report shows the **cumulated** figure for group rows. One configuration key switches it: ```hocon gatling.charting.useGroupDurationMetric = true ``` What is easy to get wrong is the flag's reach. It is narrower than it sounds: | surface | default | with useGroupDurationMetric = true | |---|---|---| | Group row in the Stats table (min, percentiles, max, mean, std dev) | cumulated response time | group duration | | End-of-run console summary | global request figures only, no group rows | unchanged | | Group detail page, *Group Duration Percentiles over Time (OK)* | always drawn | always drawn | | Group detail page, *Group Cumulated Response Time Percentiles over Time (OK)* | always drawn | always drawn | | Group detail page, both distribution charts | always drawn | always drawn | | *Group Duration Ranges* panel on that page | always duration | always duration | In other words the flag re-points the **table**, not the charts. A group's own page always carries both metrics as curves, so you can compare them there without touching configuration at all. And the ranges panel on that page is fed duration whatever the flag says — which means that with the default setting, the bars and the response-time columns on the same page are measuring two different things. Knowing that is what stops a confusing five minutes. The console row is the one worth spelling out, because that is where the flag's reach gets over-stated. `useGroupDurationMetric` is read in exactly one place in the report generator — the routine that computes a **group's** statistics — so its entire reach is the group rows of the Stats table on `index.html` plus the stats table on each group's own detail page. The summary Gatling prints when the run ends is built from the run's **global request** statistics instead: request count, min, max, mean and standard deviation, the four configured percentiles, mean throughput, the four response-time range lines and then the errors block. It has no group rows for the flag to move. The live summary printed while the run is still going is no way round that either — it carries counts only, and although each request line is prefixed with the group hierarchy it sits under, it reports no group timings at all. ## When the default is the misleading figure The default is the right one when you are asking about the **server**: how much work did a checkout journey cause, how does that total move under load, which group dominates request time. Pauses are noise for that question and the cumulated figure removes them. It becomes the misleading one whenever the question is about the **user**: 1. **A group that contains think time.** A checkout with three 5-second pauses will report a cumulated figure of a few hundred milliseconds while a real user waited 16 seconds. Quoting the cumulated number as "checkout takes 300 ms" is wrong in a way nobody in the room will catch. 2. **A group whose point is a deadline.** If the thing you care about is the end-to-end wall-clock of a journey — an SLA on a flow, a timeout budget — duration is the metric and cumulated is not. 3. **A group containing a loop or a wait.** Anything that spends time without issuing a request is invisible to the cumulated figure by construction. 4. **A group with parallel or fire-and-forget work.** Summed request times can exceed the elapsed wall-clock, so the cumulated figure can be *larger* than the duration. The practical answer in an interview is not "always use duration" — it is: **decide which question the group is there to answer, and set the flag to match, once, for the whole suite.** Mixing conventions across reports is worse than either choice. ## One coupling to remember The group metric is a reporting setting, but the group's figures are the same ones the assertion machinery reads. An assertion aimed at a group path matches that group's **cumulated response time**. Deciding what a pass rule should assert is a performance-testing question rather than a Gatling one, but knowing which of the two clocks a group assertion is reading is squarely Gatling's, and it is the detail that turns a plausible-looking group assertion into one that measures what you meant.