Using caching features

The system RAM cache can store HTTP content and serve subsequent HTTP requests for that content without forwarding the requests to the backend servers, thereby reducing the load on the backend servers.

You can configure basic static caching or dynamic caching rules.

Static caching

Static caching feature illustrates the static caching feature.

Before content is cached	After content has been cached
FortiADC receives the request from Client A and checks to see if it has a cached copy of the content. If it does not, it forwards the request to a backend server. The server sends content in response, and FortiADC caches the content. FortiADC sends it to the client.	FortiADC receives the request from Client B and checks to see if it has a cached copy of the content. It does, so it responds by sending the content to the client. The backend server is not contacted.

In general, the RAM cache conforms with the cache requirements described in sections 13 and 14 in RFC 2616.

If caching is enabled for the profile that is applied to traffic processing, the system evaluates HTTP responses to determine whether or not to cache the content. HTTP responses with status codes 200, 203, 300, 301, 400 can be cached.

The following content is not cached:

• A response for a request that uses any method other than GET.
• A response for a request of which URI is contained in URI Exclude List or Dynamic Request URI Invalid list.
• A response for a request that contains any of the following headers: If-Match, If-Unmodified-Since, Authorization, Proxy-Authorization.
• A response that contains any of the following headers: Pragma, Vary, Set-Cookie, and Set-Cookie2.
• A response that does not include the Content-Length header. The Content-Length header must be 0.
• A response that does not contain the following headers: Cache-Control, Expires.
• A response with a Cache-Control header that does not have any of the following values: public, max-age, s-maxage.
• A response with a Cache-Control header that has one of the following values: no-cache, no-store, private.

In addition, content is not cached if the user-configured RAM cache thresholds described below are exceeded.

Dynamic caching

Dynamic caching is subject to rules you configure. In the Dynamic Caching Rules List, content that matches "caching invalid" URIs is never cached; otherwise, content that matches the Dynamic Cache Rule List of URIs is cached for the period you specify.

Dynamic caching is useful for dynamic web app experiences, such as online stores. For example, suppose a site uses a shopping cart. The URL to list items in the shopping cart is as follows:

http://customshop.com/cart/list

The URLs to add or delete items in the cart is as follows:

http://customshop.com/cart/add

http://customshop.com/cart/delete

In this case, you never want to cache the added or deleted pages because the old content will be "invalidated" by the changes you make. You may want, however, to cache the list page, but only for the period of time that you specify. The dynamic "invalid" rules makes it possible for you to never cache added and deleted pages, whereas the Dynamic Cache Rule List allows you to cache the list page for a specified period of time.

Another case where dynamic caching is useful is when content on a page is dynamic. For example, suppose an online ticket vendor has the following URL that shows how many tickets remain available for an event: http://customshop.com/tickets/get_remains. The number of tickets available is updated by a backend database. In this case, you might want to invalidate caching the URL or give it a small age out time.

Configuring caching rules

Before you begin:

• You must have a good understanding of caching and knowledge about the size of content objects clients access on the backend servers.
• You must have deep and detailed knowledge of your website URIs if you want to create dynamic caching rules.
• You must have Read-Write permission for Load Balance settings.

Caching is not enabled by default. After you have configured caching, you can select it in the profile configuration. To enable caching, select the profile when you configure the virtual server.

To configure caching:

1. Click Server Load Balance > Application Optimization.
2. Click the Caching tab.
3. Click Create New to display the Caching configuration editor.
4. Complete the configuration as described in Caching configuration.
5. Save the configuration.

Caching configuration

Settings	Guidelines
Name	Configuration name. Valid characters are A-Z, a-z, 0-9, _, and -. No spaces. You reference this name in the profile configuration. Note: After you initially save the configuration, you cannot edit the name.
Maximum Object Size	The default is 1 MB. The valid range is 1 byte to 10 MB.
Maximum Cache Size	The default is 100 MB. The valid range is 1 byte to 500 MB.
Maximum Entries	The default is 10,000. The valid range is 1 to 262,144.
Maximum Age	The default is 43,200 seconds. The valid range is 60 to 86,400. The backend real server response header also includes a maximum age value. The FortiADC system enforces whichever value is smaller.
URI Exclude List
URI	Specify URIs to build the list. You can use regular expressions. This list has precedence over the Dynamic Cache Rule List. In other words, if a URI matches this list, it is ineligible for caching, even if it also matches the Dynamic Cache Rule list.
Dynamic Cache Rule List
ID	Enter a unique ID. Valid values range from 1 to 1023.
Age	Timeout for the dynamic cache entry. The default is 60 seconds. The valid range is 1-86,400. This age applies instead of any age value in the backend server response header.
URI	Pattern to match the URIs that have content you want cached and served by FortiADC. Be careful with matching patterns and the order rules in the list. Rules are consulted from lowest rule ID to highest. The first rule that matches is applied.
Invalid URI	Pattern to match URIs that trigger cache invalidation. Be careful with matching patterns and the order rules in the list. Rules are consulted from lowest rule ID to highest. The first rule that matches is applied. This list has precence over the Dynamic Cache URI list. In other words, if a URI matches this list, it is ineligible for caching, even if it also matches the Dynamic Cache URI list.