Archive for November, 2008

Notes on Django caching

November 27, 2008

I’ve spent the last few weeks playing around with django-page-cms. It’s going well so far. But I am having an issue with some customisations I made and the caching that is used. So here my notes so far on the subject. These are really for my own reference, but I thought others might find them helpful. The Django Project documentation describes the caching in detail as well.

Activating caching

You can turn on caching by using CACHE_BACKEND in the settings file.

Types of caching

There are five types of caching that come with Django:

1. Memcached

This uses the Memchached caching framework and is entirely memory based. Memcached can be downloaded from here: http://danga.com/memcached/. Memchached needs to be installed separately.

2. Database

This uses your database for caching. You need to create a table in your database using this command:

python manage.py createcachetable [cache_table_name]

and then use this setting:

CACHE_BACKEND = 'db://my_cache_table'

3. Filesystem chaching

This uses the file system for caching. You can set it up using the following setting:

CACHE_BACKEND = 'file:///var/tmp/django_cache'

Note: you need the three forward slashes after file and your webserver needs read/write access to the directory listed.

4. Local-memory caching

This provides the speed of memory caching if you don’t have the capability for running Memcached. It is multi-process and thread safe. However since each process therefore has it’s own chache, it is not bery memory efficient and best used in development environement only. Set it up like this:

CACHE_BACKEND = 'locmem:///'

5. Dummy caching

Used for development purposes to simulate caching, but without actually using a cache. Set it up like this:

CACHE_BACKEND = 'dummy:///'

You can also create your own custom chache mechanism if you wish.

CACHE_BACKEND arguments

There are three arguments:

  1. timeout: how long to chache the info for
  2. max_entries: maximum number of items to cache
  3. cull_percentage: what percentage to cull when max_entries is reached. eg: 3 means 1/3

Choosing what to cache

Caching a whole site

This can be done with middleware. See the docs for more info.

The per-view cach

This lets you cache the output of specific views. This is easy to setup:

@cache_page(60 * 15)
from django.views.decorators.cache import cache_page

def slashdot_this(request):

Template fragment caching

This lets you cache blocks within a template. You can do this using the following code:

{% load cache %}
{% cache 500 sidebar request.user.username %}
    .. sidebar for logged in user ..
{% endcache %}

{% load %} is the Django mechanism for loading custom tag libraries/
{% cache 500 sidebar request.user.username%} .. {% endcache %} defines the block to be cached. 500 is the length of the cache in seconds and any following items make up the key for the cache.

API caching

This lets you cache items programmatically. The core functions are:

cache.set('my_key', 'hello, world!', 30)
cache.get('my_key')

where my_key is the key for the item in the cache, ‘hello world!’ is the content being cached and 30 is the number of seconds to cache it for.

Further information on caching

You can also vary your cache depending on the request headers or use the cache_control decorator to control how private data is handled, whether to check for new versions and how many times a page can be chached.

There’s a Django app for everything!

November 8, 2008

I haven’t written anything in quite a while as I’ve been too busy hacking out annoying ASP.Net code in my working life.   That doesn’t mean I haven’t been reading up on Django, especially looking into what apps have already been written for Django.  And I am quite amazed. I am sure I can “cobble” together a professional, industrial strength web based CMS through the use various Django apps without really having to learn how to program python, beyond understanding the syntax that is.

My ultimate aim is to create an app that helps people write clear, meaningful, accessible content that is semantically marked up. However I have decided to first just get a basic CMS up and running with which I can manage a couple of my own personal sites.  I am hoping this will give me a deeper understanding of Django. The target audience for my CMS are people wanting to create small websites with maybe upto two dozen pages on them. What I want is the following:

  • Basic admin features. Three levels:
    1. Admin: complete control over website
    2. Editor: can add/remove pages and modify content
    3. Author: can only write content
  • Standard site administration enbaling the creation and editing of pages
  • Complete version history
  • Some form of tagging. Not sure exactly how this will be used, but I would like to be able to tag content
  • Some kind of multilingual functionality. Not sure yet how this should look, but it is anyway low priority.
  • Some way of managing more than one site from the same install

Well, there seems to be a Django app for each of these:

This post is my “back of the envelope” sketch. There’s lots of interesting tools and apps listed here. Now I need to figure out how to combine them into something meaningful.