Why can JMeter's non-GUI summariser print nothing for minutes while the test is still running?
answer
- Nothing schedules the line
- A listener needs something to listen to
- The boundary check rides on a sample
- A few seconds of slack per boundary
basics
~20 sNothing 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.
solid answer
~40 sThe **Generate Summary Results** listener is driven entirely by arriving samples. When a sample result reaches it, the listener adds it to the current delta and then asks whether the clock has crossed a reporting boundary; if it has, it writes the `+` line. There is no scheduler and no timer thread, so an interval in which nothing completes is simply skipped. JMeter's own component reference notes that the interval may not be respected when a test emits no samples inside it. The boundary test also allows only a five-second window past each multiple of `summariser.interval`, so a plan with sparse samples can miss a boundary and produce a delta covering twice the interval.
go deeper
Remember that a missing summariser line is not the same as JMeter having crashed. It usually means no sample finished in that stretch of the run.
Explain that the listener is called on sample arrival and does its boundary check there, which is why an interval with no completed samples produces no output at all rather than a zero.
Treat a gap in the console as a timestamped observation worth keeping: it marks a period in which nothing completed near a boundary, and it is one of very few things a headless run surfaces without extra tooling.
If your team's runs need a value at every interval rather than an absence, say so in the standard and provide it, because the summariser will not. Decide that once rather than per project.
## The summariser has no clock of its own It is natural to read `summariser.interval=30` as *print a line every thirty seconds*, and that is the wrong mental model. JMeter's **Generate Summary Results** listener is a sample listener: the only code path that can produce a line is the one the engine calls when a sample result arrives. There is no scheduled task, no timer thread, and nothing that fires on an idle engine. So each time a sample arrives, the listener does three things: 1. adds the result to the current delta; 2. checks whether the clock has crossed a reporting boundary; 3. if it has, formats and writes the `+` line (and the `=` line, once there is a difference between total and delta). **No sample, no step 2.** A stretch of console with no summariser line is a stretch in which no sample result reached the listener at a moment when the boundary test would have passed. ## The boundary test, and its five-second window The check is deliberately loose. JMeter reports on wall-clock boundaries so that runs started at different moments line up, and it allows a margin either side rather than demanding an exact hit. Two conditions have to hold together: - the current second must sit within a small window — five seconds — past a multiple of the interval; - more than that window must have passed since the last report, so one boundary cannot be reported twice. The consequence is worth internalising: it is not enough for the test to still be running. **A sample has to complete inside that five-second window.** A plan producing one sample every twenty seconds can skip a boundary entirely, and the next delta then covers sixty seconds or more rather than thirty. The component reference states this outright as a note on the element. ## What silence tells you, and what it does not A gap in the console is a real observation, and it is one of the few things a headless JMeter run gives you for free. It says: *between these two timestamps, nothing completed near a boundary.* That is consistent with a stalled injector, with a stalled system under test, with a plan whose samplers are simply slow, and with a plan in the middle of a long thread-group delay. It is not consistent with "throughput was zero and JMeter told me so" — the summariser never prints a `0.0/s` line for an idle window, because it does not print a line for an idle window at all. If you want a value at every interval rather than an absence, you need something outside the summariser. ## Getting more resolution Two knobs, both in `bin/jmeter.properties`: - `summariser.interval` — seconds between reports, default `30`. Shipped commented out, so the default applies unless you set it. Lowering it gives you more, shorter windows, which matters on runs measured in minutes rather than hours. - `summariser.name` — the label, and the only summariser key shipped **active** as `summariser.name=summary`. That active line is what creates the CLI summariser at all; comment it out, or set it empty, and the automatic summariser disappears. Lowering the interval does not change the underlying rule. With a five-second window and a shorter interval you get more boundaries to hit, but every one of them still needs a sample to arrive before anything is printed.
- Does the summariser print a 0.0/s line for an interval in which nothing completed?No. It writes a line only when a sample arrives at a boundary, so an idle window produces silence rather than a zero. The next line you see is a delta whose span covers the quiet period, which is why its elapsed time can be well over the configured interval.
- Which property shortens the reporting interval, and where does it live?`summariser.interval`, in `bin/jmeter.properties`. It is shipped commented out with a default of 30 seconds. Lowering it adds boundaries, which helps on short runs, but every boundary still needs a sample to arrive before a line is printed.
saying these in an interview costs you the question
- Believes a background timer prints the line every 30 seconds
- Expects a 0.0/s line when nothing completes in a window
- Reads a missing line as proof the process died
- Assumes every delta line spans exactly summariser.interval seconds