How to invalidate cached items in Stingray's Content Cache (09/19/2006)
When several client request the same web page, Stingray does not have to query the back-end origin server every time. Instead, you can use Stingray's content caching capability to remember common web page responses; this reduces the load on your origin servers, improves total Stingray throughput and ensures that clients receive web pages more quickly.
Web page responses are cached for 10 minutes, which is a sensible value if the page does not change often. In some circumstances, you may want to remove a page (or set of pages) from the Stingray cache, for example, if you've just updated the content. This article describes a range of techniques to do this.
The default cache time of 10 minutes is probably sufficient for the large majority of cachable content. You can change the cache time to a different value by editing the Content Caching settings of the Virtual Server. You may want to specify different cache times for different types of content. For example, the vast majority of your content may be cachable for 10 minutes, but some pages should only be cached for 5 seconds.
Stingray conforms accurately with the Cache recommendations of RFC 2616 (section 14.9) , so you can control its behaviour by modifying request and response headers as appropriate. The following TrafficScript response rule will set the cache time for certain URLs to 5 seconds:
You can completely clear the Stingray content cache using the Administration Server, or remotely via the Stingray Control API: In the Administration Server, go to the Activity > Content Cache page and use the Clear Content Cache button to clear the content cache on all Stingrays in your cluster. With the Stingray Control API, use the System.Cache.clearWebCache() SOAP method to clear the content cache on the local Stingray. The code sample Clearing the Stingray Content Cachedescribes how to do this using Perl; other languages are also supported.
Ways to invalidate cached items
Remote HTTP requests
If you want Stingray to invalidate its cache of a particular item, add the following HTTP header to a request for the item:
Stingray will bypass its cached version of the resource and retrieve a new version from the origin server. This new version will normally be cached, so subsequent requests will receive the new version from the Stingray cache. You can manually issue such a request using the 'httpclient' command-line application included with SXTM, in ZEUSHOME/admin/bin:
Using 'shift-reload' in Firefox or 'control-F5' in MSIE also causes these browers to add the 'no-cache' header to the request, and invalidates the cache for all users. Note that this technique will not work reliably on multi-processor systems - see the note at the end of this article.
The following TrafficScript rule reads a list of URLs from a resource file, and invalidates each URL:
You will need to put the list of urls in a file named 'refreshurls', in the ZEUSHOME/zxtm/conf/extra directory:
When you update the file, Stingray will notice that it has changed and reload it. When the TrafficScript rule runs, it will detect that the file has changed, update the internal table of URLs and invalidate all URLs in the table when corresponding requests are received. The impact of this is minimal. Stingray caches the file contents and modification times, and the TrafficScript rule will have a very minor effect on the performance of the system.
You can remotely control the list of URLs using the Control API Conf.Extra.addFile() and getFile() functions, or simply by scp'ing the list to the correct location on the Stingray systems. Each time the file is updated, all of the URLs listed in it will be invalidated when a corresponding request is received.
(Originally posted by Owen Garrett, Updated by Paul Wallace on 31st January 2014)