skip to content

How would you standardise the JMeter CLI line and artefact paths a team's nightly load run uses?

level: principalimportance: should knowfreq 36%

answer

  1. One line everybody copies, nothing improvised
  2. Two different base directories are in play
  3. Clean artefacts, by deletion or by naming
  4. Some flags are worth banning outright

basics

~20 s

Fix one canonical invocation: absolute paths or a fixed working directory, an explicit .jmx rather than LAST, clean artefacts each run via -f or a fresh name, -e paired with -l and an empty -o folder, and the run log kept somewhere readable.

solid answer

~40 s

Treat the line itself as the standard. Decide **paths** first, because JMeter uses two bases: relative names inside the plan resolve against the `.jmx` directory (`FileServer.setBaseForScript` is called with the `-t` file), while `-l` and `-j` follow the process's working directory. Either go absolute or fix the working directory for every caller. Decide the **artefact lifecycle** next: `-f` to clear and reuse one path, or a stamped name per run — noting that only `-j` gets JMeter's paired-single-quote date expansion, so `-l` and `-o` stamps have to be built beforehand. Ban `-t LAST` (a per-OS-user GUI preference that resolves to nothing on a fresh host and fails quietly), keep debug `-L` levels out, and keep environment-specific values in the property files `-p` and `-q` name rather than on the line.

go deeper

for a junior

Follow the team's canonical line rather than inventing one, and ask where its artefacts are meant to land before changing a path.

for a middle

Be able to justify each flag in the standard line and explain what would break if it were dropped, especially -f and the -e plus -l pairing.

for a senior

Own the failure modes: which misconfigurations exit 1, which exit 0, and what evidence survives a night that died before sampling.

for a principal

Make the call between clearable and accumulating artefacts, define what counts as a run, and keep the standard small enough that a reviewer can check it in five questions.

## Start from the one line everyone will copy There is no single right answer here, but there is a right shape: one canonical invocation the team reads as the definition of "a run", with every value in it explained. Something like ``` jmeter -n -t /srv/plans/checkout.jmx \ -l /srv/runs/checkout/results.jtl \ -j "/srv/runs/checkout/jmeter_'yyyyMMdd-HHmmss'.log" \ -i /srv/plans/log4j2.xml \ -f -e -o /srv/runs/checkout/report ``` Everything below is a defensible variation on that. What is not defensible is leaving each of these decisions to whoever types the line. ## Decide where the artefacts land — the paths are not symmetric This is the part teams get wrong, because two different base directories are in play: - `FileServer.setBaseForScript` is called with the `-t` file, so relative names **inside the plan** resolve against the directory holding the `.jmx`. - The `-l` and `-j` arguments are ordinary paths resolved by the JVM, so relative names there follow the process's working directory. - One exception: a `-l` value beginning with `~/` (the `jmeter.save.saveservice.base_prefix` default) is rebased onto the plan's directory — it does **not** mean the home directory. A shell will normally have expanded a bare `~/` long before JMeter sees it, so this only bites when the value was quoted. Two workable standards: absolute paths for everything on the line, or a fixed working directory that every caller enters first. Pick one and write it down; mixing them is what produces the "the results file is somewhere" bug. ## Decide the artefact lifecycle | Choice | Line | Trade | |---|---|---| | Clear and reuse | `-f -l results.jtl -e -o report` | Stable, hard-codeable paths; no history on the box | | New name per run | `-l results-<stamp>.jtl -o report-<stamp>` | Full history; every consumer must be told the stamp | Remember what JMeter will and will not build for you: the paired-single-quote date pattern is applied to the `-j` run-log name only. `-l`, `-o` and `-t` are used as given, so a stamped name for those has to be assembled before the process starts. And `-f` is not a truncate — it deletes every `ResultCollector`'s file in the tree and empties the `-o` folder. ## Decide what is banned from the line - **`-t LAST`.** It reads the GUI's recent-file list out of Java user preferences, so it is per-OS-user, GUI-written, and resolves to nothing on a fresh host. The failure is quiet: a usage message and an exit status of 0. - **GUI runs as evidence.** The banner JMeter prints at every GUI start is the team rule as much as the tool's: authoring and debugging there, measuring under `-n`. - **Ad-hoc `-L` levels.** `-L` changes what the run writes; a debug level left in the standard line changes the log volume of every night. ## Decide what belongs elsewhere, and say so Half of standardising an invocation is refusing to put things in it: 1. Environment-specific values — hosts, credentials, thread counts — belong in the property files `-p` and `-q` point at, and the property-injection flags are a subject of their own. 2. Wrapping the line in a scheduled job or a build step is a separate concern; this decision is about the line itself, so that it behaves identically however it is launched. 3. Reading the JTL or the dashboard the run produces, and turning either into a verdict, is downstream work. JMeter's exit status reports whether the *invocation* was legal and whether it could write where you pointed it — a run of nothing but errors still ends with status 0. ## Make the standard checkable The cheapest enforcement is a dry, boring checklist a reviewer can apply to any invocation: - Is every path on the line absolute, or is the working directory fixed? - Does the run start from clean artefacts, by `-f` or by a fresh name? - Is the plan named explicitly rather than by `LAST`? - Is `-e` accompanied by `-l`, and is the `-o` folder empty or cleared? - Is the run log captured somewhere a human can read it after the fact? If those five hold, the line is reproducible by anyone on the team on any box, which is the whole point of standardising it.

  • Why insist on absolute paths rather than relying on the working directory?
    Because JMeter does not use one base. Relative names inside the plan resolve against the .jmx directory, while -l and -j resolve against the process's working directory. Absolute paths remove the difference; a fixed working directory works too, but only if every caller honours it.
  • When would you argue against -f in the standard line?
    When the raw JTLs are the historical record. -f deletes every ResultCollector's file and empties the report folder, so a night that fails halfway has already destroyed the previous night's evidence. In that case give each run its own results file and folder and prune them on a schedule instead.
  • What deliberately does not belong on the standardised line?
    Environment-specific values, which belong in the property files -p and -q point at; anything that turns the results into a pass or fail verdict, which JMeter's exit status does not express; and debug log levels set with -L, which change what every night writes.

saying these in an interview costs you the question

  • Leaves each engineer to compose their own invocation
  • Assumes one base directory resolves every path on the line
  • Keeps -t LAST in a scheduled run for convenience
  • Expects a non-zero exit status when responses fail
  • Reuses one report folder without -f and calls the failure flaky
  • Puts environment-specific values directly on the command line