Products.TemplateCacheManager 0.1dev-r67816

Introduction

TemplateCacheManager is designed to speed up access to content views while at the same time making sure that stale content is not served up. TemplateCacheManager is derived from PageCacheManager.

Differences beetween TemplateCacheManager and PageCacheManager

TemplateCacheManager

• is independent of the CacheSetup product.

• returns also the ETag to the clients, supports therefore cascading and and multiple ETag caching. Client, Proxy (e.g. Squid) and TemplateCacheManager can therefore cache individual views of content including header information.

• generates statistic reports

Installation

TemplateCacheManager is designed specifically for caching views of content objects. Unlike RAMCacheManager, TemplateCacheManager caches both the html generated by a view as well as the HTTP headers.

TemplateCacheManager builds upon Zope’s standard cache manager machinery. As with RAMCacheManager, you associate some page templates with the cache manager and configure the properties. TemplateCacheManager requires an extra step: content to be cached must generate an ETag via a caching policy. TemplateCacheManager looks for a CachingPolicyManager with id caching_policy_manager. If it finds it, it then gets an ETag for the current template + content object combination. This ETag is then used as the index into the cache. If you don’t have an ETag generated for your content, your pages will not be cached.

If you create an ETag that changes when the content is changed, then the content served up by the cache will stay fresh. There will be a cache miss the first time the page is hit after the ETag changes, then subsequent hits to the newly modified content view will reflect the new version. If your content view is personalized, you will want your ETag to vary depending on the current user. A good ETag with these properties is as follows (s. INSTALL.txt in examples directory):

ETag = id of currently authenticated user + delimiter + last modified time

for content + delimiter + current time rounded to the nearest hour

The use of the id in the ETag means that every user’s view of a content object will have a different ETag, so everybody will get different cached objects. The use of the modification time means that every time the content object changes, it will generate different ETags and hence will result in new copies being pulled from the cache. The use of the current time rounded to the nearest hour means that nothing will be served up by the cache for more than an hour.

Added bonus:

TemplateCacheManager handles conditional GETs be configured by CachingPolicyManager. If the incoming request has an If-None-Match header with an ETag that matches the content object’s current ETag, TemplateCacheManager will set a status 304 header (Not Modified) and will only return the matching ETag instead of the content. This feature is needed if you are using a proxy with ETag support (e.g. squid), which can cache and handle multiple views of content indexed by ETag and Vary header.

Information about ETags

Basic info:

http://devel.squid-cache.org/etag/etag-header.html

Multiple ETag bug of squid 2.x (patch included):

http://www.squid-cache.org/bugs/show_bug.cgi?id=2112 http://www.squid-cache.org/bugs/attachment.cgi?id=1504