Caching Policies

AppDirector supports caching of HTTP traffic. Caching improves the overall network performance. Using caching, back-end servers are required to serve less content, which can save on fetching data and creating dynamic HTML pages.

Caching can also decrease the number of required TCP connections to the back-end servers. It allows a more efficient use of compression features, as AppDirector can cache compressed objects, and save the need to re-compress the same object for each client request. Caching is memory based. Once Caching is enabled for one Layer 4 Policy or more, up to 50% of available Acceleration Engine memory is used for cache. The amount of memory used depends on traffic and the cached objects and is configurable from 1 % - 50% (default 20%) in the Tuning Table.

Note: If a Caching policy is defined, by default the action is cache all the content.

Caching and Layer 7 Modification

The objective of caching is acceleration whereas the target of Layer 7 modification is to select the correct content from the correct server. Unfortunately, configuring an URL exception list does not always solve the problem.

Layer 7 modification should take precedence over caching as caching is at the client end of the flow. This means that when a request arrives it is considered for serving from cache before all other application services (for example, HTTP modifications). On the other hand, when a server response reaches an Application Services Engine it undergos compression and HTTP modification before being cached.

Caching Decisions

Caching depends on the following decision making process:

1.	Which object do you want to cache?

2.	Can it be optimized?

3.	Seven Qualifications (see Identifying Optimizable from Non-Optimizable Objects.)

4.	Once an object is encountered, caching acts as defined.

Dynamic Caching

There are several issues to consider when caching. Deciding what content is private (user specific) or public, static or changeable. More than 40% of Web content is not marked with caching directives and yet could be optimized.

Two factors to keep in mind when considering whether to cache dynamic pages include the frequency of Web content changes and the demand level for current content (hit count). Anticipated hit count determines the prioritization of Web pages to be cache. More popular Web pages take precedence over less frequently accessed pages.

AppDirector’s Dynamic Caching helps increase your server performance, improving response times by fetching content from cache rather than from the servers for dynamic as well as static content, and in addition simplifies control of the caching configuration.

This is achieved by:

identifying static objects from dynamic objects

defining optimal caching times

optimizing Dynamic objects caching in browser

avoiding caching users private content

Notes:  

URL exception rules can override dynamic caching decisions, enabling an administrator to control caching even when dynamic caching is selected.

The expiration time defined in the policy is an upper limit for cache aging, even if the object is not actually cached.

Identifying Optimizable from Non-Optimizable Objects

AppDirector identifies whether an object is optimizable by checking a series of criteria as follows:

1.	The Object should not have a cache time specified.

2.	The Object must be one of the following content types:

a.	application/*

b.

image/*

c.	audio/* (?)

d.	video/* (?)

e.	text/: plain, css, richtext, tab-separated-values, "x-*" (x-c, x-fortran, and so on)

3.	The Object name should be persistent over time to rule out an object with dynamic names usually created per-user request for single use -

4.	The Object should not have caching restrictions in its headers (like Private) that contradicts dynamic caching logic. In addition, an object should not have any restriction in AppDirector's caching policy (URL exception rule list) preventing its caching.

5.	Object access should not require authentication - objects that need authentication access are usually unique to the authenticated user.

6.	The Object should have a valid Last-Modified header allowing its content to be traceable and to be checked with a server if it was changed.

7.	The Object does not have a Vary header limiting its validity for caching only in specific cases.

When an object meets all the above criteria, it is marked as eligible for caching optimization.

Defining Optimal Caching Times

When an object is identified as eligible for caching, but with no caching time (according to its max-age or expires headers), AppDirector defines an estimated caching time.

Optimizing Dynamic Objects Caching in Browser (Object Versioning)

AppDirector can optimize the caching of objects by browsers. The algorithm for this action is based on controlling object names in the original HTML the references them. This allows AppDirector to check if objects were modified every time that the HTML was recalled and force the browser to update them when needed.

Avoiding Caching Users Private Content

During caching actions, AppDirector is careful to avoid any caching of user personal data, including:

Not caching any object marked as Cache-Control: private.

Not caching any object that requires Authentication to be accessed.

Stripping objects from set-cookie headers before caching to avoid different users receiving other users session information.

Invalidating Cache Content Changed by Clients

AppDirector allows a cached object to be invalidated following a user action that modifies it. This is performed according to HTTP cache RFC (section 13.10). This defines that any object request with HTTP method POST, PUT or DELETE must cause the object's invalidation. This invalidation occurs only after the server has approved the operation as successful (that is, responds with a 200OK)

This enables caching dynamic content like blog pages, while ensuring that every new posting invalidates the cached version of the page.

Using Leverage Browser Cache Parameter

When cached content is served by AppDirector to a clients browser, the client experiences better Quality of Service (QoS) than if it was served from the server. Further enhancement to client QoS is achieved when the clients Browser caches the content for reusing on the next request that needs it. However, not all content is optimally cached by browsers thus failing to provide the best possible QoS. AppDirector can optimize the browser caching by updating the Cache-Control directives on every cache-served object. The object headers are updated to reflect the future time it can be cached for by the browser according to the AppDirector cache time (whether from server headers or AppDirector Cache URL Exceptions Rule-List). AppDirector also ensures that the content is not served from the browser cache after it is considered stale. AppDirector provides the browser with the time that already exists in the AppDirector Cache, so that the browser can calculate the remaining time correctly.

To configure an AppDirector caching policy

1.	From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy pane displays.

2.	Set the parameters.

 

Parameter	Description
Policy Name (Mandatory)	Name of the Policy. Default: Empty
Dynamic Caching	Helps increase your server performance, improving response times by fetching content from cache rather than from the servers for dynamic as well as static content. Values: Disabled, Enabled Default: Disabled
Minimum Object Size [Bytes]	Minimum size of objects to be stored. Values: 0 – 1048576 bytes (1MB) Default: 1024
Maximum Object Size [Bytes]	Maximum size of objects to be stored. Values: 0 – 20971520 bytes (20MB) Default: 1048576
Expiration [seconds]	Maximum time that an object is kept, even if the object header is specified longer. If the object header or configuration using Cache URL Rule-List is specified less, it is purged according to its header / configuration. Default: 86,400 (24 hours)
Leverage Browser Cache	You can modify caching headers to leverage client side (browser) cache: Values: Enabled, Disabled Default: Enabled For objects marked for caching: Add/modify objects' HTTP headers to include Cache-control: public, max-age=X. X is derived from general cache settings or from the URI rule responsible for caching the specific object.
Respect Server Headers	Specifies how Server Response cache headers are treated. Respect-All (for example, RFC behavior) - If no header is sent by the server specifying the cacheability of the object, AppDirector caches the object. Cache-All - caches everything regardless of headers. In both modes, Cache URI rules override and allow for Exceptions. Values: Respect All, Cache All Default: Respect All Note: If a Caching policy is defined by default, the action is cache all the content.
Respect Client Headers	Specifies how Client request cache headers are treated: Respect-All (that is. RFC behavior) — In this mode must-validate, if-modified, and so on. headers are enforced as "get fresh from Server" and request is forwarded to server. Respect Refresh headers only — Causes only the following headers in client requests to be respected: "max-age=0", "no-cache", "pragma:no-cache". All other content is served from cache if it exists there. Serve All from Cache — Ignores all client side headers serving from cache anything that exists there. Values: Respect All, Respect Refresh headers only, Serve All from Cache Default: Respect All
URL Exceptions Rule List	Disable or select from the list of Cache URL Rule lists. Default: Disable You can define Domain without anything in the URL field to support use-cases of different behavior per domain. However, if Domain is not defined (Domain_type=none) then the URL field is mandatory.
Ignore Query Parameters	Specifies whether query parameters added to object URL should be ignored when saving/serving object from cache. Values: Enabled, Disabled Default: Disabled

3.	Click Set.

4.	In the required Layer 4 policy, select the Cache policy that you configured.

Purging Cache

In some cases you may want to purge cache content of HTTP responses. Enter the caching policy ID to purge the cache for a particular caching policy, or ALL to purge the cache for all caching policies, or the object's URL to purge only specific objects from a specific policy or from all policies

To purge cache

1.	From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy pane displays.

2.	Select any Layer 4 policy or All, and optionally add a specific object's URL.

3.	Click Set. The cache is purged.

Cache Content Invalidation

AppDirector lets you remove objects from cache by specific object URL or URL with wildcard in it (*). HTTP Cache RFC2616 requires that HTTP requests of certain methods invalidates cache content related to these requests.

An HTTP request using methods POST, PUT or DELETE causes invalidation of the requested object in the cache. The invalidation can be performed for a specific URL match of the object, that is, full match of baseURL only when ignore query parameters is enabled, or of BaseURL+parameters when ignore query parameters is disabled.

When the URL ends with an asterisk (*) it is interpreted as a wildcard, and causes the entire objects "tree" under the specified URL to be invalidated.

The wildcard is interpreted in a wide sense; meaning anything that displays in URL after that point is invalidated including multiple page instances differentiated by parameters indicated with them.

If the URL includes a page name and/or page suffix and then an asterisk, only various instances of the specific page with different parameters (specified after the question mark sign) is invalidated.

Note: The same functions can be also performed from AppDirector's WBM interface.

To remove objects from cache by specific object URL or URL with wildcard (*) in it

1.	From the AppDirector menu, select Layer 4 Traffic Redirection > Caching Policies. The AppDirector Caching Policy pane displays.

2.	Select any Layer 4 policy or All.

3.	Enter the Object URL or URL with wildcard in it (*). Using this method means that the wildcard can appear in the middle of the URL as well, to replace any characters.

4.	Click Set. The objects are removed from cache.