Manual Chapter :
Using a DNS cache sizing formula to tune DNS
cache
Applies To:
Show Versions
BIG-IP LTM
- 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
BIG-IP DNS
- 17.1.1, 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0
Using a DNS cache sizing formula to tune DNS
cache
About the DNS cache sizing formula
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.
Goals for analyzing results when using the
DNS cache sizing 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.
Recommendations for the nameserver and
message/RRset cache
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. (Anevictionoccurs 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).CHRis 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%.Acache hitresults 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 theSynchronousandQueriesfields. In order to find these fields, use the commandshow 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.
