Objective 1.03 of the 301a exam requires the candidate to have an understanding of functions that can be offloaded from a server by the LTM. One of these functions is caching.

Caching

A web cache is a HTTP device that allows you to keep (relatively) local copies of documents and files ready for quick retrieval from clients. This saves the origin (web) server from having to hand out the same data constantly for what could be thousands of requests. There may be an event, breaking news or some announcement, that causes a flurry of excitement and the surge of internet traffic that ensues. There are other factors too which play a part in user experience such as delays caused by bottlenecks and distance induced latency. Caching can help to alleviate some of the stresses on networks caused by the above.

HTTP/1.1 caching is described in RFC 7234.

Freshness 

A cache device must check that the data it has cached is up to date or "fresh". HTTP has some nice features which allow caches to ensure data is consistent with that on the origin servers.

When it's time to check the origin server so it can update its cached data, a cache uses a concept called HTTP revalidation. An origin server can attach an expiration date to the response header using either the Cache-Control: max-age or Expires header, although the Cache-Control: max-age header actually supersedes the Expires header.

When it receives a request from a client for a cached object and the Cache-Control: max-age or Expires period has expired the cache server will send a HTTP revalidation request to the origin server using a conditional GET request. It's "conditional" because the origin server only needs to send back data if it is different from the cached copy, otherwise it just responds back with a 304 Not Modified response.


A conditional GET makes use of conditional headers which generally begin with 'If-'. The most common are the If-Modified-Since and If-None-Match headers. The If-Modified-Since header is used with the Last-Modified header that the origin server sends back. If the content has been modified since the Last-Modified date then the origin server will send back the full content. Otherwise a 304 Not Modified will be returned.

The If-None-Match header is used with entity tags or ETags. These tags are basically another way to inform the cache of the validity of the data. They are a little more sophisticated (employing checksums, for example) but generally serve the same function.

Hits & Misses

It's worth quickly going over what is meant by a 'hit' and 'miss' in the context of caching as we'll see this on the BIG-IP later on.

It's actually quite simple. A cache hit is where the data requested by the client is found in the cache server. A miss is where the data is not found on the cache and it must then request the content from the origin server. It's unlikely a cache will ever reach a 100% hit rate.

F5 Web Acceleration

F5 implements caching using the Web Acceleration profile which is attached to a virtual server under the Acceleration section. Like most LTM profiles, you are able to tweak a number of settings but in the same breath you can also say you don't need to tweak anything at all.

The BIG-IP system does not cache everything. Here is a list of content it can cache:

• 200, 203, 300, 301, and 410 HTTP responses
• Responses to HTTP GET requests
• Other HTTP methods for URIs specified for inclusion in cached content, or specified in an iRule
• Content based on the User-Agent and Accept-Encoding values. The cache feature holds different content for Vary headers.

Here's what it cannot cache:

• Data specified by the following Cache-Control headers: private, no-store, no-cache
• Action-oriented HTTP methods such as HEAD, PUT, DELETE, TRACE, and CONNECT

System Checks

Caching uses up memory on a BIG-IP system so it's best to be mindful when deploying this feature. You can for example consolidate a single Web Acceleration profile for multiple virtual servers. if your policy allows. First you want to check how much memory you have allocated to the TMOS system:

# show sys provision
---------------------------------------------------------
Sys::Provision
Module  CPU (%)  Memory (MB)  Host-Memory (MB)  Disk (MB)
---------------------------------------------------------
...
tmos         88         1582               140          0


Next check what percentage of RAM Cache memory is available to use for caching:

# list sys db ramcache.maxmemorypercent
sys db ramcache.maxmemorypercent {
    value "50"
}

What the above tells you is that for every TMM instance on your system you are able to use up to 1582 / Number of TMM instances / 2. In my case I have two TMM instances so that gives me 392Mb of RAM for caching. However, it's generally best to leave the cache size to its default of 100Mb unless you really need more.

Profile Settings

There are a few settings under the profile:

• Maximum Entries: quite simple really, how many entries you can have in the cache.
• Maximum Age: the time before a cached object becomes 'stale' and require revalidation.
• Minimum Object Size: if an object is smaller than this it won't be cached.
• Maximum Object Size: if an object is bigger than this it won't be cached.
• URI Caching: here is where you can get granular with what URIs you actually want to cache (or not cache).
• Ignore Headers: basically tells the BIG-IP system how to handle cache-control requests from browsers.
• Insert Age Header: specifies whether the LTM adds the Age and Date headers
• Aging Rate: specifies how aggressive the system is in aging out cached entries when space is needed for new objects

Testing 

The setup for this lab is as follows:




It works something like this...

1. The client makes a new request to the LTM virtual server on .230. The LTM being a full proxy device completes the TCP 3-way handshake and receives the first HTTP request from the client before initiating a connection to the backend web server. Here we are using SNAT so it sources the connection from .109.




2. The web server responds with a 200 OK for each request and includes the Last-Modified and ETag headers. My Apache 2 web server has not been configured to send expiry information.



3. The LTM now caches the responses based on the URI List configuration in the profile. As we have left this to the default .* it will attempt to cache everything. If we look at the LTM Ram Cache we can see the entries that have been cached. Here is one example:

#show ltm profile ramcache all
Host: 10.128.3.230
  Size (bytes)     33719

Note that the following fields:

• Owner Slot: The TMM instance that processed this cache entry
• Received: the time the LTM received the content from the origin server
• Last Sent: the time the LTM last queried the origin server for this content
• Expires: the cached time we have configured in the profile (180 seconds).

4. A different user (or the same user) makes a subsequent request for the same resource within the 3 minutes period. The LTM now serves the content from its RAM Cache and includes the Age and Date headers. The Age header value is 69 seconds which is the time since the LTM first received the content from the origin server.



#show ltm profile ramcache all
Host: 10.128.3.230
  Size (bytes)     33719

5. 3 minutes have now passed with no client requesting the same resources. The content is now considered 'stale' by the LTM and requires a 'freshness' update, or revalidation. The LTM now passes each request to the origin server as a conditional GET and includes the If-Modified-Since header.


 If the data has not been modified the origin server responds with a 304 Not Modified.



6. The LTM passes the content to the client and includes the Age & Date header but now with a value of 0. The reason is because the LTM has only just received the content (or rather the update) from the origin server. Therefore the delta between the Received and Last Sent is zero.



#show ltm profile ramcache all
Host: 10.128.3.230
  Size (bytes)     33719
If we attempt another connection that allow the LTM to serve content from its cache we now see hits against the Hits counter.

Summary

I have admittedly left a lot of detail on caching technology out but hopefully this post provides you with some knowledge on how caching is implemented on the LTM system. Thanks for reading.