DNS

The Challenge

Load testing presents challenges when working with dynamic DNS setups, such as CDNs or your own DNS-based load balancing.

While resolving a single IP address via a DNS call is relatively simple, resolving IPs that change over time or by location can create setup and execution issues. It also makes debugging more difficult. XLT offers several options to deal with these situations.

Standard DNS Resolution

Address resolution with Java is not perfect in the context of load tests that use DNS load-balancing concepts:

1. Java’s address resolution cache is global to the JVM. When an entry expires, it expires for all virtual users in that JVM at the same time. Consequently, if the IP address has changed, all traffic generated by that JVM hops from the current server to another almost immediately.
2. Java does not perform automatic round-robin for multiple IP addresses. Java caches IP addresses in the order received and returns them in the same order for the lifetime of the cache entry. This way, the first IP address typically gets all the traffic.

Logging

First, it is important to gain more insights into IP address resolution. You can enable additional IP data logging to get details about the IP used via the result data files.

xlt.dns.recordAddresses = true

Improve Distribution

XLT includes some enhancements to improve load distribution. To tackle the first issue, XLT can maintain a separate address resolution cache for each virtual user. This cache is valid for the lifetime of a virtual user’s session (i.e., one iteration). This softens the transition to the new IP address somewhat, as the current session still uses the old IP address. XLT fixes the second issue by automatically shuffling the IP addresses so that all IPs are utilized equally.

Enable these features by setting the following properties as needed:

xlt.dns.cacheAddresses = true
xlt.dns.shuffleAddresses = true

• cacheAddresses: Enables caching of resolved addresses for the entire lifetime of a WebClient, which is typically a transaction unless special scenarios have been implemented (e.g., to simulate using a second virtual browser).
• shuffleAddresses: Enables random selection of IPs from the returned list instead of always using the first one (Java’s standard behavior).

Use Only One Address

If a hostname is resolved to more than one IP address, the underlying HttpClient will try one IP after another until a connection can be established. This process is silent. Issues are noticed only if none of the given IPs can be contacted because only then will exceptions bubble up. This might lead to difficult-to-explain results, especially when the total request runtime and socket timings do not match.

If you suspect issues with one of the servers, but these issues are masked by the silent failover to another, you can debug this more effectively by limiting the selection list. Set the following property, and XLT will randomly pick a single IP address from the list of available addresses:

xlt.dns.pickOneAddressRandomly = true

If the server with the chosen IP address has issues, you will identify them immediately. When you combine this property with xlt.dns.recordAddresses=true, you will immediately know which IP/server instance is causing the issue.

Changing Cache Time

Java’s standard DNS handler sometimes caches entries beyond the regular cache lifetime announced during resolution. To override this and request new resolutions more often, set the cache duration. However, keep in mind that a low value might cause unwanted high traffic to your next resolver.

xlt.dns.providers.platform.cache.duration = 30

• cache.duration: The number of seconds an entry is available in Java’s global resolution cache.

Note that this value applies only to the Java resolution cache. When you set the alternative provider, this value is not used.

Using an Alternative Provider

XLT provides a second way of resolving DNS names, using dnsjava for that purpose. Before you change this, ensure you understand the problem you want to solve. DNS resolution by Java improves with new Java releases; hence, the reason for adding dnsjava to support eDNS and allow overriding DNS servers may no longer hold true.

Especially if you have trouble resolving DNS names behind CDNs where the CDN load balances using DNS entries, trying this alternative provider might be an option. It supports EDNS, an extension to DNS that allows the resolver to return data based on the user’s location instead of its own location or subnet.

xlt.dns.provider = platform

• provider: changes the underlying DNS service provider (“platform” or “dnsjava”); “platform” is the default value.

Additional settings allow customizing the behavior of dnsjava:

## Settings for the DnsJava-based DNS service provider.
## - resolver.servers ... the list of DNS server addresses (empty for system defaults)
## - resolver.timeout ... the DNS server timeout [s]
## - edns.version ....... the DNS extension version (-1 to disable extensions)
xlt.dns.providers.dnsjava.resolver.servers =
xlt.dns.providers.dnsjava.resolver.timeout = 5
xlt.dns.providers.dnsjava.edns.version = 0

The values shown are the defaults.