Starting with the BIG-IP^® system version 11.2.0, every traffic management microkernel (TMM) maintains a replicated copy of the cache. There are no checks preventing sizing a cache so large that it runs the TMM out of memory.

The general guideline for DNS cache sizing is the formula:

(msg + rrset + NS * 250b) * 2.5 * (# of TMMs-per-blade) <= 1/2 allocated TMM memory

where msg is message cache, a sub-cache of the DNS cache that contains the response to a specific DNS query.

rrset is RRset cache, a sub-cache of the DNS cache that contains the resource record set data referenced by the message cache. In the case of very simple A/AAAA queries, responses may be generated directly from the RRSet cache.

NS is nameserver cache, a sub-cache of the DNS cache that contains metadata about nameservers used to resolve DNS queries. Information in this sub-cache is used to aid back-end name resolution, and is only used on a cache miss. Transparent caches do not have a nameserver sub-cache.

If configuring multiple caches, consider the cumulative size of all caches in the formula.

You have several goals to consider when analyzing results from the DNS cache sizing formula:

• Maximize cache hits; reduce back-end traffic.
• Maximize system throughput (responses/sec).
• Optimize system resource (CPU/memory) utilization.

F5^® makes some specific recommendations for the nameserver and message/RRset cache:

Nameserver cache (non-transparent caches only)

Populating the nameserver cache with a new entry generally results in more internally replicated data than with the other types of caches, resulting in a higher CPU cost. To reduce this cost, you should size the nameserver cache to reduce the eviction rate to a relatively low value. (An eviction occurs when valid data, TTL has not expired, is removed from a sub-cache to make room for new data.)

Recommendation: Double the NS value from the DNS cache sizing formula, until the eviction rate is low and stable.

Aside from staying within the sizing formula, there is no connection between the size of the nameserver cache and the other cache sizes. This differs from previous guidance, which suggested that you double the nameserver cache size whenever the message cache size was doubled.

Message and RRset cache

These caches are sized with the goal of optimizing the Cache Hit Ratio (CHR). CHR is the ratio of cache hits to queries. It is calculated as a percentage: (Synchronous/Queries)*100. Caches are generally considered to be performing well with a CHR above 80%.

A cache hit results from a DNS query that a BIG-IP^® device can answer from information already contained within its sub-caches with no back end queries. This is tracked in the Synchronous and Queries fields. In order to find these fields, use the command show ltm dns cache resolver <cachename>.

Maximizing the cache sizes provides the highest CHR, but might result in unnecessary CPU utilization. Maintaining a larger cache is expensive due to the cost of longer cache access times for both lookups and insertions.

Keeping in mind the DNS cache sizing formula, you can double these caches until you observe no significant improvement (> 1%) in CHR.

Recommendation: Once a doubling does not produce a significant improvement, revert to the previous value.

The default ratio for these two caches is 10:1 (RRset:Message), which produces good results in testing, particularly with query sets that include predominantly A/AAAA query types.