Gatling generates arguably the most beautiful performance test reports in the industry -- interactive, color-coded, and drill-down capable. But beauty does not help if you do not know what to look at. The concepts are the same as JMeter (response times, throughput, errors), but the layout and terminology differ. If JMeter reports are like a spreadsheet, Gatling reports are like an interactive dashboard. Let us walk through each section.
When your Gatling simulation finishes, it generates an HTML report in the target/gatling/<simulation-name>-<timestamp>/ directory. The report opens to a global overview page with navigation tabs. Unlike JMeter where you might need to scroll through one long page, Gatling organizes everything into distinct views.
The top of the Global view shows a summary table with total requests, OK count, KO (fail) count, and percentile response times. Below that are two critical indicators.
| Indicator | What Gatling Shows | How to Interpret |
|---|---|---|
| Response Time Ranges Bar | Green/yellow/orange/red horizontal bar | Green (< 800ms) should dominate. Red means failures. Adjust thresholds in gatling.conf if your SLA differs from defaults. |
| Number of Requests per Second | Line chart showing throughput over time | Should ramp up with users and plateau. A declining line = server struggling. |
| Response Time Distribution | Histogram of all response times | A tight, left-leaning bell curve is ideal. A long right tail means outliers. |
| Response Time Percentiles Over Time | Line chart with p50/p75/p95/p99 lines | Lines should stay flat. If they diverge (p99 rising while p50 stays flat), tail latency is growing. |
Click "Details" in the top navigation. You see a list of all request names from your simulation. Click any request to see its individual charts -- response time distribution, response time over time, latency over time, and requests per second. This is where you find out that the /api/search endpoint is 10x slower than everything else while /api/health is blazing fast. The Details view in Gatling is equivalent to the Aggregate Report in JMeter -- it is your per-endpoint microscope.
By default, Gatling uses four response time buckets: under 800ms (green), 800-1200ms (yellow), over 1200ms (orange), and failed (red). These defaults come from web usability research but may not match your SLA. You can change them in gatling.conf.
gatling {
charting {
indicators {
# Adjust these to match your SLA
lowerBound = 500 # Below this = fast (green)
higherBound = 1500 # Above this = slow (orange)
# Between lower and higher = acceptable (yellow)
# Failed requests are always red
}
}
}Q: Have you used Gatling? How do its reports compare to JMeter?
A: Yes, I have used both. The core metrics are the same -- response times, throughput, errors, percentiles -- but the presentation differs significantly. Gatling reports are interactive HTML with drill-down capabilities. You can click on any request name and see its individual response time distribution, which is very convenient. JMeter reports are more tabular and static by default, though you can customize them with plugins. One practical difference: Gatling color-codes responses into buckets (green/yellow/orange/red) based on configurable thresholds, which makes it easy to get a visual pass/fail at a glance. In JMeter, you typically compare against SLA thresholds manually. For reporting to stakeholders, I find Gatling reports require less post-processing because they already look polished.
Key Point: Gatling and JMeter reports answer the same three questions (how fast, how much throughput, how many errors) but present them differently. Learn to translate between them -- the analysis skills are identical.
Key Point: Gatling reports are interactive and visually polished but answer the same questions as JMeter: response time trends, throughput capacity, per-endpoint breakdown, and error rates.