How to configure JMeter to Handle Dynamic IPs and Load Balancer
Description
Do you see errors in JMeter while executing the performance testing, but not see such errors if you access the website manually during the load testing? If yes, then, there is a possibility you have not properly configured your JMeter script. Let’s configure JMeter to Handle Dynamic IPs and Loadbalancer before putting the load on such a website.
- Introduction
- Solution
- How is Java DNS caching related to this problem?
- Option 1: You can configure the TTL in the file java.security
- Option 2: DNS Cache Manager
Do you see errors in JMeter while executing the performance testing, but not see such errors if you access the website manually during the load testing? If yes, then, there is a possibility you have not properly configured your JMeter script. Let’s configure JMeter to Handle Dynamic IPs and Loadbalancer before putting the load on such a website.
This will paint your report red which no one wants as these errors are not related to the Application Under Test (AUT).
If JMeter is not configured properly for such a website then, you may observe the following:
- The requests are getting redirected to only one server and the other server is sitting idle while doing the load testing of the website that has multiple servers to balance the requests using a load balancer.
- Errors like “Target server failed to respond” or “Your hostname could not be resolved to an IP address” in JMeter or “java.net.SocketException: Software caused connection abort recv failed”
Here is what the results will look like. See below response data.
java.net.SocketException: Software caused connection abort: recv failed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at java.net.SocketInputStream.read(Unknown Source)
at sun.security.ssl.InputRecord.readFully(Unknown Source)
at sun.security.ssl.InputRecord.read(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source)
at sun.security.ssl.AppInputStream.read(Unknown Source)
at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:166)
at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:90)
at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:281)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:92)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:61)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:254)
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:289)
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:252)
at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:191)
at org.apache.jmeter.protocol.http.sampler.MeasuringConnectionManager$MeasuredConnection.receiveResponseHeader(MeasuringConnectionManager.java:201)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:300)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:127)
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:715)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:520)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.executeRequest(HTTPHC4Impl.java:517)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:331)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.followRedirects(HTTPSamplerBase.java:1490)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.resultProcessing(HTTPSamplerBase.java:1571)
at org.apache.jmeter.protocol.http.sampler.HTTPAbstractImpl.resultProcessing(HTTPAbstractImpl.java:463)
at org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:411)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1146)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1135)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261)
at java.lang.Thread.run(Unknown Source)
There are several reasons for this problem like insufficient hardware or generating unrealistic load, but if you think you are generating realistic load using decent hardware, but still getting those error then, Java DNS caching could causing the problem.
DNS Caching problem occurs if there is:
- A load balancer (for example, CDN)
- Or, IPs are dynamic (for example, services hosted on AWS)
Solution
Change the TTL, Java DNS Cache settings
Or, add DNS Cache Manager in JMeter (from JMeter 2.12 the DNS Cache Manager has been included as a configuration element)
How is Java DNS caching related to this problem?
What Java does is, caches the IP address against each domain name you access and the JVM default TTL is set to never re-resolve DNS names to IP addresses. This means that when the IP address for a resource changes, the application will be unable to connect to that resource until someone manually restarts the JVM so that the new IP addresses can be picked up. In these cases, it is vital that the TTL be configured to a shorter time period, like 60 seconds.
Option - 1
You can configure the TTL in the file java.security, which is located in the directory %JRE%libsecurity. The configured value specifies the number of seconds that the JVM should cache a successful DNS name lookup. Here is an example that shows how to configure the TTL to 60 seconds.
networkaddress.cache.ttl=60
Option - 2
Dzimitry Kashlach created the “DNS Cache Manager” which is available in JMeter 2.12 and later versions. DNS Cache Manager is bundled with JMeter you don’t have to add any additional jar file for this.
Ref: http://jmeter.512774.n5.nabble.com/DNS-Cache-Manager-improvement-for-testing-CDN-td5720797.html
Steps :
Add “DNS Cache Manager” Thread Group or Test Plan
Check “Clear cache each iteration”
It’s done
Find More Information About DNS Cache Manage
Leave a comment