An overview on F5 LTM Caching for 10.x code version
F5 LTM Cache
- F5 LTM RAM Cache is used to cache HTTP objects in the F5’s RAM.
- High Demand HTTP objects / Static Content can be stored on the F5 and served till the expiration period for the object.
- RAM Cache feature in F5 is compliant with RFC 2616.
F5 LTM Cache Eligibility
- Any response with the following status code 200, 203, 206, 300, 301 and 410 to a GET request, is cached by default.
- Any non-GET method request to URI can be cached by adding the URI to the “Include List” or “Pin List” Difference between “Include List” and “Pin List”
- Both Lists are used to store objects that are NOT cached by default.
- “Pin List” will store the object, ignoring the expiry information provided by the header. The object will be cached even after the expiry timer – like a permanent cache. “Include List” will store the object, honoring the Cache headers.
Exclude List
- Any object that can be stored by the F5 LTM cache, by default (GET Request + relevant status code) can be “excluded” from being cached by adding it to this list.
If you want to enable or disable caching, use an iRULE along with HTTP Caching profile:
when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/static" } {
CACHE::disable
}
}
With Caching enabled on the HTTP profile, the above iRULE will cache any valid object (defined by HTTP profile) but will NOT cache requests with “/static” uri, even if they satisfy the cache requirement.
NOTE
When you use “CACHE::enable” for any iRule, it will cache the relevant object even if the response headers prevent it from being cached. I would recommend using reverse logic – Use “Cache::disable” for any object that should NOT be cached and any object that should be cached will be taken care by the HTTP Caching profile based on the response headers.
Cache Control Headers
HTTP headers that are given importance by F5 LTM as per RFC:
- Expires
- Last-Modified
- Cache-Control
Cache-Control
HTTP 1.1 introduced a new class of headers, Cache-Control response headers, to give Web publishers more control over their content, and to address the limitations of Expires.
Useful Cache-Control response headers include:
max-age=(seconds) — specifies the maximum amount of time that an representation will be considered fresh. Similar to Expires, this directive is relative to the time of the request, rather than absolute. Seconds is the number of seconds from the time of the request you wish the representation to be fresh for.
s-maxage=(seconds) — similar to max-age, except that it only applies to shared (e.g., proxy) caches.
public — allows caches (shared and private) to store the response.
private — allows caches that are specific to one user (e.g., in a browser) to store the response; shared caches (e.g., in a proxy) may not.
no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.
no-store — instructs caches not to keep a copy of the representation under any conditions.
must-revalidate — tells caches that they must obey any freshness information you give them about a representation. HTTP allows caches to serve stale representations under special conditions; by specifying this header, you’re telling the cache that you want it to strictly follow your rules.
proxy-revalidate — similar to must-revalidate, except that it only applies to proxy caches.
For example:
Cache-Control: max-age=3600, must-revalidate
When both Cache-Control and Expires are present, Cache-Control takes precedence.
This is a good document about Caching – Caching Tutorial
F5 RAM Cache Setting
In this case, default “HTTP” profile is used as a parent profile for the “PROF_HTTP_CACHE” custom profile.
In this example, a snapshot of F5 Cache Settings is provided:
RAM Cache: This needs to be Enabled for Caching to be implemented.
Maximum Cache Size: Total memory that is used for caching by this profile.
Maximum Entries: Number of HTTP objects that is cached.
Maximum Age: This is the duration till which the HTTP object is cached. Regardless of this value, RAM Cache will flush any object that is considered to be “expired” based on the Cache Control Headers.
Minimum Object Size: Any object that is equal to or greater than this value can be cached, if its headers allow it to be cached.
Maximum Object Size: Any object that is equal to or lesser than this value can be cached, if its headers allow it to be cached.
Ignore Headers: These are specific Headers that are provided by the Client-side, if Client requries “fresh/non-cached” objects. By default, it is set to ignore these Client Side headers (Ignore Headers : ALL). In effect, even if the Client requires a “non-cached” object, F5 can serve a cached object, provided such an object exists in its RAM Cache. If you want F5 to obey client-side cache-control headers, set “Ignore Headers : None”.
An Example
- HTTP Server has to be configured to serve the HTTP objects with the correct Header for caching.
This link can be used to test out the “Cacheability” of a site:
For any cache-able resource this MUST exist in order to honor caching:
- “Expires” or “Cache-Control” header MUST exist
- “Last-Modified” or “ETag” header MUST exist
In the above Header list, “ETag” is not considered by F5 LTM. So, for caching on F5:
- “Expires” or “Cache-Control”
- “Last-Modified”
Caching will occur even without the above headers but in that case, it is tough to control the expiry time and each proxy has its own algorithm to determine the cache-ability of an object and this is not optimum. While troubleshooting, make sure that the server’s response contains the headers specified.
If you use a specific HTTP link, the response provides information on the Header:
https://redbot.org/?uri=http%3A%2F%2Fwww.yahoo.com
You can move the cursor on the specific headers to get more information on the specific headers.
Cached Header Response
In this example, the “Date” and “Age” headers were inserted by the F5 to indicate the “Date” at which the F5 received the HTTP request and the “Age” of the cached object that was served. If Client should not see these values, then you can disable it under the “Insert Age Header” variable in the F5’s HTTP profile that is used for enabling caching.
$ curl -vk http://domain.com
> GET / HTTP/1.1
> User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.10
> Host: blog.corporationwiki.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Cache-Control: max-age=3600, must-revalidate
< Content-Type: text/html; charset=UTF-8
< Last-Modified: Thu, 12 Jan 2012 20:07:56 GMT
< Vary: Accept-Encoding, User-Agent< Server: Microsoft-IIS/7.5
< X-Powered-By: PHP/5.2.17
< WP-Super-Cache: Served supercache file from PHP
< X-Powered-By: ASP.NET< Accept-Ranges: bytes
< Connection: Keep-Alive
< Date: Thu, 12 Jan 2014 21:07:01 GMT <<<—–
< Age: 289 <<<< ——
< Content-Length: 37089
Vary Header
In the above example, Vary header has the following information:
Vary: Accept-Encoding, User-Agent
This tells the cache that the cached object is specific to the “User-Agent”. If you open up a browser (say, FF) and access the URL with HTTP objects that can be cached, it will be cached by the F5 LTM. If you access the same URL, from the same User-Agent (FF), you will be served with the cached HTTP objects.
On the other hand, if you open up a browser (say, FF) and access the URL with HTTP objects that can be cached, it will be cached by the F5 LTM. Now, if you access the same URL but from a different User-Agent (say, IE), the cached object will NOT be served. The cached objects are specific to FF (User-Agent) and there is no cache object for IE, for the specific URL requested and the request will be directed to the server. Basically, the content cached by F5 is unique to each User-Agent because of the Vary Header.
NOTE: F5 LTM honors only Accept-Encoding & User-Agent as Vary Header values. Any other value will be ignored.
This is a good blog to understand Vary Header and Caching