Headless Execution

JMeter prints it on every GUI launch because the GUI is for creating and debugging a plan, not for driving load. The banner also gives the command line to use instead: jmeter -n -t [jmx file] -l [results file] -e -o [report folder].

HEAP. Apache JMeter's bin/jmeter launcher defaults it to -Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m, so an injector starts with a fixed one-gigabyte heap unless HEAP is exported first, normally from bin/setenv.sh.

Most JMeter listeners keep every sample they receive, View Results Tree and View Results in Table included. Simple Data Writer keeps none - it writes the row and lets the result go, so load runs use it.

JMeter's -J flag defines a JMeter property inside the running JMeter instance; -D defines a Java system property in the JVM. Both take name=value, may be repeated, and are applied while JMeter starts up.

Each of the 500 threads calls the listener inside its own loop and queues behind one shared buffer. In GUI mode that buffer holds up to 500 whole sample results, response bodies included, redrawn twice a second.

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.

The -f flag, long form --forceDeleteResultFile. It deletes existing results files and the web report folder before the test starts. Without it, JMeter opens an existing CSV results file in append mode and never rewrites the header.

Maximum 4 GB, initial still 1 GB. The launcher expands HEAP's default first and appends JVM_ARGS afterwards, so the later -Xmx4g wins while -Xms1g and -XX:MaxMetaspaceSize=256m stay on the line untouched.

One real platform thread, its own clone of everything under that Thread Group, and its own copy of the variables. Plan size therefore multiplies by thread count before the first request goes out.

The bin/jmeter launcher places everything you type after -jar ApacheJMeter.jar, so the JVM treats it as an application argument. JMeter's own parser matches -D and calls System.setProperty during its startup.

JMeter's -p names the base property file to load instead of bin/jmeter.properties and may appear only once. -q names an extra property file merged on top of the current set, and may be repeated.

The -o folder must not exist or must be empty. JMeter checks it before loading the plan, so the first night's dashboard files make the second night abort with 'Cannot write to ... as folder is not empty' and exit status 1.

It exports JMETER_COMPLETE_ARGS=true before calling bin/jmeter, which makes that script set ARGS empty. Only JVM_ARGS and JMETER_OPTS then reach java, so HEAP, GC_ALGO and the OOM heap-dump flag are all dropped.

Every HTML response is parsed on the sampling thread, and each asset becomes another request whose result hangs off a container result JMeter builds for the page. That container can carry dozens of results, and every listener sees all of them.

JMeter applies command-line property options in the order they appear. The -q file is read after the -J flag and copies its own env.host over the value the flag had just set.

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.

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.

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.

Move the setting into bin/setenv.sh, which bin/jmeter sources before applying its own defaults and which an upgrade cannot overwrite. Set the whole HEAP string per machine class, and forbid edits to the shipped launcher.

Set a default the injector can always afford - a lean writer, errors only, nothing retained - and make richer recording an explicit, time-boxed exception that someone owns rather than a habit plans drift into.

Put each environment's stable values in a reviewable -q property file per environment, and reserve -J for the few values that genuinely vary run to run. Keep credentials out of -J, whose value JMeter logs verbatim.

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.

The most recently opened test plan from the JMeter GUI's Open Recent list, which lives in the Java user preferences node for LoadRecentProject. On a host where that user never ran the GUI it resolves to nothing.

VERBOSE_GC is a slot the launcher expands into the JVM options between HEAP and GC_ALGO. Apache ships it unset, with two commented-out -Xlog:gc candidates, so you must uncomment one or export your own.

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.

JMeter reads the whole argument as a path to a properties file and loads every key in it into the global property set. If that path cannot be read, JMeter does nothing and logs nothing.