Cache invalidation is a powerful tool that allows you to maintain tight coherence between the content on your origin 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 system's cache is refreshed with the same frequency. Cache invalidation, on the other hand, allows 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 or a request contains a new auction bid. For these situations, you configure specific events to prompt the WebAccelerator system to refresh its cached content using cache invalidation.
The methods of invalidating content on the WebAccelerator system, include:
One way to trigger cache invalidation is by using invalidation rules. When you configure invalidation rules, you define elements on a request that prompt the WebAccelerator system to invalidate and refresh specified cached content. When the WebAccelerator system receives a request that matches the parameters that you specified for the invalidation rule, it performs the following steps:
You can create invalidation rules that are quite broad. 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 invalidation 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 system's cache with a single rule, by specifying that any request received by your domain is invalidated.
Although there are times when you need to invalidate a significant portion of the cache, this process can tax the origin server as it attempts to respond to multiple requests for new content. For this reason, it is important to make the invalidation rule parameters as specific as possible.
You organize invalidation rules in the Request Type Hierarchy tree, with any associated invalidation rules assigned to the leaf node. You can configure invalidation rules only for leaf nodes in the Request Type Hierarchy tree. You can, however, define multiple invalidation rules for each leaf node.
The WebAccelerator system triggers invalidation rules before performing response matching, therefore, invalidation rules only apply to requests that match to a node, never to responses.
When configuring an invalidation rule, you must specify the following:
You configure source matching rules by specifying the HTTP request data type parameters and their values that are required for a match. For the WebAccelerator system to trigger an invalidation rule, the HTTP request must match to a leaf node and all of the associated parameters specified for the source matching rule.
Not all requests that match a node that you define will trigger the invalidation rule. You can define a subset of matching requests by specifying additional parameters for the source as part of the rule. Then, only this subset of requests trigger the invalidation 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 source matching rule for this node, you can 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 target matching rules unless it first matches a source matching rule. Once the WebAccelerator system matches a request to the parameters for the source matching rule, it reviews the parameters set for the target matching rule.
You configure target matching rules by specifying the HTTP request data type parameters and their values that are required for a match. If a match occurs, the WebAccelerator system invalidates the content specified by the target matching rule and retrieves fresh content from the origin server. Once it receives the fresh content, the WebAccelerator system stores the content in its cache and services the request.
When specifying a target matching rule, you must provide at least one parameter based on the Path data type.
To prompt the WebAccelerator system to trigger an invalidation rule for a request, the following must occur:
The following requests are candidates for invalidation for an invalidation rule that specifies, in the source matching rules, that the product query parameter must be Computers and that the path for the request must begin with /apps.
While the following requests are not candidates for invalidation:
Invalidation 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 invalidation rule for that compiled response. The WebAccelerator system does not invalidate a range of compiled responses until it receives a request for each individual response in the range. By setting 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 sets the lifetime for the invalidation rule by examining the maximum lifetime values set for all compiled responses targeted by the rule, and using the longest TTL value it finds for the rule. 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 invalidation rule for any requests that have either /apps or /srch in their path, your Request Type Hierarchy 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 a maximum age of 15 minutes, while the /apps node uses the system's 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 your invalidation rule.
During the 24 hours that the rule is in effect, the WebAccelerator system refreshes compiled responses either because they match an invalidation rule or because they have exceeded the set lifetime value. Either way, the WebAccelerator system refreshes any content matching the invalidation rule at least once before it discards the rule.
This section of the chapter provides information about how to configure an example invalidation rule. For this example site, you have three top-level nodes in the Request Type Hierarchy as follows:
For this example, any request for /apps/doSomething.jsp changes content returned by /srch/doSimpleSearch.jsp. However, you want requests for doSimpleSearch.jsp to only be updated if its producttype query parameter matches the value set for the group query parameter on doSomething.jsp.
That is, if the WebAccelerator system receives the following request: http://www.somesite.com/apps/doSomething.jsp?group=Doors&....
it should send, to the origin server, any subsequent requests that appear as follows: http://www.somesite.com/srch/doSimpleSearch.jsp?producttype=Doors&....
For this, you create an invalidation rule on the Default node, because you know that all requests for /apps/doSomething.jsp match to that node. Its target, requests for doSimpleSearch.jsp, always match to the Search node should include a producttype query parameter with a value matches the value of group in the triggering request for /apps/doSomething.jsp. Therefore, the target matching rule should specify doSimpleSearch.jsp for the path and producttype for the query parameter.
This prompts the WebAccelerator system to trigger the invalidation rule only for this application. All other requests that match to the Default node, do not trigger this invalidation rule.
For a new or modified acceleration policy to be in effect for your site, you must publish it. See Publishing acceleration policies , located in Chapter 3, for more information.
You can use the manual invalidation method to invalidate specific cached content the next time the WebAccelerator system receives a request for it. Since an invalidation rule is not associated with manual invalidation, you do not have to publish a policy in order to activate it. Instead, you define the applications or specific content that you want invalidated.
This section of the chapter provides information about how to configure a manual invalidation example. For this example, you have a car rental application that serves groups of images using the following naming convention:
These images are stable, so you set a long cache TTL value for them using a lifetime rule, however, you recently updated all your automobile_xxx images and you want to refresh these images in the WebAccelerator system's cache.
Now, the next time each one of the automobile images is requested from your site, the WebAccelerator system will send the request to the origin server and refresh its cache with the updated images.