After a Gatling Community Edition run, which panels does the generated index.html show, and what does each one plot?
answer
- One global page, one page per request
- Header strip, three tables, six charts
- Stats columns: Total OK KO %KO Cnt/s
- Percentiles-over-time chart is OK only
basics
~20 sGatling's index.html shows response-time ranges, a simulation card, an assertions table, the Stats table, an errors table, users start rate, concurrent users, response-time distribution, percentiles over time over successful requests only, requests per second and responses per second.
solid answer
~50 s`index.html` is the global page of the static HTML report Gatling writes after the run, consolidating every request; the *Details* menu links one page per request and per group. Its header strip carries the **Response Time Ranges** bars, an OK/KO polar chart and a simulation card with the Gatling version, run date, duration and run description. Below that come the **Assertions** table, the **Stats** table (`Total`, `OK`, `KO`, `% KO`, `Cnt/s` plus min, four configurable percentiles, max, mean and standard deviation) and the **Errors** table. Then six charts. Five of them share the run's time axis: users start rate, number of concurrent users, response-time percentiles over time for successful requests only, requests per second and responses per second. The sixth, **Response Time Distribution**, does not — it is a histogram whose x-axis is response time in milliseconds, bucketed from the run's data.
code
hocon · 14 linesgatling {
charting {
maxPlotPerSeries = 1000
useGroupDurationMetric = false
indicators {
lowerBound = 800
higherBound = 1200
percentile1 = 50
percentile2 = 75
percentile3 = 95
percentile4 = 99
}
}
}go deeper
Be ready to open a Gatling report and name what you are looking at: the ranges bars, the Stats table, the two user charts, the response-time distribution histogram and the three time charts under it.
Be ready to say which records feed each panel — that requests per second counts sends while responses per second counts arrivals, and that the percentiles chart takes successful requests only.
Be ready to explain that everything is computed at report-generation time from simulation.log, so the configuration on the classpath at that moment decides the columns and the bucket bounds.
Be ready to say what the report is and is not as an interface: an artifact to read, not a data source to integrate with, which is why a verdict has to ride out on the exit code.
## Where the report comes from Gatling Community Edition finishes a run by writing a **static HTML report** into that run's own results folder, and `index.html` is its **global page** — every request of the run, consolidated. Beside it sit one HTML page per request and per group, reachable from the *Details* menu, and `simulation.log`, the raw record of the run. The report is generated **after** the simulation stops, by reading `simulation.log` end to end. The browser does no arithmetic: every figure you see was computed at generation time from the configuration that was on the classpath then. That is why `--no-reports` (`-nr`) can skip generation entirely and `--reports-only` (`-ro <directoryName>`) can rebuild the whole report later from an existing log. This is Gatling 3.15.x; the machine-readable side files Gatling once dropped beside the HTML — `stats.json`, `global_stats.json`, `assertions.xml` and `assertions.json` — were deleted as dead internals, and the project's FAQ says they will not be restored. ## The panels on the global page A three-part header strip comes first: - **Response Time Ranges** — one bar per band: successful requests faster than the lower bound, successful requests between the bounds, successful requests at or above the higher bound, and a fourth bar counting failures. The cut points come from `gatling.charting.indicators.lowerBound` (800 ms) and `higherBound` (1200 ms). - **A request-count polar chart** — the OK versus KO share of the whole run at a glance. - **The simulation card** — the Gatling version and its release date, the run's start date, the run's duration, and the `--run-description` text when one was supplied. Then the tables: - **Assertions** — one row per assertion with an `OK`/`KO` status. Rendered only when the simulation declared any. - **Stats** — the main table, below. - **Errors** — *Error*, *Count*, *Percentage*, sorted by count. Rendered only when something failed. Then six charts. Five of them share the run's time axis; the third, Response Time Distribution, does not: 1. **Users start rate** — virtual users started per second, one series per scenario plus an "All users" series. Gatling's docs describe this as the chart that matches your profile when the profile is declared as an arrival rate (an *open* one). 2. **Number of concurrent users** — concurrent virtual users per second, split the same way. This is the chart that matches a profile declared as a held population (a *closed* one). 3. **Response Time Distribution** — the one chart in this list that is not plotted against elapsed run time. Its x-axis is response time in milliseconds, bucketed between the run's smallest and largest observed response time, and its y-axis is the share of requests that landed in each bucket, drawn as a successes series and a failures series. 4. **Response Time Percentiles over Time (OK)** — the `(OK)` in the title is literal: this chart is built from **successful requests only**. 5. **Requests per second over time** — counted at the instant each request was *sent*. 6. **Responses per second over time** — counted at the instant each response *arrived*, split into successes and failures. ## The Stats table, column by column | group | columns | |---|---| | Executions | `Total` · `OK` · `KO` · `% KO` · `Cnt/s` | | Response Time (ms) | `Min` · four configurable percentile columns (`50th`, `75th`, `95th`, `99th` by default) · `Max` · `Mean` · `Std Dev` | Three things about it are easy to get wrong: - On the **global** page every *Response Time* column is computed over **all** requests, successes and failures together; only the Executions half separates them. The per-request Details pages break those same figures into `Total`, `OK` and `KO` columns. - `Cnt/s` divides the request count by the **whole run's wall-clock duration**, not by the window in which that particular request was being sent. - When the scenario uses `group(...)` the table becomes a **tree**: groups are the non-leaf rows, requests the leaves beneath them. ## Detail pages add a chart the global page has not A request page repeats the ranges panel, its own stats table with the Total/OK/KO split, the errors table, the distribution and percentiles-over-time charts and the two throughput charts — and adds a **Response Time against Global RPS** scatter, plotting that request's response times against how busy the whole run was at the same moment, successes and failures as separate series. A group page instead carries two distribution charts and two percentiles-over-time charts: one pair for the group's **duration**, one for its **cumulated response time**. ## What the report deliberately does not do The page reports; it does not judge. The only verdict on it is the Assertions table, and the run's exit code is what carries that verdict to a pipeline. Choosing what a pass rule should assert, comparing this run against a baseline, and reading a diagnosis into the curves are performance-testing questions that live outside Gatling itself. The report's job — and the thing worth knowing precisely — is which records fed which figure.
- Can you rebuild the report without re-running the simulation?Yes. `--reports-only` (`-ro <directoryName>`) regenerates the HTML from an existing `simulation.log`, which is also how you salvage a run you interrupted. One caveat: the component that writes the log buffers, so a forcefully killed run loses its tail and the rebuilt report is short by whatever was still in the buffer.
- Which panels of the global page can be missing altogether?Two. The Errors table renders nothing when no request failed, and the Assertions table renders nothing when the simulation declared no assertions. Their absence is information: an empty-looking report is usually a clean run, not a broken generator.
saying these in an interview costs you the question
- Thinks index.html recalculates figures in the browser from simulation.log
- Assumes the percentiles-over-time chart includes failed requests
- Expects a machine-readable stats file beside index.html to parse
- Believes the report itself decides whether the run passed