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.
Figure 33 illustrates the static caching feature.
Before content is cached | After content has been cached |
---|---|
|
|
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:
In addition, content is not cached if the user-configured RAM cache thresholds described below are exceeded.
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.
Before you begin:
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.
Settings | Guidelines |
---|---|
Name |
Configuration name. Valid characters are 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. |