http://docs.djangoproject.com/en/1.0/topics/cache/
Once you get really into the power of a framework like Django, you’ll start using it to add really cool features you would never have had the time for if you had to code them from scratch. Some of those really cool features will end up taking more time than your server can afford. Django also has a cacheing mechanism that you can use to cache expensive tasks. For example, looking at that custom autoLink filter, you might discover, after adding a thousand topics, that auto linking text takes too long.
When your tests show you that some feature is taking too much time and causing requests to queue on the server, you can either cache the entire page, or cache portions of the page.
If you want to use cacheing, the first thing you need to do is modify your settings.py file.
CACHE_BACKEND = 'file:///Users/jerry/Desktop/Django/Blog/cache?max_entries=500'
The “max_entries” value is the maximum number of caches Django will create before it starts throwing out entries. When that number of caches are created, Django will arbitrarily remove about a third of the caches.
Make sure that the folder you’re using exists; in this case, there needs to be a “cache” folder inside the Blog folder I’ve made for testing.
- Page cacheing
- The easiest way to set up cacheing is to just tell Django to cache every page. You can do this by adding a cacheing “middleware”. Look for MIDDLEWARE_CLASSES in settings.py. “Middleware” is a low-level “plugin” system for altering page requests; that includes things like providing a cached version of a page instead of recreating it for every request.
- Template tag cacheing
- Sometimes you don’t want to cache an entire page. You have a site where some things on the pages change every time the page is loaded. But you also don’t want to recreate expensive tasks that rarely change, such as the list of authors or topics. You can hook directly into the cacheing system using a template tag
- Custom cacheing
- The above two methods are very easy. They cache for a specific amount of time and then recreate the page or section on the next request after the cache expires. If the page doesn’t need recaching, Django still recaches it, and if the page does need recaching Django will still wait until the cache expires. That’s usually fine: you’ll set cache expiration to be some reasonable amount of time, and five or ten minutes here or there…
- When to worry about cacheing?
- Generally, you don’t want to go overboard when cacheing. Cacheing adds complexity, and you often don’t know where it’s needed. When you’ve finished adding a feature, you can test how long it takes using the {% now %} tag in your code and by calculating elapsed time inside of your Python code.
- Watching your cache
- Determining the right number of max_entries can be tricky. In this simple example, we know exactly how many entries we’ll be caching per post, but in a more complex setup we might only be able to guess. So it’s useful to watch the cache fill up, especially immediately before and after loading a page.
Related Pages
