skip to content

In a JMeter plan replicated to six engines, what do ${__machineName} and ${__machineIP} return on each one?

level: middleimportance: nice to knowfreq 32%

answer

  1. Information functions, no required arguments
  2. Local to the JVM that evaluates them
  3. One optional argument: a variable name
  4. Identical container names defeat it

basics

~10 s

The host name and IP address of the machine that evaluates them - so each engine returns its own. They are the built-in way to tell six identical copies of one replicated plan apart.

solid answer

~40 s

Both are information functions that report the **local** machine: `${__machineName}` returns `InetAddress.getLocalHost().getHostName()` and `${__machineIP}` returns `getHostAddress()`, each computed once per JVM and cached. Because a replicated plan's body is evaluated by the engine that runs it, six engines running the identical plan produce six different values - which is exactly what makes them useful, since JMeter offers no per-engine section in a plan. Each takes one optional argument, the name of a variable to also store the result in, so `${__machineName(SERVER_ID)}` returns the name and sets `SERVER_ID` at the same time. Both can be written with or without parentheses. The catch is that the value is whatever the host's own name resolution returns, so identically-named containers give you six identical answers and the trick silently stops distinguishing anything.

code

text · 6 lines
text
${__machineName}                 -> gen3          (this engine's host name)
${__machineIP}                   -> 10.4.0.13     (this engine's address)
${__machineName(SERVER_ID)}      -> gen3          and sets the variable SERVER_ID

Use in a CSV Data Set Config Filename field:
    data/logins-${__machineName}.csv

go deeper

for a junior

Know that these two functions report the machine running the element, not the machine that started the test. On six JMeter engines you get six answers from one plan.

for a middle

Explain why: the plan is evaluated on the engine, so a local-host lookup is the engine's. Mention the optional argument that also stores the value in a variable.

for a senior

Show the failure mode. Identically-named containers give one name on every engine and the per-engine file naming collapses silently, so verify the names are distinct before depending on them.

for a principal

Decide what an engine's identity is and make it deliberate. If the platform supplies hostnames you do not control, assign the identity yourself rather than inheriting whatever name resolution happens to return.

## What they return, and where `${__machineName}` and `${__machineIP}` are information functions with no required arguments. One asks the JVM for the local host's name, the other for its address, and both cache the answer for the life of the process. In a standalone run that is the machine you started JMeter on and the functions are barely interesting. In a distributed run they become the one identity a replicated plan has. The controller sends every engine the same tree; each engine precompiles and evaluates it in its own JVM; so the same `${__machineName}` in the same element resolves to `gen1`, `gen2`, `gen3` and so on, one value per engine, with no branching in the plan and no per-engine element. ## The optional argument Each function accepts at most one argument: **the name of a variable to store the result in**. The function still returns the value as well. ``` ${__machineName} the engine's host name ${__machineName()} identical - the parentheses are optional ${__machineName(SERVER_ID)} returns the name and also sets the variable SERVER_ID ${__machineIP} the engine's IP address ${__machineIP(SERVER_IP)} returns the address and also sets SERVER_IP ``` Storing it in a variable once, high in the plan, is usually neater than calling the function in a dozen places. ## What they are actually used for - **Per-engine data files.** A Filename of `data/logins-${__machineName}.csv` makes each engine open a different file, which is one of the two ways to stop six engines dealing out the same rows. - **Per-engine identity in the traffic.** Stamping the engine's name into a header or a request field makes the target's own logs attributable to a generator. - **Per-engine output paths.** Anything the plan itself writes on the server needs a name that will not collide when six engines write it. - **Confirming the topology.** Recording the value with the results is a cheap proof that the run really used six distinct machines and not the same one addressed twice. ## Where it breaks | Situation | What the function gives you | |---|---| | Six named hosts with working name resolution | Six distinct names - the intended case | | Containers built from one image, hostname unset | The same name on every engine | | A host whose name resolves to a loopback entry | A name that identifies nothing useful | | Two engines on one box on different ports | The same name for both | The last two rows are the quiet failures. Nothing errors: the per-engine file name simply collapses to one name, every engine opens the same file, and you are back to duplicated rows with no warning. If you use these functions to differentiate engines, verify the names are distinct before you rely on them - and prefer `${__machineIP}` when hostnames are unreliable, or set the container hostnames explicitly so the name is yours rather than the platform's. ## A note on scope These functions tell you *which machine*, not *which slice*. There is no built-in function that reports an engine's index within the run or how many engines the controller started, so you cannot compute a share from them - you can only key off an identity you already arranged. That is the same limitation the whole replicated-plan model has: JMeter will tell a replica who it is, but it will never tell it what fraction of the work is its own.

  • Why does ${__machineName} return the engine's name rather than the controller's during a distributed run?
    Because the controller ships the plan as serialised elements and each engine precompiles and evaluates that tree in its own JVM. The function asks the local JVM for its host name, and the local JVM is the engine's.
  • Is there a JMeter function that tells an engine its index among the engines in the run?
    No. JMeter 6.0.0 ships no function reporting an engine's ordinal or the total engine count, because a replicated plan has no notion of a slice. Any per-engine share has to come from an identity you arranged yourself, such as the machine name or a per-server property.

saying these in an interview costs you the question

  • Says the function returns the controller's host name.
  • Relies on it across containers that all share one hostname.
  • Expects it to report the engine's index within the run.
  • Thinks it is re-evaluated per sample rather than cached per JVM.
  • Uses it to compute a share of the load rather than an identity.