TurboGears – Caching

In order to enhance the performance of a web application, especially if it is involved in lengthy operations, caching techniques are used. TurboGears provides two types of caching techniques −
Whole-page Caching

It works at the HTTP protocol level to avoid entire requests to the server by having either the user’s browser, or an intermediate proxy server (such as Squid) intercept the request and return a cached copy of the file.
Application-level Caching
This works within the application server to cache computed values, often the results of complex database queries, so that future requests can avoid needing to re-calculate the values. For web applications, application-level caching provides a flexible way to cache the results of complex queries so that the total load of a given controller method can be reduced to a few user-specific or case-specific queries and the rendering overhead of a template.

Application-level Caching

As mentioned earlier, ‘quickstarted’ TurboGears project is configured to enable Beaker package for caching support. Beaker supports the following back-ends used for cache storage −

• memory − Used for per-process storage. It is extremely fast.
• filesystem − per-process storage as well as multi-process.
• DBM database − per-process, multi-process, fairly fast.
• SQLAlchemy database − per-database-server storage. Slower compared to the above given options.
• Memcached − multi-server memory based cache.

Controller Caching

For quick controller caching, a cached() decorator is available. The entire controller body is cached depending on various parameters of request. The definition of tg.decorators.cached() decorator is as follows

tg.decorators.cached(key, expire, type, 
   query-args, cache_headers, invalidate_on_startup, cache_response)

The description of parameters is as follows −

S.No	Parameters & Description
1	key Specifies the controller parameters used to generate the cache key.
2	expire Time in seconds before cache expires, Defaults to “never”.
3	Type dbm, memory, file, memcached, or None.
4	cache_headers A tuple of header names indicating response headers.
5	invalidate_on_startup If True, cache is invalidated each time application starts or is restarted.
6	cache_response response should be cached or not, defaults to True.

Following is an example of controller caching −

@cached(expire = 100, type = 'memory')
@expose()
def simple(self):
   return "This is a cached controller!"

Template Level Caching

The Genshi template engine retrieves template from a cache if its contents have not changed. The default size of this cache is 25. By default, automatic reloading of templates is true. In order to improve performance, the following settings can be made in app_cfg.py −

[app:main]
genshi.max_cache_size = 100
auto_reload_templates = false

To cache a template, you just have to return the tg_cache option from the controller that renders the cached template.
The tg_cache is a dictionary that accepts the following keys −

• key − The cache key. Default: None.
• expire − how long the cache must stay alive. Default: never expires
• type − memory, dbm, memcached. Default: dbm.

The following example illustrates template caching −

@expose(hello.templates.user')
def user(self, username):
   return dict(user = username, tg_cache = dict(key = user, expire = 900))

---