The WebAccelerator system is designed to increase the performance of web applications (such as Microsoft® Sharepoint, Microsoft® Outlook Web Access, Plumtree®, SAP® Portal, Siebel™, Oracle® Portal, and others). The WebAccelerator system does this by modifying the web browser's behavior and interaction with the web application, as well as by compressing and caching dynamic and static content to reduce traffic to the web application servers.
The following figure illustrates the basic configuration for the WebAccelerator system.
The WebAccelerator system benefits include:
Most sites are built on a collection of web servers, application servers, and database servers that we refer to collectively as origin servers. Origin servers can serve all possible permutations of the content offered by your site, while the WebAccelerator system only stores and serves page content combinations that were previously requested by clients visiting your site. By serving the bulk of common requests, the WebAccelerator system significantly reduces the load on the origin servers, which improves performance for your site.
Once installed, the WebAccelerator system receives all requests destined for the origin server. The first time a client makes a request for a specific page, the WebAccelerator system relays the request to the origin server, and attempts to cache the response that it receives, before forwarding the response to the client. The next time a client requests the same page, the WebAccelerator system serves the response from its cache, instead of sending the request to the origin servers.
This means that for each HTTP request it receives, the WebAccelerator system performs one of the following actions:
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:
For each matching rule in an acceleration policy, there are corresponding caching rules. The matching and caching rules are organized in a tree structure called the Request Type Hierarchy 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 node in the Request Type Hierarchy tree. Once matched to a node, the WebAccelerator system applies the associated caching rules to each group.
The caching and matching rules for acceleration policies can be unique to a specific application. 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 the applications at your site.
Some applications have specific types of HTTP requests that require special handling. For example:
For unique sites with specific requirements, you can copy and customize a pre-defined acceleration policy and modify specific matching and caching rule settings to create your own user-defined acceleration policy. For information about creating user-defined acceleration policies, see Creating user-defined acceleration policies , located in Chapter 3.
Matching rules are based on specific parameters for:
When configuring matching rules, you define the HTTP data types that the WebAccelerator system should look for in an HTTP request in order to group requests and responses. Once the WebAccelerator system groups requests and responses, it applies the associated caching rules that you defined.
The WebAccelerator system performs application matching only against leaf nodes in the Request Type Hierarchy tree. The WebAccelerator system cannot match requests and responses to a node in the Request Type Hierarchy tree. The primary purpose of a node is inheritance, and each leaf node for matching rules corresponds with specific caching rules.
For additional information about the Request Type Hierarchy tree, see Understanding the Request Type Hierarchy tree .
You can base matching rules on the following HTTP request data types:
You use these HTTP request data types as parameters to define matching and caching rules.
For more information about how to use HTTP request data types, see Chapter 5 .
There are two HTTP response data types on which you can base matching rules.
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. A response 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.
For responses, the WebAccelerator system bases classification on the first information present, in the following order:
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.
For more information about HTTP response data types, see Chapter 5 .
After the WebAccelerator system matches an HTTP request to a matching rule, it applies the associated caching rules, which dictate how the WebAccelerator system manages the request. The WebAccelerator system applies the caching rules to the request, based on the following criteria:
Each caching rule is associated with a matching rule, represented by a leaf node on the Request Type Hierarchy tree. Once the WebAccelerator system finds the matching leaf node, it applies the caching rules from the associated caching rule's leaf node. Just like the matching rules node, the caching rules node can inherit rules from its ancestors.
Some of the caching rules pertain to how the WebAccelerator system handles a request, and some pertain to how the WebAccelerator system handles the response. The caching rules are defined as follows:
All of the acceleration policies defined for the WebAccelerator system are located in a tree structure called the Request Type Hierarchy tree, which you can access from the Policy Editor screen. To view specific matching and caching rules for acceleration policies, you click a node on the Request Type Hierarchy tree. Once you select a node, you can click the various rules on the menu bar to view the specific settings for each rule.
The tree structure of the Request Type Hierarchy tree enables parent-child relationships. You can make changes to rule settings at the node (parent) level and propagate them to the associated leaf nodes (children). In other words, the matching and caching rules that are associated with a leaf node inherit rules from the acceleration policies of its parent nodes. Parent (or ancestor) nodes exist only for rule inheritance. The WebAccelerator system can match a request or response only to a leaf node in the hierarchy.
A simple site might expect only two types of requests:
For this site, you would create a Request Type Hierarchy tree with the following two leaf nodes, and relevant matching rules.
This Request Type Hierarchy tree example appears as follows.
This acceleration policy matches requests to the Applications leaf node. However, if a request matches to the Applications leaf node because its path is for the CGI-based application, but the response that comes back is a GIF image, the response is matched to the Images leaf node.
For more specific information about the Request Type Hierarchy tree, see Chapter 4Introducing the Request Type Hierarchy Tree .