Applies To:

Show Versions Show Versions

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

11 
Cache invalidation is a powerful tool that allows you to maintain tight coherence between the content on your origin web servers and the content that the WebAccelerator system has in its cache.
If you update content for your site at regular intervals, such as every day or every hour, you can use lifetime rules to ensure that the WebAccelerator systems cache is refreshed with the same frequency. Invalidations rules, on the other hand, allow you to expire cached content before it has reached its time to live (TTL) value, and is a good tool to use when content updates are event-driven, such as when an item is added to a shopping cart, a request contains a new auction bid, or a poster has submitted content on a forum thread. For these situations, you can use invalidations rules to identify those specific events that prompt the WebAccelerator system to refresh its cached content.
When you configure invalidations rules, you define elements in a request that prompt the WebAccelerator system to invalidate and refresh specific cached content. When the WebAccelerator system receives a request that matches the parameters that you specified for the invalidations rule, it performs the following steps:
Replaces the specified content, which it previously had in its cache, with the new content it receives from the origin web server.
You can create invalidations rules that are more general. For example, you can create a rule to invalidate any request that contains a specific cookie. Depending on how your site is designed, this type of invalidations rule can invalidate a significant percentage of the compiled responses that is currently cached by the WebAccelerator system. You also have the option to invalidate the entire contents of the WebAccelerator systems cache with a single rule, by specifying that any request received by your domain is invalidated.
Although there may be situations that require you to invalidate a significant portion of the cache, it is important to keep in mind that such a broad invalidation process can tax the origin web server as it attempts to respond to multiple requests for new content. For this reason, we recommend that you make the invalidations rule parameters specific, whenever possible.
An invalidations rule is active.
You can create invalidations rules and enable or disable them at any time.
The invalidations rule contains a path parameter for both the Request Header Matching Criteria and the Cached Content to Invalidate. If you do not want to assign a specific path, you can use a single slash (/).
The invalidations rule has reached its effective time.
You can specify that invalidations rules are effective immediately, or you can set a time in the future.
The WebAccelerator system has refreshed the cached content that corresponds to the request, before the effective date on the invalidations rule.
This ensures that the WebAccelerator system does not invalidate a compiled response more than once, under the same invalidations rule. A compiled responses refresh time identifies the last time the WebAccelerator system refreshed that compiled response with content from the origin web server. If the compiled response was refreshed after the invalidations rule went into effect, the WebAccelerator system considers the content current.
The request matches the configured request header matching criteria that you specified.
The information that appears on the request must match all the HTTP request data type parameters that you specified for the Request Header Matching Criteria within the invalidations rule.
For example, the following requests are candidates for invalidation for an invalidations rule that specifies, in the Request Header Matching Criteria, that the product query parameter must be Computers and that the path for the request must begin with /apps.
Invalidations rules are typically targeted at a range of compiled responses. The WebAccelerator system does not invalidate a compiled response until it matches a request to the invalidations rule for that compiled response, and it does not invalidate a range of compiled responses until it receives a request for each individual response in the range.
By assigning an appropriate lifetime for a rule, the WebAccelerator system ensures that it refreshes every targeted compiled response, before it discards the rule. The WebAccelerator system assigns the lifetime value for the invalidations rule by examining the maximum lifetime values set for all compiled responses targeted by the rule, and using the longest TTL value it finds. When the longest TTL value for the compiled responses is reached, the WebAccelerator system considers those compiled responses expired and refreshes them, even if an invalidation trigger has not occurred.
For example, if you created an invalidations rule for any requests that have either /apps or /srch in their path, your Policy Tree would include two nodes with application matching rules set so that requests with /apps in the path match to one node, and requests with /srch match to the other node. For this example, the /srch node has a lifetime rule specifying a maximum age of 15 minutes, while the /apps node uses the systems maximum lifetime of 24 hours.
Compiled responses that the WebAccelerator system creates to service requests matching the /srch node have a maximum lifetime of 15 minutes. Compiled responses that the WebAccelerator system creates to service requests matching the /apps node uses a maximum lifetime of 24 hours. Based on this, the WebAccelerator system assigns a 24 hour lifetime for the invalidations rule.
During the 24 hours that the rule is in effect, the WebAccelerator system refreshes compiled responses either because they match an invalidations rule or because they have exceeded the set lifetime value. Either way, the WebAccelerator system refreshes any content matching the invalidations rule at least once before it discards the rule.
You organize invalidations rules on the Policy Tree, with any associated invalidations rules assigned to the leaf node. You can configure invalidations rules only for leaf nodes on the Policy Tree, and you can define multiple invalidations rules for each leaf node.
The WebAccelerator system triggers invalidations rules before performing response matching, therefore, invalidations rules only apply to requests that match to a node, never to responses.
Request Header Matching Criteria
You define the parameters that the WebAccelerator system must match in a request, in order to trigger the invalidations rule
Cached Content to Invalidate
You define the content to invalidate and refresh, if the WebAccelerator system finds the parameters in the HTTP request header that are specified in the Request Header Matching Criteria setting
Warning: When configuring an invalidation rule, all parameters are optional except for the Path parameter. If you do not specify the Path parameter for the Request Header Matching Criteria and the Cached Content to Invalidate settings, the invalidations rule does not trigger the WebAccelerator system to invalidate the specified cache. If you do not want to define a specific path, you can use a single slash (/).
For the Request Header Matching Criteria setting, you specify the HTTP request data type parameter that the WebAccelerator system must find in an HTTP request header, in order to trigger the invalidations rule. For the WebAccelerator system to apply an invalidations rule, the HTTP request must match to a leaf node as well the associated parameters specified for the Request Header Matching Criteria setting.
Not all requests that match a node that you define will trigger the invalidations rule. You can define a subset of matching requests by specifying additional parameters for the source as part of the rule. Then, only the defined subset of requests trigger the invalidations rule. For example, assume that to match to a particular node, a request must include /apps/shopping in the path and the query parameter cart must be present. To configure the Request Header Matching Criteria setting parameters for this node, you specify that a request must include the query parameter cart and the value of cart must equal Add. In this case, not all requests that match the node prompt the invalidation. The WebAccelerator system only invalidates requests where cart=add.
The WebAccelerator system does not examine incoming requests and compare them to the configured Cached Content to Invalidate unless it first finds the Request Header Matching Criteria. Once the WebAccelerator system matches a request to the parameters configured for the Request Header Matching Criteria, it reviews the parameters set for the Cached Content to Invalidate. If a match occurs, the WebAccelerator system invalidates the content specified by the Cached Content to Invalidate parameter that you configured, and retrieves fresh content from the origin web server. Once it receives the fresh content, the WebAccelerator system stores the content in its cache and services the request. When you specify Cached Content to Invalidate, you must provide at least one parameter based on the Path data type.
Always configure the invalidations rule for the leaf node on the Policy Tree that describes the types of requests that should trigger the invalidation. That is, create the invalidations rule for the node of the Request Header Matching Criteria, not for the node of the Cached Content to Invalidate. The requests that match to the node should be the requests that activate the invalidations rule, not the requests for which the compiled responses became invalidated.
This section of the chapter provides information about how to configure an example invalidations rule. For this example site, you have three top-level nodes on 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.
For this example, any request for the application, /apps/doSomething.jsp, changes content returned by /srch/doSimpleSearch.jsp. However, you want requests for doSimpleSearch.jsp to be updated only if its producttype query parameter matches the value set for the group query parameter on doSomething.jsp.
For this, you create an invalidations rule for the Default leaf node, because you know that all requests for the path, /apps/doSomething.jsp, match to that node. The target, requests for doSimpleSearch.jsp, always match to the Search node and should include a producttype query parameter when a value matches the value of group in the triggering request for /apps/doSomething.jsp. Therefore, the Cached Content to Invalidate setting should specify doSimpleSearch.jsp for the path, and producttype for the query parameter.
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 the existing 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 Invalidations.
The Invalidations Rules screen opens.
7.
Click the Create button.
The invalidations rules options display.
8.
In the Description box, type a description for the invalidations rule. For example: doSomething invalidated producttype
9.
In the Request Header Matching Criteria area, select Path from the Add Parameter list, and click the Add button.
The Parameter Identity screen opens.
10.
In the Value(s) box, type the following application path: /apps/doSomething.jsp
This prompts the WebAccelerator system to trigger the invalidations rule only for this application. All other requests that match to the Default node do not trigger this invalidations rule.
11.
Click the Save button.
The Request Header Matching Criteria table displays the Path parameter that you defined.
12.
In the Cached Content to Invalidate area, select Path from the Add Parameter list, and click the Add button.
The Parameter Identity screen opens.
13.
In the Value Match area, select Value Group from the Type list.
The Value Group box displays.
14.
In the Value Group box, type the following path:
/srch/doSimpleSearch.jsp
15.
Click the Save button.
The Cached Content to Invalidate table displays the Value Group parameter that you defined.
16.
In the Cached Content to Invalidate area, select Query Parameter from the Add Parameter list, and click the Add button.
The Parameter Identity screen opens.
17.
In the Name box, type producttype.
18.
In the Value Match area, select Query Parameter from Request from the Type list.
The Name box displays.
19.
In the Query Parameter from Request box, type group.
20.
Click the Save button.
The Cached Content to Invalidate table displays the Query Parameter from Source parameter that you defined.
21.
Click the Save button.
For a new or modified acceleration policy to be in effect for your site, you must publish it. One way to do this is to click the Publish button from any screen within the Policy Editor to open the publish screen. We recommend that when you make a series of changes to an acceleration policy, you click the Publish button on the Policy Editor screen only after you make the last change in the series. Alternatively, you can publish an acceleration policy from the Policies screen. See Publishing acceleration policies, for more information.
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)