skip to content

Injector Overload Symptoms

The evidence JMeter itself prints when the generator has run out of room: a flattening summariser rate, a throughput target never reached, GC pauses, and an OutOfMemoryError in the run log.

on this pageshow

explore

questions

5

In a JMeter non-GUI run, what do the summariser's + and = console lines each report?

level: middleimportance: must knowfreq 62%

answer

  1. Two kinds of line, not one
  2. One window, one whole run
  3. Thread counts sit on only one kind
  4. Default label is summary

basics

~20 s

The + line is a delta covering only the window since the last report; the = line is the running total for the whole run so far. Only the + line carries Active, Started and Finished thread counts.

solid answer

~40 s

In CLI mode JMeter creates a **Generate Summary Results** listener named from `summariser.name` (shipped as `summary`) and prints two kinds of line. A `+` line is the **delta** for the reporting window that just closed; an `=` line is the **running total** since the test began. Both show the sample count, the elapsed span, the resulting `/s` rate, then `Avg`, `Min` and `Max` sample times in milliseconds and an `Err` count with its percentage. Only the `+` line appends `Active`, `Started` and `Finished`, taken from JMeter's engine-wide thread counters. The very first report prints a `+` line alone, because the running total and the delta are still the same number.

code

text · 6 lines
text
Creating summariser <summary>
summary +     16 in 00:00:12 =    1.3/s Avg:  1608 Min:  1163 Max:  2009 Err:     0 (0.00%) Active: 5 Started: 5 Finished: 0
summary +     82 in 00:00:30 =    2.7/s Avg:  1518 Min:  1003 Max:  2020 Err:     0 (0.00%) Active: 5 Started: 5 Finished: 0
summary =     98 in 00:00:42 =    2.3/s Avg:  1533 Min:  1003 Max:  2020 Err:     0 (0.00%)
summary +     85 in 00:00:30 =    2.8/s Avg:  1505 Min:  1008 Max:  2005 Err:     0 (0.00%) Active: 5 Started: 5 Finished: 0
summary =    183 in 00:01:13 =    2.5/s Avg:  1520 Min:  1003 Max:  2020 Err:     0 (0.00%)

go deeper

for a junior

Recognise the two line shapes when you run jmeter -n and know that the numbers after Avg, Min and Max are milliseconds. Being able to say which line is the delta is most of the value here.

for a middle

Explain that the delta covers one reporting window while the total covers the whole run, and that Active, Started and Finished appear only on the delta line because they are a snapshot rather than an accumulation.

for a senior

Read a scrolling summariser during a live run: use the + line for what is happening now, notice a short first delta as normal, and treat the = line's rate as a lagging average you should not quote as current throughput.

for a principal

Decide what the console stream is for on your team. It is the only live view a headless run offers, so settle whether stdout is captured, whether the interval suits your run lengths, and what the numbers may and may not be used to claim.

## Two line kinds, one summariser In a non-GUI (`-n`) run JMeter creates a **Generate Summary Results** listener for you and prints `Creating summariser <summary>` before the test starts. The name comes from the `summariser.name` property, which `bin/jmeter.properties` ships set to `summary` — that name is the label at the start of every line it writes. From then on the listener emits two different kinds of line: - a **`+` line — the delta**. It covers only the reporting window that has just closed, so its figures describe *now*. - an **`=` line — the running total**. It covers every sample recorded since the test started, so its figures describe *the run so far*. ## The fields, left to right Both kinds carry the same statistics block: | Field | Meaning | |---|---| | `+ 82` / `= 98` | sample count in this window / in the run so far | | `in 00:00:30` | elapsed time the count is spread over, `hh:mm:ss` | | `= 2.7/s` | samples divided by that elapsed time — **samples per second** | | `Avg: 1518` | mean sample elapsed time, **milliseconds** | | `Min:` / `Max:` | fastest and slowest sample in the window, milliseconds | | `Err: 0 (0.00%)` | error count and the same figure as a percentage | Only the `+` line then appends `Active: 5 Started: 5 Finished: 0`. Those three come from JMeter's engine-wide thread counters — **`Active` is threads started and not yet finished, summed across every thread group**, not the count of threads under whatever element the summariser is attached to. ## Why the first report shows no = line Look at the sample output: the first report is a lone `+` line. JMeter only writes the `=` line when the running total's sample count differs from the delta's, and on the very first report they are the same number. The `=` line appears from the second report onwards, and again at the end of the test. Two related quirks are worth expecting: 1. The **first delta is short**. JMeter reports on a wall-clock boundary (every `summariser.interval` seconds, 30 by default), so the first window runs from test start to the first boundary — `00:00:12` in the example. 2. The **last delta is short too**, and the closing pair is not aligned to a boundary at all. ## Where the lines are written Two properties, both defaulting to `true` and both shipped commented out in `bin/jmeter.properties`: - `summariser.out` — write to `System.out`, which is what you see scrolling in the terminal; - `summariser.log` — write the same text to `jmeter.log`, where each line also carries a timestamp. That matters when you are reading a run after the fact: the console copy is only as durable as whatever captured stdout, while the log copy is timestamped. ## What the lines do not say The summariser reports sample counts and sample times. It prints no verdict, no threshold, and no figure about the machine it is running on. Deciding what a flat `/s` or a rising `Avg` *means* is a separate exercise; the summariser's job is to put the numbers on screen while the run is still going.

  • Why does the very first summariser report print a + line but no = line?
    JMeter writes the `=` line only when the running total's sample count differs from the delta's. On the first report every sample recorded so far is also in the delta, so the two counts are equal and the total line is suppressed. It appears from the second report onwards.
  • Besides the terminal, where else do those lines go?
    `summariser.log` (default `true`) sends the same text to `jmeter.log`, where log4j2 prefixes each line with a timestamp and level. `summariser.out` (default `true`) sends it to `System.out`. Both keys ship commented out in `bin/jmeter.properties`, so both defaults apply unless you set them.
  • If a plan already contains a Generate Summary Results listener, what should you name it?
    Anything other than `summary`. The listener groups samples by element name, and the CLI-created summariser already uses that label, so a second element with the same name accumulates into the same totals and the counts come out inflated. The component reference calls this a design choice, not a bug.

The + line is the speedometer and the = line is the trip average. Ten minutes into a steady drive the trip average barely twitches when the speedometer drops, so if you want to know what is happening right now you read the speedometer.

saying these in an interview costs you the question

  • Says the + and = lines are the same figures reformatted
  • Reads the = line's rate as the current throughput
  • Expects Active on the running-total line
  • Assumes every delta window is exactly 30 seconds
  • Reads Avg, Min and Max as seconds rather than milliseconds
open as a page

A JMeter run's summariser rate flattens while its Active count keeps climbing. Which JMeter output records that?

level: seniorimportance: should knowfreq 52%

basics

~20 s

Successive + delta lines hold the story: the /s figure, the Active count, the Avg time and the Err share, window by window. Beside them sit jmeter.log at ERROR and any gap where no line was printed at all.

open as a page

What happens to a JMeter non-GUI run when a sampler thread throws OutOfMemoryError?

level: seniorimportance: should knowfreq 48%

basics

~10 s

The thread dies and the run carries on. JMeter's default uncaught-exception handler logs an ERROR block in jmeter.log and prints one line to stderr, and bin/jmeter's always-on heap-dump flag leaves a .hprof file behind.

open as a page

Across a team's headless JMeter runs, which of JMeter's own output would you require every run to archive?

level: principalimportance: should knowfreq 38%

basics

~20 s

At minimum the captured stdout carrying the summariser lines, a per-run jmeter.log kept with -j, and the results file. JMeter tracks nothing about the injector host during a run, so decide separately where that comes from.

open as a page

Why can JMeter's non-GUI summariser print nothing for minutes while the test is still running?

level: middleimportance: nice to knowfreq 32%

basics

~20 s

Nothing schedules the line. JMeter checks whether a reporting boundary has passed only when a sample result arrives, so a window in which no sample completes produces no line at all rather than a zero-rate one.

open as a page