Chapter 7 Reverse Proxy Cache

7.1 Overview

This chapter will cover the concepts and strategies of using the Reverse Proxy Cache to better enhance the overall speed and performance of your Web servers. Using the cache function will improve website performance and throughput, and will also reduce server load by caching heavily requested data in the temporary memory of the FortiBalancer appliance.

7.1 Understanding Reverse Proxy Cache

7.1.1 How Reverse Proxy Cache Works

The Reverse Proxy Cache is located right in front of Web servers. It receives the requests from clients all over the Internet and responds to these requests by working with the Web servers.

 

Figure 7-1 Reverse Proxy Cache Working Mechanism

1. The client sends a request to the FortiBalancer appliance, requesting for a file on the Web server. The FortiBalancer appliance will forward the request to the cache module for processing.
2. If the requested content has been cached on the FortiBalancer appliance and the cache does not expire (cache hit), the FortiBalancer appliance will send the file copy to the client directly without forwarding the request to the Web server. If the requested content does not exist in cache (cache miss), the request will be forwarded to the Web server for processing.
3. The Web server responds to the FortiBalancer appliance with the requested content.
4. The FortiBalancer appliance responds to the client with the requested content, and caches the content. Future requests for the same content will be responded directly from the FortiBalancer appliance cache module.

The default behavior of the cache is to send the cached object to the client while the cache is being filled with new objects.

The maximum size of the cache objects depends on different system memories of the FortiBalancer appliances. See the table below:

Table 7-1 Max Size of Cache Object

System Memory	Max Size of Cache Object
4GB	10240KB (10MB)
8GB	20480KB (20MB)
16GB	40960KB (40MB)

 

7.1.2 Advantages of Reverse Proxy Cache

Compared with traditional cache functions, the Reverse Proxy Cache, without making any compromise on the overall stability and performance, provides a smarter, high-efficient and personalized configuration platform for administrators to more flexibly adjust the FortiBalancer appliances to addressing the demands of different websites. This helps administrators improves the response ability of the websites, reduces the load of Web servers and delivers perfect user experience of visiting the websites.

The Reverse Proxy Cache function is mainly featured with the following advantages: Ø Improved performance

• The cache function is an independent module in the OS. Turning it off will not impact the functionality of other modules in the system.
• The cache module strictly controls its memory consumption under 25% of the total system memory.
• The ability to cache both the compressed and uncompressed contents allows the

FortiBalancer to send compressed contents to appropriate clients without having to involve the compression engine. This greatly enhances compression throughput.

Ø    Outstanding stability

• If any error occurs to the cache module, administrators can turn off the module immediately, which will not affect the running of other system functions.
• All cache tuning parameters now use the “cache filter” mechanism, and the global control parameters are reduced. This new approach gives administrators more flexibility and control and minimizes confusion during configuration.

Ø    Intelligent monitoring

Ÿ     The FortiBalancer process monitor also monitors the cache (in addition to the reverse proxy). If it detects any issues (or if the cache process crashes), it will restart the cache after appropriate cleanup.

Ø    Flexible configuration

• Since the cache is a separate process, it can be updated in place using the “component update” mechanism.
• The statistics from “show statistics cache” are more detailed and are designed to allow administrators to get data that would help them understand how the FortiBalancer is making caching decisions. This should help the customer tune the FortiBalancer or their website to optimize performance.
• The “cache filter” mechanism reduces global control parameters, which increases the precision and flexibility of command control by administrators.
• The cache can now be switched on/off on a per-virtual site basis.

7.1.3 Cacheability of Contents

The HTTP traffic falls into two categories: cacheable contents and non-cacheable contents. The cacheability of contents depends on the information within the HTTP headers. The reverse-proxy cache will check the request and response HTTP headers to make cache decisions. If the response for a request is cached, the subsequent request for the same object will be served from the cache instead of from a backend server.

By default, if there are no HTTP headers that restrict caching for an object, the reverse-proxy cache will cache the content. The following are the more popular cache-control headers that will control if the content will be cached and if so, for how long.

Cache-Control: public

The public keyword indicates that any available and configured cache may store the content. Cache-Control: private

This directive is intended for a single user and will not be cached by the reverse-proxy cache.

Cache-Control: no-cache

This directive lets the reverse-proxy cache know that it can cache the content and can only use the cached content if the appliance first re-validates the content with the origin server.

Expires: Tue, 30 Oct 2010 14:00:00 GMT

This header tells the cache when the content will expire and when to re-fetch it from an origin server when the request for that object is made. In this example it tells the cache to make the content expire on Tuesday, 30 Oct 2010 14:00:00 GMT.

7.1.3.1 Cacheable Contents

Any content with Cache-Control directives which allow caching of the content will always be cached. If the content does not contain a Cache-Control directive, then it will always be cached and will not be re-validated until it is manually flushed from the cache. If the content does not contain an “Expires” header, after it expires, the FortiBalancer appliance will re-validate the content with the origin server and update the content when it is requested next time.

7.1.3.2 Non-Cacheable Contents

Content that has Cache-Control headers which restrict caching of the content will not be cached. Responses to requests with cookies are not served from cache, unless configured by the user to do so.

7.1.4 Cache Filter

The Cache Filter mechanism helps administrators realize more precise control over the cache module with simple cache configurations, such as whether to cache the contents requested by a specific host or not and how long the cached content will live. The priority of the control parameters in cache filter is higher than the peer parameters defined in the Cache-Control header.

The following gives several application examples of cache filter. For detailed configuration examples, refer to the section Reverse Proxy Cache Configuration and the FortiBalancer CLI Reference.

• Cache all “*.jpg” files from the host “www.xyz.com”, and the TTL of cache contents is 200,000 seconds.
• Only cache the image files in common formats, such as JPG, GIF or BMP.
• For the cache objects from the same host, some can be cached by following the cache filter rules, and others can be cached by following the definitions in the cache control header, such as the TTL of the cache.
• Ignore the specific type of query strings in the request URL when looking up for an object in cache.

7.1.5 Cache Expiration Time

Three types of cache expiration time are involved during the cache process:

• The expiration time defined by the “Expires” field in the HTTP header;
• The global cache expiration time configured via the command “cache settings expire {hh:mm:ss|seconds}”;
• The TTL time specified by the “ttl” parameter in the command “cache filter rule <host_name> <url> {cache|urlquery|ttl}”.

The priorities of the three expiration times are as follows:

1. The expiration time configured in “cache filter rule” will be used first.
2. If the “ttl” parameter is not specified, the global expiration time specified by “cache settings expire” command will apply.
3. For the cache content that does not match any cache filter rule, the expiration time defined in the HTTP header will be applied.
4. If no “Expires” field is available in the HTTP header to define the expiration time, just follow the configuration of “cache settings expire”.