What is Dynamic Caching, and when should it be used?

Short answer

Dynamic Caching adds the request information selected in the Key list (such as language, device, country, cookie) to the cache key in the Cache profile, alongside the address; separate copies are kept for the same address according to this information. It is used for caching content that varies by language, device, country or user. Since each additional value increases the number of copies, the hit ratio drops and memory usage increases.

How Does It Work?

In the standard cache, a single copy of an address is kept and that copy is served to everyone. When Dynamic caching is turned on, each value in the Key list is appended to the end of the key; requests whose values differ get separate copies.

	Standard cache	Dynamic caching
Key	Host + path + query string	The same key + the selected Key values
Copies for one address	1	As many as the different combinations of the Key values
Suitable content	Content that is the same for everyone	Content that varies by header, cookie or client

What does the content vary by?	Smart Variable to add to the Key
Language	Request HTTP header content (Accept-Language)
Device type	Request HTTP header content (the header that distinguishes the device)
Country	Client Country
Session (user-specific)	Request Cookie Content (the name of the session cookie)

Dynamic Caching in TR7

• Where: Load Balancer → Profiles → Cache → right-click on the profile row → Edit (or Add) → the Dynamic Caching switch is turned on → Smart Variables are added to the Key list → Save. At least one variable is required; if the same variable is added twice, the "There are duplicate values" warning appears. It is off by default.
• vService type: HTTP only.
• Effect of the change: The save is applied without dropping open connections; the copies in the cache are deleted. In a cluster, it is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
• Monitoring: On the Details tab in the preview of the profile, the Key row shows the selected variables (preview of the selected profile); the hit ratio is monitored on the Frontend Cache Hit Ratio graph on the vService dashboard.
• Verification: When the same address is requested with curl -s -o /dev/null -D - -H "Accept-Language: tr" https://www.example.com/ and then with en, each language first gets TRCACHE: MISS and, on repetition, TRCACHE: HIT.
• WEB-CLI: The --dynamicCaching true and --dynamicCachingKeys.0 fields are used (dynamic caching).

When?

• Used: Language versions by Accept-Language, mobile and desktop pages by device type, content by country, user-specific cache by session cookie.
• Not used: Static files that are the same for everyone (they produce unnecessary copies) and values that differ for each client, such as the client IP (memory fills up quickly).

Common Misconceptions

• "Dynamic caching caches according to the selected value instead of the address." The selected values do not replace the address; they are added to the key.
• "More keys give a better result." Each key multiplies the number of copies; the hit ratio drops.
• "The client IP is enough to distinguish the user." Users behind NAT share the same IP; for user-specific caching, the session cookie is preferred.

How it is done in the documentation

• Cache · Dynamic Caching
• Cache · Recommended Values and Tuning Guide
• WEB-CLI · Dynamic Caching

Related questions

• Are the query string and Host Header part of the cache key; can I change this?
• How do I prevent user-specific content from being cached by mistake?
• What is a Smart Variable; how is it used in conditions and actions?