Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 2 - Overview of the WebAccelerator System
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


2

Overview of the WebAccelerator System


Introducing the WebAccelerator system

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.

 

 

Figure 2.1 Basic WebAccelerator system configuration

The WebAccelerator system benefits include:

  • Browser behavior control
    Without requiring changes to the browser, the WebAccelerator system ensures that users do not download duplicate content.
  • Content acceleration
    The WebAccelerator system provides content acceleration by:
    • Opening additional simultaneous browser connections
    • Rapidly displaying PDF documents
    • Accelerating dynamic content
    • Using software compression for web applications
    • Using dynamic and static caching for web applications
  • Reports and logs
    The WebAccelerator system provides:
    • Comprehensive graphs
    • Alerting capability
    • Unified logging for web application hits

Servicing HTTP traffic

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:

  • Services the request from its cache
    Upon receiving a request from a browser or web client, the WebAccelerator system initially checks to see if it can service the request from compiled responses in its cache.
  • Sends the request to the origin servers
    If the WebAccelerator system is unable to service the request from its cache, it sends a request to the origin server. Once it receives a response from the origin server, the WebAccelerator system caches that response according to the acceleration policy rules, and then forwards the request to the client.
  • Redirects the request to the origin servers
    The WebAccelerator system redirects requests for some pre-defined types of content, such as requests for streaming video.
  • Creates a tunnel to send the request to the origin servers
    You can use tunneling for encrypted traffic (HTTPS) content that you do not want processed by the WebAccelerator system. Note that the WebAccelerator system can cache and respond to SSL traffic without using tunnels.

Understanding acceleration policies

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
    Used to group requests and responses to a specific node in the Request Type Hierarchy tree.
  • Caching rules
    Used to manage HTTP requests and responses.

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.

Using pre-defined or user-defined acceleration policies

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:

  • 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 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.

Understanding matching rules

Matching rules are based on specific parameters for:

  • HTTP request data types
  • HTTP response data types

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 .

Defining HTTP request data type parameters for matching rules

You can base matching rules on the following HTTP request data types:

  • Protocol
  • Host
  • Path
  • Extension
  • Method
  • Query Parameter
  • Unnamed Query Parameter
  • Path Segment
  • Cookie
  • User Agent
  • Referrer
  • Header
  • Client IP

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 .

Defining HTTP response data type parameters for matching rules

There are two HTTP response data types on which you can base matching rules.

  • Content-Disposition
  • Content-Type

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:

  • 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).
  • The extension of the path in the request.

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 .

Understanding caching rules

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:

  • Whether the request is for content that the WebAccelerator system can cache
  • Whether the request is for content that the WebAccelerator system has already cached
  • Whether the content that the WebAccelerator system has cached is fresh enough to service the request
  • Requirements for how the WebAccelerator system should compile responses from the content it receives from the origin server
  • Requirements for how the WebAccelerator system should reassemble compiled responses into the appropriate web page to service the request

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:

  • 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 .
  • Assembly
    Specifies how the WebAccelerator system assembles a compiled response. Assembly rules include options for compression, Express Loader, Express Connect, response rewriting, and assembly. The WebAccelerator system applies assembly rules to requests. For more information, see Chapter 8 .
  • Proxying
    Prompts the WebAccelerator system to always forward the request to the origin servers. The WebAccelerator system applies some elements of proxying rules to requests, and some elements to responses. For more information, see Chapter 9 .
  • 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 .
  • Lifetime
    Specifies, with minimum and maximum age variables, how long content should remain in the WebAccelerator system's cache before a refresh is required. The WebAccelerator system applies lifetime rules to responses. For more information, see Chapter 10 .
  • Invalidations
    Specifies the conditions under which the WebAccelerator system automatically invalidates cached content.You can manually invalidate content or set invalidation triggers. When content expires, the WebAccelerator system sends the next request it receives for the same content, to the origin server for fresh content. The WebAccelerator system applies invalidation rules to requests. For more information, see Chapter 11 .

Understanding the Request Type Hierarchy tree

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.

Request Type Hierarchy tree example

A simple site might expect only two types of requests:

  • Requests for GIF images
  • Requests for a CGI-based application

For this site, you would create a Request Type Hierarchy tree with the following two leaf nodes, and relevant matching rules.

  • A leaf node called Images
    With an associated matching rule that identifies a match in a request if the file extension is .gif.
  • A leaf node called Applications
    With associated matching rules that identify a match for CGI-based application as follows.
    • A rule based on the path that appears in the requesting URL.
    • A rule based on the request and response not matching an image content type.

This Request Type Hierarchy tree example appears as follows.

 

Figure 2.2 Request Type Hierarchy tree example

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 .




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

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)