Caching can be considered effective in reducing the response time for clients when the cache-hit rate is high; that is, a relatively large number of requests are served from the cache instead of being sent to origin servers. For a high cache-hit rate, there should be sufficient memory to store cacheable responses from origin servers and the entries in the cache should be validated regularly.
Note:
Dynamic content is generally not cacheable. So if the application or content being served by the origin servers consists mostly of dynamic content, the cache-hit rate is bound to be low. In such cases, enabling and tuning caching might not yield a significant performance improvement.To improve the cache-hit rate, you can tune the following caching parameters:
Cache-entry replacement method
When the cache becomes full—that is, the number of entries reaches the maximum entries limit, or the cache heap size reaches the maximum cache heap space—further entries in the cache can be accommodated only if existing entries are removed. The cache-entry replacement method specifies how Oracle Traffic Director determines the entries that can be removed from the cache.
The default replacement method is Least Recently Used (lru). When the cache is full, Oracle Traffic Director discards the least recently used entries first.
The other available method is Least Frequently Used (lfu). When the cache is full, Oracle Traffic Director discards the least frequently used entry first.
In either method, every time Oracle Traffic Director serves content from the cache, it needs to track usage information—the time the content was served in the case of the lru replacement method, and the number of times the content was served in the case of lfu. So the time saved by serving content directly from the cache instead of sending the request to the origin server, is offset to a certain extent by the latency caused by the need to track usage information. Between the two methods, lru requires marginally lower computing resources.
You can disable cache-entry replacement by specifying false as the replacement method.
Maximum cache heap space
If only a small portion of the available heap space is used, it is possible that responses are not being cached because the virtual server-specific caching rules are defined too narrowly.
The optimal cache heap size depends upon how much system memory is free. With a large cache heap, Oracle Traffic Director can cache more content and therefore obtain a better hit ratio. However, the heap size should not be so large that the operating system starts paging cached content.
Maximum number of entries in the cache
If the number of entries in the cache, as shown in the perfdump report, is consistently near, or at, the maximum number of entries, it is an indication that the cache might not be large enough. Consider increasing the maximum number of entries.
If the number of entries in the cache is very low when compared with the maximum allowed entries, it is possible that responses are not being cached because the virtual server-specific caching rules are defined too narrowly.
Maximum size of cacheable object
To conserve system resources, you can limit the size of objects that are cached, even if the objects fulfill other caching rules.
If you observe that objects that are larger than the maximum cached object size are requested frequently, consider increasing the limit.
In a caching rule for a specific virtual server, you can specify the following parameters:
Minimum and maximum size of objects that can be cached
Minimum and maximum interval between cache-validation checks
Maximum number of characters in a query string that can be cached
Whether to compress content before caching
Whether to cache HTTPS responses