Applies To:

Show Versions Show Versions

Manual Chapter: Policy Management Guide for the BIG-IP WebAccelerator Module: 11 - Performing Cache Invalidation
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


11

Performing Cache Invalidation


Overview of cache invalidation

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.

Note

For additional information about rules for content lifetime, see Chapter 10, Configuring Lifetime Rules .

Defining invalidation methods

The methods of invalidating content on the WebAccelerator system, include:

  • Invalidation rules
    Used to expire specific content under specific conditions. When the WebAccelerator system receives a request that matches an invalidation rule's source matching rule, it expires the content specified by the configured target matching rule.
  • Manual invalidation
    Used to prompt the WebAccelerator system to immediately expire the content in its cache. You can use this method when you determine that the cached content is no longer current (for example, because you just updated content on your site).

Configuring invalidation rules

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:

  • Invalidates the cached content that it would have served.
  • Sends the request to the origin server for fresh content.
  • Replaces the content that it previously had in its cache with the new content.
  • Responds to the request with the refreshed content.

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.

Organizing invalidation rules in the Request Type Hierarchy tree

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.

Specifying matching rules

When configuring an invalidation rule, you must specify the following:

  • Source matching rules
    Parameters that the WebAccelerator system must match in a request, in order to trigger the invalidation rule.
  • Target matching rules
    Parameters that specify the content that the WebAccelerator system must invalidate and refresh, after the invalidation rule has been triggered through the source matching rules.

Source matching rules

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.

Target matching rules

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.

Important

Always configure the invalidation rule for the leaf node on the Request Type Hierarchy that describes the types of requests that should trigger the invalidation. That is, create the invalidation rule for the node of the source matching rules, not for the node of the target matching rules. The requests that match to the node should be the requests that activate the invalidation rule, not the requests for which the compiled responses get invalidated.

Triggering invalidation

To prompt the WebAccelerator system to trigger an invalidation rule for a request, the following must occur:

  • The invalidation rule must reach its effective time.
    You can specify that invalidation rules are effective immediately, or you can set a time in the future.
  • The request must match the configured source matching rules.
    The information that appears on the request must match all the HTTP request data type parameters that you specified for the source matching rules within the invalidation rule.
  • 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.

    http://www.somesite.com/apps/shop.jsp?action=show&product=Computers

    http://web1.somesite.com/apps/search/simple.jsp?product=Computers&

    category=desktop

    While the following requests are not candidates for invalidation:

    http://www.somesite.com/shop.jsp?action=show&product=Computers

    http://web1.somesite.com/apps/search/simple.jsp?product=Organizers&

    category=desktop

  • The WebAccelerator system must have refreshed the cached content that corresponds to the request, before the effective date on the invalidation rule. This ensures that the WebAccelerator system does not invalidate a compiled response more than once under the same invalidation rule. A compiled response's refresh time identifies the last time the WebAccelerator system refreshed that compiled response with content from the origin server. If the compiled response was refreshed after the invalidation rule went into effect, the WebAccelerator system considers the content current.

Setting the lifetime for invalidation rules

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.

For information about setting lifetime rules, see Chapter 10, .

Configuring an invalidation rule example

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:

  • Home
    Specifies the rules related to the home page.
  • Applications
    Specifies the rules related to the applications for the site, with child nodes, such as:
    • Default
      Specifies the rules related to non-search related applications.
    • Search
      Specifies the rules related to your site's search application.
  • Images
    Specifies the rules related to graphics images.
Note

See, To create the Home, Application, and Images nodes for the example Request Type Hierarchy tree , located in Chapter 4, for specific instructions about how to create the Request Type Hierarchy tree.

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.

To create the example invalidations rule

  1. On the Main tab of the navigation pane, click Policies.
    The Policies screen opens, displaying a list of acceleration policies.
  2. Click Edit next to the acceleration policy that you want to edit.
    The Policy Editor screen opens.
  3. From the Request Type Hierarchy tree, click the Default node.
  4. On the acceleration policy menu bar, click Invalidations.
    The Invalidations rules screen opens.
  5. Click the Add button.
    The invalidation rule's options display.
  6. In the Description box, type a description for the invalidation rule. For example: doSomething invalidated producttype
  7. In the Source Matching Rules area, select Path from the Add Parameter list, and click the Add button.
    The Parameter Identity screen opens.
  8. In the Value(s) box, type the following application path:
  9. /apps/doSomething.jsp

    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.

  10. Click the Save button.
    The Source Matching Rules table displays the Path parameter that you defined.
  11. In the Target Matching Rules area, select Path from the Add Parameter list, and click the Add button.
    The Parameter Identity screen opens.
  12. In the Value Match area, select Value Group from the Type list.
    The Value Group box displays.
  13. In the Value Group box, type the following path:
  14. /srch/doSimpleSearch.jsp

  15. Click the Save button.
    The Target Matching Rules table displays the Value Group parameter that you defined.
  16. In the Target Matching Rules area, select Query Parameter from the Add Parameter list, and click the Add button.
    The Parameter Identity screen opens.
  17. In the Query Parameter Name box, type:
  18. producttype

  19. In the Value Match area, select Query Parameter from Source from the Type list.
    The Name box displays.
  20. In the Query Parameter from Source Name box, type group.
  21. Click the Save button.
    The Target Matching Rules table displays the Query Parameter from Source parameter that you defined.
  22. Click the OK button.
    The Invalidation Triggers summary screen opens.
  23. Verify that the Active check box is checked next to each of the invalidated triggers that you created.
  24. Click the Save button.

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.

Invalidating content manually

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.

To manually invalidate cached content

  1. On the Main tab of the navigation pane, click Applications.
    The Applications screen opens.
  2. On the Main tab of the navigation pane, click Invalidate Content.
    The Invalidate Content screen opens.
  3. Configure the conditions under which you want to invalidate content.
  4. In the Application(s) to Apply Invalidation area, check the box next to the application you want to invalidate. Or, check the Select All check box.
  5. Click the Invalidate button.

Manual invalidation example

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:

/images/automobile_228a9.gif
/images/automobile_q5df90.gif
/images/automobile_nnp8g5.gif

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.

To manually invalidate the cached automobile images

  1. On the Main tab of the navigation pane, click Applications.
    The Applications screen opens.
  2. On the Main tab of the navigation pane, click Invalidate Content.
    The Invalidate Content screen opens.
  3. In the Cached Content to Invalidate area, click the Invalidate content that matches the following URI expression button.
  4. In the box, type the following regular expression:
  5. /\/images\/automobile_.*\.gif/
  6. In the Application(s) to Apply Invalidation area, check the car rental application check box.
  7. Click the Invalidate button.

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.




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)