Applies To:

Show Versions Show Versions

Manual Chapter: Configuring Variation Rules
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

When the WebAccelerator system caches responses from the origin web server, it uses elements, such as the URI and query parameters, to create the Unique Content Identifier (UCI). The WebAccelerator system stores the UCI in its cache in the form of a compiled response. and uses the UCI to easily match future requests to the correct content in its cache. When creating a UCI, the WebAccelerator system ignores or includes certain elements in a request (see Understanding caching behavior, for default behavior).
The purpose of a variation rule is to allow you to change and refine the elements on which the WebAccelerator system bases its caching process. If an acceleration policy contains a variation rule, the WebAccelerator system uses the configured parameters in the variation rule to create the UCI for the request, and for the cached page. If the WebAccelerator system receives two requests that are identical, except for the value of a particular query parameter defined in the variation rule, the WebAccelerator system creates a different UCI for each and caches each response under its unique UCI.
For example, by default the WebAccelerator system functions on the assumption that a cookies presence and value, or the absence of a cookie, does not change the contents of the web page it serves. However, if you would like the presence and value of a cookie to prompt the WebAccelerator system to serve a different page, you can configure a variation rule with a cookie parameter that prompts the WebAccelerator system to serve particular content, such as a page that is customized with a clients user name, based on a certain cookie parameter located in the request.
Once you configure the variation rule parameter for a specific cookie, the WebAccelerator system uses that cookie and its value in the UCI for any request assigned to the specified node. For the WebAccelerator system to match the UCI of a new request and the UCI of a cached page, the new request must have the same value for the cookie as the request that generated the cached page. When it finds a match, the WebAccelerator system uses the stored page to service the new request.
Variation rules affect the UCI under which the WebAccelerator system cached the response; therefore, the WebAccelerator system applies variation rules to all requests after it matches the request to a node, even when it sends the request to the origin server for fresh content.
You organize variation rules in the Policy Tree, with any associated variation rules assigned to the leaf node. Each leaf node that has a variation rule must contain at least one defined parameter. The variation parameters specified for a leaf node are a combination of the parameters that you defined locally at the node, and any parameters that are inherited from the nodes ancestors. (For information about inheritance support in the Policy Tree, see Understanding rule inheritance within the Policy Tree.)
You use variation rules to specify the HTTP request elements on which the WebAccelerator system bases caching behavior. The HTTP request flow occurs as follows:
2.
Once it matches the request to a leaf node, the WebAccelerator system examines the leaf node to see if a variation rule is defined for the leaf node.
3.
If a variation rule is defined for the leaf node, the WebAccelerator system reviews each of the rule parameters to see which elements of the HTTP request it should use to create the UCI. (The variation rule parameters override the defaults that define which elements affect page content and should, therefore, be included in the UCI.)
4.
5.
The WebAccelerator system uses the UCI to find a valid compiled response in its cache. If it finds a compiled response cached under the same UCI, and that UCI has not expired, the WebAccelerator system services the request with that compiled response.
6.
If a valid compiled response is not available, the WebAccelerator system sends a request to the origin server.
7.
Once it receives a response from the origin server, the WebAccelerator system creates a compiled response and caches it under the UCI it created in Step 4.
The WebAccelerator system caches certain HTTP request elements, by default. You can use variation rules to instruct the WebAccelerator system to cache other elements or to modify the default caching options, thereby customizing caching behavior.
If one or more of these elements do not affect the content that your site serves, you can create a variation rule instructing the WebAccelerator system to not include those parameters in the UCI. In other words, if the presence and value of these parameters in an HTTP request can vary while the response remains the same, you should create a rule to make the WebAccelerator system aware of that. That way, when the WebAccelerator system assembles a UCI, it includes does not include the parameters that you specify as not significant for content in the variation rule.
If the content that your site serves is dependent on one or more of these elements, you must create a variation rule instructing the WebAccelerator system to include those parameters in the UCI. In other words, if the presence and value of these parameters in a request require different responses from your site, create a rule to make the WebAccelerator system aware of that. That way, when the WebAccelerator system assembles a UCI, it includes the parameters you specify in the variation rule.
You must create a variation rule if a parameter that is not included in the UCI by default affects the content served by your site. That is, you should create a variation rule if the content that your site serves is dependent on:
The state of the HTTP USER_AGENT, REFERER, or other request headers
If you do not create a variation rule in these situations, the WebAccelerator system may not provide the content you want when servicing a request.
Suppose your site receive client requests for an application and you want the WebAccelerator system to serve content served based on whether the client is a customer or a partner. To do this, you create a variation rule that identifies the version cookie as significant for content. You can then define that when the version cookie is set to a value of 1, the WebAccelerator system responds with a version of the page that contains content specifically for customers, and when the version cookie is set to a value of 2, the WebAccelerator system responds with a version of the page that contains content specifically for partners.
For content produced for Cookie: version=1.
For content produced for Cookie: version=2.
For content produced when the version cookie does not appear in the request.
It is important to keep in mind that when you are creating this variation rule, you must specify that the version cookie parameters are significant for content. If you do not, the WebAccelerator system ignores the value set for the cookie and produces, at most, two compiled responses: One for requests that contain the cookie, and one for requests that do not contain the cookie.
If version is not specified as a parameter that is significant for content, the WebAccelerator system does not include the value of version in the UCI. That means that when the WebAccelerator system receives the first request, it generates a UCI and sends the request to the origin server. Once it receives the response from the origin server, the WebAccelerator system caches the response under the UCI.
If the first request contains the cookie version=2, the page that the WebAccelerator system caches is under the UCI is for the partners content. Since all subsequent requests that include that cookie have the same UCI, the WebAccelerator system serves the cached partner page, even if the request contains the cookie version=1 and should be served the customer page, unless you specify that the cookie version parameter is significant for content.
You can use variation rules not only to serve particular pages to specific requests, but also to save cache space. When you use the appropriate variation rules, you can greatly reduce the size of the cache and enhance cache efficiency, resulting in a significant resource savings. You do this by setting variation rules for request parameters that the WebAccelerator system treats as significant for content, but that your site ignores when determining content to return.
For example, if your site uses a query parameter that provides session tracking information, and your sites pages are not affected by the value set for the session tracking query parameter, you can configure a variation rule to identify the session tracking query parameter as not significant for content. This way, the WebAccelerator system caches one version of the page for any value of the session tracking query parameter, instead of caching separate but identical pages for each different value.
Without a variation rule in this situation, the WebAccelerator system creates one unique compiled response for every page that every user views. This results in an unnecessarily large cache.
Variation rules are based on HTTP request data parameters that the WebAccelerator system uses to determine which request elements to include in a UCI. The purpose of defining variation parameters is to specify one of the following behaviors:
HTTP request elements that match the variation rule result in unique page content.
The WebAccelerator system uses the specified parameter and its value in the UCI it creates for the request.
HTTP request elements that match the variation rule do not result in unique page content.
The WebAccelerator system ignores the value set for the specified parameter, which means that the parameter and its value are not included in the UCI that the WebAccelerator system creates for the request.
If an element in a request matches two or more variation rule parameters, and the parameter defines conflicting behavior (one parameter indicates that the value is significant for content and the other does not), the WebAccelerator system considers the parameter significant for content. This means that the WebAccelerator system compiles a separate response for the conflicting parameter value in the request. This is the most reliable way to handle conflict when the WebAccelerator system matches a request value to multiple parameters.
If you specify conflicting named and unnamed query parameter values in a variation rule, it can be unclear which the WebAccelerator system should use when processing a request.
For example, consider a request for http://www.siterequest.com/show.jsp?computer&vendor=whiteBox and a configured variation rule with the parameters outlined in Table 7.1.
When applying this variation rule to the request for http://www.siterequest.com/show.jsp?computer&vendor=whiteBox, the WebAccelerator system could interpret computer as either of the following:
A query parameter named computer that has no value set for it
Therefore, it is unclear whether the WebAccelerator system should use computer in the UCI, and whether the result is a unique page. In this case, the WebAccelerator system determines that the query is ambiguous, and matches the request to the node with the highest priority in the Policy Tree. For information about how to modify node priority, see To change the priority of a node on the Policy Tree.
By default the WebAccelerator system treats all ambiguous query parameters as a named query parameter without a value. You can override this default behavior by performing the steps in the following procedure.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
4.
On the Policy Tree, click the node for which you want to change the All Other Query Parameters variation parameter.
5.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
6.
On the Policy Editor menu bar, click Variation.
The Variation Rules screen opens, displaying a summary of variation rules for the node.
7.
From the Name column in the variation rules table, click All Other Query Parameters.
The Parameter Identity screen opens.
8.
Check the box for Treat ambiguous query parameters as unnamed.
9.
Click the Save button.
The Variation Rules screen opens, displaying the variation rules table for the node.
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.
For example, a matching rule based on cookie A can only specify a single set of values for the cookie, depending on a match or a no match. For more flexibility, you could use a variation rule with a value group for cookie A, consisting of several rules such as:
When cookie A begins with aa, the page content is the same.
This rule indicates that the WebAccelerator system matches all requests to the same page if the request contains a cookie called A with a value that begins with aa.
When cookie A begins with bb, the page content is the same.
This rule indicates that the WebAccelerator system matches all requests to the same page if the request contains a cookie called A with a value that begins with bb. However, the page it matches is different from the page for cookie A with a value of aa.
For all other cookie A values, page content is unique.
This rule indicates that the WebAccelerator system matches all requests that contain a cookie called A with any value that does not begin with with aa or bb, to a unique page specified for each cookie value. That is, if there were three requests with three different values for cookie A (such as ca233, ca234, ba234), the WebAccelerator system would match the requests to three different pages.
This section of the chapter provides information about how to configure an example variation rule for a user-defined acceleration policy. For this example site, you have three top-level nodes in the Policy Tree as follows:
Home
This branch node specifies the rules related to the home page.
Applications
This branch node specifies the rules related to the applications for the site, with the following leaf nodes:
Default
This leaf node specifies the rules related to non-search related applications.
Search
This leaf node specifies the rules related to your sites search application.
Images
This branch node specifies the rules related to graphics images.
Note: See To create the Home, Application, and Images nodes for the example Policy Tree, for specific instructions about how to create the Policy Tree.
It needs to provide different branding information if the REFERER request header begins with, http://www.siterequest.com.
Any other value for the REFERER request header does not affect the content served by your site.
It uses a query parameter called sessionID to track site users.
This query parameter does not affect page content, and is used for tracking purposes only.
REFERRER rule
You base this rule on the REFERER data type, and set it on the Applications node.
Query Parameter rule
You base this rule on the Query Parameter data type, and set on the Search node.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
4.
5.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
6.
On the Policy Editor menu bar, click Variation.
The Variation Rules screen opens, displaying a summary of variation rules for the node.
7.
From the Name column in the variation rules table, click Referrer.
The Parameter Identity screen opens.
8.
In the Value Groups area, click the Add button.
The screen refreshes and displays the value groups options.
9.
Check the Values matches check box, and in the adjacent box, type the regular expression that matches the value you expect on the REFERER request header, as follows:
Note: For more information about regular expressions, see Appendix C, Supporting Regular Expressions.
10.
From the Values Define list, select Different Content, to prompt the WebAccelerator system to provide a unique page to matched requests.
11.
Click the Save button.
The new variation parameter displays next to the Referrer rule in the variation rule summary table.
1.
On the Main tab of the navigation pane, expand WebAccelerator and click Applications.
The Applications screen opens in a new window.
2.
On the Main tab of the navigation pane in the new window, click Policies.
The Policies screen opens, displaying a table of user-defined and pre-defined acceleration policies.
3.
On the User-defined Acceleration Policies table, click the name of the acceleration policy that you want to edit.
The Policy Editor screen opens.
5.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
The acceleration rules display on the Policy Editor menu bar.
6.
On the Policy Editor menu bar, click Variation.
The Variation Rules screen opens, displaying a summary of variation rules for the node.
7.
From the Add Parameter list, select Query Parameter and click the Add button.
The Parameter Identity screen opens.
8.
In the Name box, type sessionID.
9.
In the Values Groups area, click the Add button.
The screen refreshes and displays the value groups options.
10.
Check the Values matches check box, and in the adjacent box, type the following regular expression:
11.
Check the box for Value is an empty string.
12.
From the Values Define list, select Same Content, to indicate that page content is not affected by this parameter.
13.
Click the Save button.
The new parameter displays in the variation summary table next to the Search 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)