In a JMeter run against a load-balanced hostname, why does every thread hit the same backend IP?

seniorshould knowfreq 45%

answer

One address for the whole fleet
The JVM decided before JMeter did
A config element with its own resolver
Only one sampler implementation honours it

basics

~20 s

Without a DNS Cache Manager, JMeter resolves the hostname through the JVM's own DNS cache, so every thread reuses the first address that came back. Adding the element gives each thread a private resolution cache instead.

solid answer

~50 s

JMeter runs in one JVM, and by default name resolution goes through that JVM's DNS cache. The first lookup wins for the whole process, so a hostname that resolves to a rotating set of addresses collapses to one, and only one member of the cluster takes load. The DNS Cache Manager exists for exactly this: it resolves names per thread and keeps the results in its own cache, independent of both the JVM and the OS. Two constraints matter. It works only with the HttpClient4 sampler implementation — a sampler left on Java ignores it entirely — and the manual says to put it at the root of a Thread Group or Test Plan rather than under a single HTTP Request. Clear cache each iteration decides whether a thread re-resolves at each iteration boundary or keeps its address for the whole run.

JMeter runs in one JVM, and by default name resolution goes through that JVM's DNS cache. The first lookup wins for the whole process, so a hostname that resolves to a rotating set of addresses collapses to one, and only one member of the cluster takes load. The **DNS Cache Manager** exists for exactly this: it resolves names per thread and keeps the results in its own cache, independent of both the JVM and the OS. Two constraints matter. It works only with the **HttpClient4** sampler implementation — a sampler left on `Java` ignores it entirely — and the manual says to put it at the root of a Thread Group or Test Plan rather than under a single HTTP Request. **Clear cache each iteration** decides whether a thread re-resolves at each iteration boundary or keeps its address for the whole run.

code

xml · 5 lines

xml

<DNSCacheManager guiclass="DNSCachePanel" testclass="DNSCacheManager" testname="DNS Cache Manager" enabled="true">
  <collectionProp name="DNSCacheManager.servers"/>
  <boolProp name="DNSCacheManager.clearEachIteration">true</boolProp>
  <boolProp name="DNSCacheManager.isCustomResolver">false</boolProp>
</DNSCacheManager>

go deeper

for a junior

Recall that JMeter has a DNS Cache Manager element and that without it the whole run can talk to one address.

for a middle

Explain that resolution is per thread once the element is present, and that only HttpClient4 samplers honour it.

for a senior

Spot a run that measured one backend, place the element correctly, and understand what re-resolving each iteration does to your figures.

for a principal

Decide whether the team's plans should pin hosts through the Static Host Table or spread across a cluster, and make that part of the plan template.

Why one IP wins

A load-balanced hostname often resolves to several addresses, and a browser fleet spreads across them because each machine resolves independently. JMeter is one process. Java caches successful lookups inside the JVM, so the first resolution the run performs is the one every thread inherits. The result is a run that reports the capacity of a single backend while the report claims to describe the cluster.

The manual states this directly in the DNS Cache Manager's own description: by default JMeter uses the JVM DNS cache, and that is why only one server from the cluster receives load.

What the element changes

The DNS Cache Manager resolves names for each thread separately and stores the results in its own cache, independent of both the JVM and the OS caches. Each thread has its own copy of the element and therefore its own map of hostname to addresses.

Its fields:

Clear cache each iteration — when set, a thread's DNS cache is emptied at the start of each iteration, so it resolves again and may land somewhere new;
Use system DNS resolver — the default radio option; lookups go through the platform resolver;
Use custom DNS resolver — lookups go through the bundled dnsjava resolver, using the DNS Servers table if you fill it in, or the machine's configured servers if you leave it empty;
Static Host Table — a Host to Hostname or IP address mapping that acts like an /etc/hosts entry scoped to the plan. The manual states that Use custom DNS resolver has to be enabled for this mapping to be used.

The static host table is the quiet win here: you can point www.example.com at a specific test host without touching the machine, and the requests still carry www.example.com in their headers.

The two constraints that catch people

HttpClient4 only. The manual carries an explicit note, and the code bears it out — only the HttpClient4 implementation is handed the manager as its DNS resolver. A plan whose samplers are set to Java, or a JMeter whose jmeter.httpsampler property points at the Java implementation, gets nothing from the element and no warning either.
Placement. The manual says to use it at the root of a Thread Group or Test Plan, and not as a child of a particular HTTP Sampler.

Reading the effect on your numbers

When you add the element and tick Clear cache each iteration, the second iteration is no longer guaranteed to be the cheap one. A thread that kept a resolved address had a warm path to a specific backend; a thread that re-resolves may reach a different, colder member of the cluster. The numbers you were about to report change, and they change because of a client-side setting rather than anything the system under test did.

That is the general shape of everything in this family of elements: the cookie store, the cache and the DNS cache all make iteration two cheaper than iteration one, and each of them has its own switch for whether that is allowed. What the resulting number means for capacity is a question for the performance-foundations material; what JMeter gives you is the switch and an honest label for it.

A short checklist

Confirm the samplers are on HttpClient4 before you conclude the element does not work.
Put the manager at the Thread Group or Test Plan root.
Decide Clear cache each iteration deliberately and write the choice into the plan, not into someone's memory.
If you need a fixed mapping, use the Static Host Table with the custom resolver rather than editing the injector's hosts file, so the plan is self-describing.

## Why one IP wins A load-balanced hostname often resolves to several addresses, and a browser fleet spreads across them because each machine resolves independently. JMeter is one process. Java caches successful lookups inside the JVM, so the first resolution the run performs is the one every thread inherits. The result is a run that reports the capacity of a single backend while the report claims to describe the cluster. The manual states this directly in the DNS Cache Manager's own description: by default JMeter uses the JVM DNS cache, and that is why only one server from the cluster receives load. ## What the element changes The **DNS Cache Manager** resolves names for each thread separately and stores the results in its own cache, independent of both the JVM and the OS caches. Each thread has its own copy of the element and therefore its own map of hostname to addresses. Its fields: - **Clear cache each iteration** — when set, a thread's DNS cache is emptied at the start of each iteration, so it resolves again and may land somewhere new; - **Use system DNS resolver** — the default radio option; lookups go through the platform resolver; - **Use custom DNS resolver** — lookups go through the bundled dnsjava resolver, using the **DNS Servers** table if you fill it in, or the machine's configured servers if you leave it empty; - **Static Host Table** — a `Host` to `Hostname or IP address` mapping that acts like an `/etc/hosts` entry scoped to the plan. The manual states that `Use custom DNS resolver` has to be enabled for this mapping to be used. The static host table is the quiet win here: you can point `www.example.com` at a specific test host without touching the machine, and the requests still carry `www.example.com` in their headers. ## The two constraints that catch people 1. **HttpClient4 only.** The manual carries an explicit note, and the code bears it out — only the HttpClient4 implementation is handed the manager as its DNS resolver. A plan whose samplers are set to `Java`, or a JMeter whose `jmeter.httpsampler` property points at the Java implementation, gets nothing from the element and no warning either. 2. **Placement.** The manual says to use it at the root of a Thread Group or Test Plan, and not as a child of a particular HTTP Sampler. ## Reading the effect on your numbers When you add the element and tick **Clear cache each iteration**, the second iteration is no longer guaranteed to be the cheap one. A thread that kept a resolved address had a warm path to a specific backend; a thread that re-resolves may reach a different, colder member of the cluster. The numbers you were about to report change, and they change because of a client-side setting rather than anything the system under test did. That is the general shape of everything in this family of elements: the cookie store, the cache and the DNS cache all make iteration two cheaper than iteration one, and each of them has its own switch for whether that is allowed. What the resulting number means for capacity is a question for the performance-foundations material; what JMeter gives you is the switch and an honest label for it. ## A short checklist - Confirm the samplers are on HttpClient4 before you conclude the element does not work. - Put the manager at the Thread Group or Test Plan root. - Decide `Clear cache each iteration` deliberately and write the choice into the plan, not into someone's memory. - If you need a fixed mapping, use the Static Host Table with the custom resolver rather than editing the injector's hosts file, so the plan is self-describing.

What does JMeter's DNS Cache Manager Static Host Table let you do?
Map a hostname to another hostname or a literal address inside the plan, the way an `/etc/hosts` entry would, without touching the machine. You type the name in the `Host` column and the target in `Hostname or IP address`. The manual requires `Use custom DNS resolver` to be selected for the mapping to apply.
Does a DNS Cache Manager change how JMeter's Java sampler implementation resolves hosts?
No. Only the HttpClient4 implementation is handed the manager as its DNS resolver, so a sampler left on `Java` resolves through the JVM exactly as before and the element has no effect on it — silently.

saying these in an interview costs you the question

Blames the load balancer instead of name resolution
Puts the DNS Cache Manager under a single HTTP sampler
Expects it to spread load without checking the clearing option
Expects it to work with the Java sampler implementation
Thinks it overrides the OS hosts file for the whole machine

Why one IP wins

The manual states this directly in the DNS Cache Manager's own description: by default JMeter uses the JVM DNS cache, and that is why only one server from the cluster receives load.

What the element changes

Its fields:

Clear cache each iteration — when set, a thread's DNS cache is emptied at the start of each iteration, so it resolves again and may land somewhere new;

Use system DNS resolver — the default radio option; lookups go through the platform resolver;

Use custom DNS resolver — lookups go through the bundled dnsjava resolver, using the DNS Servers table if you fill it in, or the machine's configured servers if you leave it empty;

Static Host Table — a Host to Hostname or IP address mapping that acts like an /etc/hosts entry scoped to the plan. The manual states that Use custom DNS resolver has to be enabled for this mapping to be used.

The static host table is the quiet win here: you can point www.example.com at a specific test host without touching the machine, and the requests still carry www.example.com in their headers.

The two constraints that catch people

HttpClient4 only. The manual carries an explicit note, and the code bears it out — only the HttpClient4 implementation is handed the manager as its DNS resolver. A plan whose samplers are set to Java, or a JMeter whose jmeter.httpsampler property points at the Java implementation, gets nothing from the element and no warning either.

Placement. The manual says to use it at the root of a Thread Group or Test Plan, and not as a child of a particular HTTP Sampler.

Reading the effect on your numbers

A short checklist

Confirm the samplers are on HttpClient4 before you conclude the element does not work.

Put the manager at the Thread Group or Test Plan root.

Decide Clear cache each iteration deliberately and write the choice into the plan, not into someone's memory.

If you need a fixed mapping, use the Static Host Table with the custom resolver rather than editing the injector's hosts file, so the plan is self-describing.

In a JMeter run against a load-balanced hostname, why does every thread hit the same backend IP?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Why one IP wins

What the element changes

The two constraints that catch people

Reading the effect on your numbers

A short checklist

▾common follow-ups2 questions

▾red flags5 flags

Why one IP wins

What the element changes

The two constraints that catch people

Reading the effect on your numbers

A short checklist

answer

go deeper