Applies To:Show Versions
- 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Invalidating Cached Content
Overview: Invalidating cached content for an application
You can manually invalidate cached content for one or more applications, which expires, but does not remove, the cached content. Invalidating cached content by application is useful for troubleshooting as well as for manually refreshing the cached content.
Overview: Invalidating cached content for a node
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 BIG-IP system caches.
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 system’s cache is refreshed with the same frequency. Invalidations rules, however, 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.
When you configure invalidations rules, you define elements in a request that prompt the BIG-IP system to invalidate and refresh specific cached content. When the BIG-IP system receives a request that matches the parameters that you specified for the invalidations rule, it performs the following steps.
- Invalidates the cached content that it would have served.
- Sends the request to the origin web server for fresh content.
- Replaces the specified content, which it previously had in cache, with the new content it receives from the origin web server.
- Responds to the request with the refreshed content.
You can create invalidations rules that are based on a specific parameter, for example, an invalidation rule based on a certain cookie.
The BIG-IP triggers an invalidations rule for a request, only when the following conditions exist.
- 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 BIG-IP has refreshed the cached content that corresponds to the request,
before the effective date on the invalidations rule.
This ensures that the BIG-IP module does not invalidate a compiled response more than once, under the same invalidations rule. A compiled response’s refresh time identifies the last time the BIG-IP 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 BIG-IP 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.
While the following requests are not candidates for invalidation.
Invalidations rules are typically targeted at a range of compiled responses. The BIG-IP 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 BIG-IP ensures that it refreshes every targeted compiled response, before it discards the rule. The BIG-IP 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 BIG-IP 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 system’s maximum lifetime of 24 hours.
Compiled responses that the BIG-IP creates to service requests matching the /srch node have a maximum lifetime of 15 minutes. Compiled responses that the BIG-IP creates to service requests matching the /apps node uses a maximum lifetime of 24 hours. Based on this, the BIG-IP assigns a 24-hour lifetime for the invalidations rule.
During the 24 hours that the rule is in effect, the BIG-IP refreshes compiled responses either because they match an invalidations rule or because they have exceeded the set lifetime value. Either way, the BIG-IP refreshes any content matching the invalidations rule at least once before it discards the rule.
Invalidations rules parameters
When configuring an invalidations rule, you must specify parameters for the following settings.
- Request Header Matching Criteria. You define the parameters that the BIG-IP 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 BIG-IP finds the parameters in the HTTP request header that are specified in the Request Header Matching Criteria setting.
Request header matching criteria
For the Request Header Matching Criteria setting, you specify the HTTP request data type parameter that the BIG-IP must find in an HTTP request header, in order to trigger the invalidations rule. For the BIG-IP 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 BIG-IP only invalidates requests where cart=add.
Cached content to invalidate
The BIG-IP 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 BIG-IP review the parameters set for the Cached Content to Invalidate setting. If a match occurs, the BIG-IP invalidates the content specified, and retrieves fresh content from the origin web server. The BIG-IP stores the fresh content in 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.