skip to content

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%

answer

  1. Console text is an artefact too
  2. One file is truncated on the next start
  3. The interval default suits long runs
  4. Nothing in the output tracks the host over time

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.

solid answer

~40 s

A headless run emits stdout (the `+` and `=` summariser lines), `jmeter.log`, the JTL, and a `.hprof` if the JVM ran out of heap. A workable standard captures the first three for every run, not just failing ones, and names them per run. Two JMeter-specific traps drive that: `bin/log4j2.xml` opens `jmeter.log` with `append="false"`, so the next run on the same injector destroys the previous log unless `-j` gives each its own; and `summariser.interval` defaults to 30 seconds, which is far too coarse for a short run. Nothing in Apache JMeter 6 tracks the injector's own CPU or heap while the test runs, so if you need that, it has to come from outside the tool.

go deeper

for a junior

Know the three files a headless run leaves behind: the results file from -l, jmeter.log, and whatever captured the console. They are separate things with separate contents.

for a middle

Explain why -j matters: the shipped log4j2 configuration opens jmeter.log without appending, so a second run on the same machine overwrites the first run's log entirely.

for a senior

Set the run up so it can be argued about afterwards: per-run log names, captured stdout, an interval that suits the run length, and a known home for a heap dump if the JVM dies.

for a principal

Own the trade-offs explicitly. Resolution against console noise, every run against failures only, JMeter's own thin output against host metrics from another system with its own clock and retention. Write the choice down so it survives the person who made it.

## Start from what JMeter actually emits Before deciding what to keep, be honest about what there is. A headless Apache JMeter 6 run produces exactly four streams, and only three of them are about the run's own health: | Stream | Controlled by | What it carries | |---|---|---| | stdout | `summariser.name` (ships as `summary`; empty means no summariser at all), `summariser.out` (default on, the data lines only) | `Creating summariser <summary>`, printed whatever `summariser.out` says, then every `+` and `=` line | | `jmeter.log` | `summariser.log` (default on), `-j` | the same lines timestamped, plus every engine `INFO`/`ERROR` | | the JTL | `-l` | per-sample rows | | `.hprof` | `-XX:+HeapDumpOnOutOfMemoryError` in `bin/jmeter` | a heap dump, only if the JVM ran out | There is **no fifth stream that tracks the machine over time**. Apache JMeter 6 ships no listener reporting the injector host's CPU, load average or heap during a run; the Monitor Results listener was dropped and nothing replaced it. `jmeter.log` does open with a startup header — `Max memory` and `Available Processors` as the JVM sees them, `os.name`/`os.arch`, the local IP — but that is one line each, written before the test tree is built, describing what the process was handed rather than what it then did. `Active`, `Started` and `Finished` on the `+` line are the only host-side numbers that move during the run. Anything more comes from outside the Apache download — the third-party `jp@gc - PerfMon Metrics Collector` is one such add-on — or from the platform the injector runs on. ## The four decisions worth making once 1. **Capture stdout as a file, not as scrollback.** The summariser stream is the only live view a headless run has, and in most pipelines it exists only for as long as the job's console log is retained. Redirect it and archive it beside the JTL. 2. **Give every run its own log.** The `File` appender in `bin/log4j2.xml` opens `jmeter.log` with `append="false"`, so run *n+1* on a shared injector destroys run *n*'s log. `-j` per run, named after the run, removes a whole class of "the log was gone by morning". 3. **Set `summariser.interval` for your shortest run, not your longest.** The shipped default of 30 seconds gives an hour-long soak 120 windows and a three-minute smoke test six. It ships commented out, so it is the default that applies unless somebody sets it. 4. **Decide where a heap dump may land.** It is on by default and sized like the live heap, so a fleet of `-Xmx8g` injectors can fill a volume quietly. Either give it a directory with room, or accept that the workspace cleanup takes it. ## Where the honest disagreement is The trade-offs are real, and a team can land in different places for good reasons: - **Resolution against noise.** A 10-second interval makes a short run readable and makes a two-hour soak's console unusably long. Some teams set the interval per plan; some standardise one figure and live with it. - **Every run against failed runs.** Archiving stdout, the log and the JTL for every nightly run is cheap for a week and expensive for a year. Keeping only failures is cheaper but leaves you without the baseline you need to say a run was normal. - **In-band against out-of-band.** JMeter's own output is easy to collect and says almost nothing about the injector. Host metrics say a great deal but arrive from a different system with different retention, and now you need the two clocks to agree. ## The line to hold Whatever you choose, the standard has to be a property of the pipeline rather than of the engineer running the test. JMeter prints no verdict on any of this, and a run whose evidence was not collected cannot be re-argued later — the process has exited, the workspace is gone, and `jmeter.log` has already been truncated by the next run.

  • Why is capturing stdout not redundant when summariser.log is already on?
    They are the same lines in different places with different lifetimes. `jmeter.log` is truncated by the next run on that injector unless `-j` is used, while a captured stdout file lives with the job's other artefacts. Keeping both costs almost nothing and covers the case where one of them was lost.
  • What would you set summariser.interval to, and why is one figure hard to standardise?
    Set it from the shortest run in the suite: a three-minute test needs 5 or 10 seconds to be readable at all, while a two-hour soak at 10 seconds produces thousands of console lines. Many teams set it per plan rather than globally for exactly that reason.
  • How would you get injector CPU into the picture without changing the plans?
    From the host, not the tool. Apache JMeter 6 ships nothing that tracks it during a run, so the choice is a third-party listener added to every plan or ordinary host metrics collected alongside the run. The second keeps plans clean but needs the two clocks to agree so the series can be lined up.

saying these in an interview costs you the question

  • Assumes jmeter.log accumulates across runs on one injector
  • Archives artefacts only for runs that failed
  • Expects the summariser to report injector CPU or heap
  • Treats console scrollback as a durable record
  • Leaves summariser.interval at 30 seconds for three-minute runs