Applies To:

Show Versions Show Versions

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

10 
Cache invalidation is a powerful tool that you can use 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 WebAcceleratorTM 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.
1.
In the navigation pane, expand WebAccelerator and click Policies.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
5.
Click Invalidations.
6.
Click the Create button.
7.
In the Description box, type a description for the invalidations rule. For example: doSomething invalidated producttype
9.
Click the Save button.
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 based on a specific parameter, for example, an invalidation rule based on a certain cookie.
Important: 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 as specific as possible, 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.
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 only matches a request to an invalidation rule if it first finds the parameters set for the Request Header Matching Criteria setting. If it matches a request to the parameters configured for the Request Header Matching Criteria setting, only then does the WebAccelerator system review the parameters set for the Cached Content to Invalidate setting. If a match occurs, the WebAccelerator system invalidates the content specified, and retrieves fresh content from the origin web server. The WebAccelerator system stores the fresh content in its cache and services the request. When configuring an invalidations rule, you must provide at least one parameter based on the Path data type for the Cached Content to Invalidate setting.
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.
For this example, any request for the /apps/doSomething.jsp application 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.
To accomplish 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.
In the navigation pane, expand WebAccelerator and click Policies.
3.
4.
From the Matching Rules list on the Policy Editor menu bar, select Acceleration Rules.
5.
Click Invalidations.
6.
Click the Create button.
7.
In the Description box, type a description for the invalidations rule. For example: doSomething invalidated producttype
8.
In the Request Header Matching Criteria area, select Path from the Add Parameter list, and click the Add button.
9.
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.
10.
Click the Save button.
The Request Header Matching Criteria table displays the Path.
11.
In the Cached Content to Invalidate area, select Path from the Add Parameter list, and click the Add button.
12.
In the Value Match area, select Value Group from the Type list.
13.
In the Value Group box, type the following path:
/srch/doSimpleSearch.jsp
14.
Click the Save button.
15.
In the Cached Content to Invalidate area, select Query Parameter from the Add Parameter list, and click the Add button.
16.
In the Name box, type producttype.
17.
In the Value Match area, select Query Parameter from Request from the Type list.
18.
In the Query Parameter from Request box, type group.
19.
Click the Save button.
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)