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:
F5® makes some specific recommendations for the nameserver and message/RRset cache:
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.
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.