Applies To:

Show Versions Show Versions

Manual Chapter: Overview of Acceleration Policies
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

An acceleration policy is a collection of rules that specify how the WebAccelerator system caches, assembles, and responds to HTTP requests. There are two main parts to an acceleration policy:
Matching rules
The WebAccelerator system uses matching rules to group requests and responses to a specific leaf node in the Policy Tree.
Acceleration rules
The WebAccelerator system uses acceleration rules to manage HTTP requests and responses.
For each matching rule in an acceleration policy, there are corresponding acceleration rules. The matching and acceleration rules are organized in a tree structure called the Policy Tree. The process of mapping requests to acceleration policies is called application matching. To perform application matching, the WebAccelerator system analyzes the requested host to match the request to an acceleration policy. Once matched to an acceleration policy, the WebAccelerator system analyzes the information in the HTTP request and uses the matching rules to group requests and responses to a specific leaf node in the Policy Tree. Once matched to a leaf node, the WebAccelerator system applies the associated acceleration rules to each group.
The WebAccelerator system comes with several pre-defined acceleration policies. In most cases, you can use these pre-defined acceleration policies to manage HTTP requests for your sites applications.
You can assign different acceleration policies to applications, depending on the type of matching and acceleration rules you want to apply. Some applications have certain types of HTTP requests that require special handling. For example:
An auction site needs an invalidation rule that prompts the WebAccelerator system to invalidate cached content for an item whenever a new bid request comes in.
A site with rotating advertisements needs a variation rule that changes the advertisements that appear on a page each time the WebAccelerator system assembles a response.
For unique sites with specific requirements, you can copy and customize a pre-defined acceleration policy and modify specific matching and acceleration rule settings to create your own user-defined acceleration policy. For information about creating user-defined acceleration policies, see Creating user-defined acceleration policies.
Matching rules are based on specific parameters for HTTP data types and HTTP response header data types. The WebAccelerator system uses matching rules to look for identified objects in an HTTP request or response, such as path, file extension, cookie, or query parameter, in order to group the requests and responses. Once grouped, the WebAccelerator system applies the associated acceleration rules to the request and responses.
When configuring matching rules, you define the HTTP data types that the WebAccelerator system should look for in an HTTP request to group the requests and responses. Once the WebAccelerator system groups requests and responses, it applies the associated acceleration rules that you defined.
Acceleration rules dictate how the WebAccelerator system manages requests and responses. Each acceleration rule is associated with a matching rule, represented by a leaf node on the Policy Tree. Once the WebAccelerator system finds the matching leaf node, it applies the leaf nodes associated acceleration rules.
Requirements for how the WebAccelerator system should compile responses from the content it receives from the origin web server
Requirements for how the WebAccelerator system should reassemble compiled responses into the appropriate web page to service the request
Some of the acceleration rules pertain to how the WebAccelerator system handles a request, and some pertain to how the WebAccelerator system handles the response. The acceleration rules are defined as follows.
Variation
Identifies specific elements in an HTTP request that affect the content contained in the web page, and specifies whether the WebAccelerator system should use those elements in the UCI to identify cached content. Variation rules are associated with content that is specific to requests. For example, variation rules can specify content that the WebAccelerator system should serve based on a certain cookie. For more information, see Chapter 7, Configuring Variation Rules.
Assembly
Specifies how the WebAccelerator system assembles a compiled response for a request. Assembly rules include options for Intelligent Browser Referencing, MultiConnect, Content Assembly on Proxies, and parameter substitution. The WebAccelerator system applies assembly rules to requests. For more information, see Chapter 8, Configuring Assembly Rules.
Proxying
Identifies specific elements in an HTTP request that prompt the WebAccelerator system to forward the request to the origin web servers. The WebAccelerator system applies some elements of proxying rules to requests, and some elements to responses. For more information, see Chapter 9, Configuring Proxying Rules.
Lifetime
Specifies, with minimum and maximum age variables, how long content should remain in the WebAccelerator systems cache before the WebAccelerator system sends the request to the origin server for fresh content. The WebAccelerator system applies lifetime rules to responses. For more information, see Chapter 10, Configuring Lifetime Rules.
Invalidations
Identifies specific elements in an HTTP request that prompt the WebAccelerator system to refresh the specific cached content. For more information, see Chapter 11, Configuring Invalidations Rules.
Connections
Specifies the type of connection that the WebAccelerator system should use to communicate with the destination host for the specified application, and identifies specific elements in an HTTP request that prompt the WebAccelerator system to use a specified connection pool. For more information, see Chapter 12, Configuring Connections Rules.
Responses Cached
Specifies the content that the WebAccelerator system should cache, based on the HTTP response code that arrived with the content. The WebAccelerator system applies responses cached rules to responses. For more information, see Chapter 13, Configuring Responses Cached Rules.
In addition to these HTTP data type parameters, you can also base matching rules on the following HTTP response header data types.
Unlike HTTP request data types, you do not base a matching rule directly on the value of an HTTP response data type. Instead, the WebAccelerator system uses these values to classify a request or response and generate a object type. You base the matching rule on the object type.
For requests, the classification is based on the file extension present in the request. For example, a matching rule might specify that the WebAccelerator system place all requests with a .gif extension into a group for images. An assembly rule might specify that the WebAccelerator system use a value for a query parameter contained in a request, as a substitute for a value in the cached response, before it assembles the page.
The file extension from the file name field in the Content-Disposition header in the response.
The file extension from the extension field in the Content-Disposition header in the response.
The Content-Type header in the response (unless it is an ambiguous MIME type).
Once the WebAccelerator system classifies a request or response by object type, it generates a content type for it by appending the object type to the group to which the object type belongs.
You can then define a matching rule based on the object type, for example the Content-Type header, by specifying the regular expression you to match, or not to match, for the content type in a request or response.
The WebAccelerator systems acceleration policies are located in a tree structure called the Policy Tree, which you access from the Policy Editor screen. The Policy Tree consists of root nodes, leaf nodes, and branch nodes.
The WebAccelerator system performs application matching only against leaf nodes in the Policy Tree and then applies the leaf nodes corresponding acceleration rules to the request. In contrast, the primary purpose of a root node and a branch node is to easily propagate rules to leaf nodes. The WebAccelerator system cannot match requests and responses to a root node or a branch node in the Policy Tree.
The structure of the Policy Tree supports this parent-child relationship so that you can make changes to rule settings at the root or branch (parent) node and propagate them to the associated leaf (child) nodes. Typically there is only one root note assigned to the Policy Tree. What distinguishes a root node from a branch node, is that a root node has no parent node.
To view specific matching and acceleration rules, you click a leaf node on the Policy Tree. Once you select a leaf node, you can click the matching and acceleration rules on the menu bar to view specific rule parameters for each node.
In this section, we describe how to configure an example Policy Tree for a site. For this site example, you expect only two types of requests:
This example acceleration policy would consist of a Policy Tree with the following two leaf nodes, configured with the specified matching rules.
A leaf node called Images
The Images leaf node has an associated matching rule that identifies a match in a request, if the file extension is .gif.
A leaf node called Applications
The Application leaf node has two associated matching rules that identify a match for a CGI-based application as follows:
For this acceleration policy, the configured rules prompt the WebAccelerator system to match requests to the Applications leaf node. Since the WebAccelerator system matches requests and responses, if the WebAccelerator matches a request to the Applications leaf node because its path is for the CGI-based application, but the response that comes back is a GIF image, it matches the response to the Images leaf node.

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)