An acceleration policy is a collection of rules that determine how the WebAccelerator system caches, assembles, and responds to HTTP requests. The WebAccelerator system ships with several pre-defined acceleration policies. You can also create user-defined acceleration policies, if required. See also caching rules and matching rules.
An application profile provides the key information that the WebAccelerator system needs to appropriately handle requests to the applications on your site. An application profile consists of a host map and a specified acceleration policy.
Application matching is the process of mapping HTTP requests and responses to associated acceleration policies. To perform application matching, the WebAccelerator system analyzes information in an HTTP request, and uses the matching rules to group requests and responses. Once matched to an acceleration policy, the WebAccelerator system applies the associated caching rules to each group. See also caching rules and matching rules.
Assembly is the process of running a compiled response in order to respond to an HTTP request. When the WebAccelerator system receives an HTTP request that it can service from its cache, it places that request in an assembly queue. The WebAccelerator system then uses special threads to run the compiled response (including any related ESI-compiled response), and assembles the content required to respond to the request.
Assembly rules dictate how the WebAccelerator system assembles pages in order to respond to requests. Assembly rules contain specific parameter value substitution and various content assembly options, such as compression.
browser minimum age
The browser cache minimum age is a setting that specifies the minimum amount of time that content is stored in the web browser's local cache before the browser checks for fresh content from the WebAccelerator system. This setting affects only the browser's local cache, not the compiled response stored on the WebAccelerator system's cache.
Caching rules dictate how the WebAccelerator system manages HTTP requests. Some caching rules pertain to how the WebAccelerator system handles a request, and some pertain to how the WebAccelerator system handles the response. Each caching rule is associated with a matching rule, represented by a leaf node on the Request Type Hierarchy tree. The WebAccelerator system first matches an HTTP request or response to a matching rule, then applies the associated caching rules. Just like a matching rule, the caching rule can inherit policies from its ancestors, or parent node, on the Request Type Hierarchy tree. See also matching rules and Request Type Hierarchy tree.
Content lifetime is the length of time that is allowed to elapse before a compiled response expires, and the WebAccelerator system sends a request to the origin server for fresh content. Content lifetime can vary for each compiled response.
Edge Side Includes
Edge Side Includes (ESI) is a simple markup language that supports web surrogates, such as the WebAccelerator system, and is used to define web page components for dynamic assembly and delivery of web applications.
Most browsers create up to two persistent TCP connections for each domain from which they are requesting data. The Express Connect feature modifies embedded URLs with unique subdomains, which prompts the browser to open more persistent connections (up to two per subdomain generated by the WebAccelerator system). These additional browsers result in faster data downloads.
The Express Loader feature (enabled by default) increases the efficiency of the web browser's local cache by reducing or eliminating requests to your site for relatively static content, such as images and style sheet (CSS) files.
The WebAccelerator system creates log files called hit logs to log cache hits and misses. These hit logs contain the same sort of information that your web servers create in their log files. For user-defined acceleration policies, you can tailor the information that appears in the WebAccelerator system's hit logs so they work seamlessly with whatever analysis tools you use for your web server log files.
A host map is defined for each application profile and contains a list of hosts to which the Web Accelerator system can match HTTP requests. See also application profile.
A leaf node is part of the Request Type Hierarchy tree. The WebAccelerator system performs application matching only against the leaf nodes in the Request Type Hierarchy tree. For each incoming HTTP request, the WebAccelerator system uses the matching rules for each node, to find the best leaf node to match and then applies the corresponding caching rules.See also Request Type Hierarchy tree and node.
Log headers are the lines that appear at the top of a log file, and are used to identify the type and order of the information written to each line in the log file. Some log analysis software uses log headers to determine how to parse the log file.
Matching rules are based on specific parameters for HTTP request data types and HTTP response data types. The WebAccelerator system uses matching rules to look for specific things 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 caching rules to the request and responses. See also Request Type Hierarchy tree and caching rules.
A node is part of the Request Type Hierarchy tree and represents matching rules and caching rules for an acceleration policy. Nodes are used only for rule inheritance. The WebAccelerator system does not apply matching and caching rules that are associated with a node directly to an HTTP request. Rather, nodes provide a simple way for you to propagate matching and caching rules across one or more leaf nodes. See also Request Type Hierarchy tree and leaf node.
one-to-one connection mapping
One-to-one connection mapping provides a unique connection to the origin server for each unique client connection. One-to-one connection mapping is the most secure connection type, but it is also the slowest mapping option.
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.
parameter value substitution
When you configure parameter value substitution for assembly, the WebAccelerator system changes the targeted parameter's value on a specific page it serves from its cache, so that the parameter you specified appears on the URL embedded in the page.
From the Policy Editor screen, you can view a pre-defined acceleration policy, or create or modify a user-defined acceleration policy.
proxy override rules
Proxy override rules are options that you can specify within proxying rules to identify conditions under which the WebAccelerator system should ignore all proxying rules. When a proxy override rule applies to an HTTP request, the WebAccelerator system can service the request from its cache, even if a proxying rule dictates that the WebAccelerator should send the request to the origin server. See also proxying rules.
Proxying rules identify the elements in a URL of an HTTP request that indicate whether the WebAccelerator system should send a request to your origin servers, instead of attempting to service it from its cache. See also proxying override rules.
random value substitution
Random value substitution is an operation that generates a random number and places that number on a targeted location in an embedded URL. When the WebAccelerator system compiles the page into a response, it examines the target location to see the length of the string used for the value. On subsequent page requests, the WebAccelerator system replaces that value with a random number of the same length.
Request Type Hierarchy tree
The Request Type Hierarchy tree is located on the left side of the Policy Editor screen, and is composed of nodes. The WebAccelerator system performs application matching against leaf nodes that correspond to specific matching rules, and then applies the associated caching rules. See also, application matching.
When you create a host map, you identify the domain as it appears on the HTTP HOST request header. These domains are called requested hosts. See also host map.
The Rewrite Engine uses response rewrite scripts to manipulate HTTP responses received from the origin servers. See also response rewrite scripts.
response rewrite scripts
Response rewrite scripts manipulate HTTP responses that the WebAccelerator system receives from the origin servers. This manipulation occurs before the response is processed by the WebAccelerator system, so it is the manipulated response that the WebAccelerator system manages and caches, not the actual response sent by the origin servers. See also Rewrite Engine.
The stand-in period identifies how long the WebAccelerator system continues to serve content from its cache after content has expired and when the origin servers do not respond when the WebAccelerator system requests fresh content.
The WebAccelerator system uses a source definition for parameter value substitution during assembly. A source definition contains the value that the WebAccelerator system embeds in the URL, in place of the cached value. Typically, the source is a specific request element, such as a particular query parameter, and the WebAccelerator system uses that value during substitution. However, you can specify another source type, such as a random number. See also target definition.
Surrogate targeting is an ESI mechanism that allows you to control a specific surrogate device. This mechanism is required, because a site can contain multiple web surrogates. You can use surrogate targeting to identify header information that is meant for the WebAccelerator system, by adding a parameter to the Surrogate-Control directive.
The WebAccelerator system uses a target definition or parameter value substitution during assembly. A target definition contains the value from the source definition in the embedded URL. The target is always a specific request element, such as a particular query parameter, and the WebAccelerator system replaces its value during substitution. See also, source definition.
Unique Content Identifier (UCI)
A UCI is a collection of elements, such as the URI and query parameters, that is generated in responses from the origin server. The WebAccelerator system uses the UCI to easily match future requests to the correct content in its cache. See also, variation rules.
A value group is a collection of variation rule parameter values. The purpose of a value group is to enable you to specify several different parameter values for the same variation rule. Each value can prompt a different behavior by the WebAccelerator system.
Variation rules are associated with content that is specific to requests. If an acceleration policy contains a variation rule, the WebAccelerator system uses the information in the variation rule to help create the Unique Content Identifier (UCI), for the request and for the cached page, which the WebAccelerator system stores in its cache in the form of a compiled response. See also, Unique Content Identifier (UCI).