The Django Book

Memcached

By far the fastest, most efficient type of cache available to Django, Memcached is an entirely memory-based cache framework originally developed to handle high loads at LiveJournal (http://www.livejournal.com/) and subsequently open-sourced by Danga Interactive (http://danga.com/). It’s used by sites such as Slashdot and Wikipedia to reduce database access and dramatically increase site performance.

Memcached is available for free at http://danga.com/memcached/. It runs as a daemon and is allotted a specified amount of RAM. Its primary feature is to provide an interface—a super-lightning-fast interface—for adding, retrieving, and deleting arbitrary data in the cache. All data is stored directly in memory, so there’s no overhead of database or filesystem usage.

After installing Memcached itself, you’ll need to install the Memcached Python bindings, which are not bundled with Django directly. These bindings are in a single Python module, memcache.py, which is available at http://www.tummy.com/Community/software/python-memcached/.

To use Memcached with Django, set CACHE_BACKEND to memcached://ip:port/, where ip is the IP address of the Memcached daemon and port is the port on which Memcached is running.

In this example, Memcached is running on localhost (127.0.0.1) port 11211:

CACHE_BACKEND = 'memcached://127.0.0.1:11211/'

One excellent feature of Memcached is its ability to share cache over multiple servers. This means you can run Memcached daemons on multiple machines, and the program will treat the group of machines as a single cache, without the need to duplicate cache values on each machine. To take advantage of this feature with Django, include all server addresses in CACHE_BACKEND, separated by semicolons.

In this example, the cache is shared over Memcached instances running on the IP addresses 172.19.26.240 and 172.19.26.242, both of which are on port 11211:

CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11211/'

In the following example, the cache is shared over Memcached instances running on the IP addresses 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and 172.19.26.244 (port 11213):

CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11212;172.19.26.244:11213/'

A final point about Memcached is that memory-based caching has one important disadvantage. Because the cached data is stored only in memory, the data will be lost if your server crashes. Clearly, memory isn’t intended for permanent data storage, so don’t rely on memory-based caching as your only data storage. Without a doubt, none of the Django caching back-ends should be used for permanent storage—they’re all intended to be solutions for caching, not storage—but we point this out here because memory-based caching is particularly temporary.

Database Caching

To use a database table as your cache back-end, create a cache table in your database and point Django’s cache system at that table.

First, create a cache table by running this command:

python manage.py createcachetable [cache_table_name]

where [cache_table_name] is the name of the database table to create. This name can be whatever you want, as long as it’s a valid table name that’s not already being used in your database. This command creates a single table in your database that is in the proper format Django’s database-cache system expects.

Once you’ve created that database table, set your CACHE_BACKEND setting to "db://tablename", where tablename is the name of the database table. In this example, the cache table’s name is my_cache_table:

CACHE_BACKEND = 'db://my_cache_table'

The database caching back-end uses the same database as specified in your settings file. You can’t use a different database back-end for your cache table.

Filesystem Caching

To store cached items on a filesystem, use the "file://" cache type for CACHE_BACKEND, specifying the directory on your filesystem that should store the cached data.

For example, to store cached data in /var/tmp/django_cache, use this setting:

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

Note that there are three forward slashes toward the beginning of the preceding example. The first two are for file://, and the third is the first character of the directory path, /var/tmp/django_cache. If you’re on Windows, put the drive letter after the file://, like so:: file://c:/foo/bar.

The directory path should be absolute—that is, it should start at the root of your filesystem. It doesn’t matter whether you put a slash at the end of the setting.

Make sure the directory pointed to by this setting exists and is readable and writable by the system user under which your Web server runs. Continuing the preceding example, if your server runs as the user apache, make sure the directory /var/tmp/django_cache exists and is readable and writable by the user apache.

Each cache value will be stored as a separate file whose contents are the cache data saved in a serialized (“pickled”) format, using Python’s pickle module. Each file’s name is the cache key, escaped for safe filesystem use.

Local-Memory Caching

If you want the speed advantages of in-memory caching but don’t have the capability of running Memcached, consider the local-memory cache back-end. This cache is per-process and thread-safe, but it isn’t as efficient as Memcached due to its simplistic locking and memory allocation strategies.

To use it, set CACHE_BACKEND to 'locmem:///', for example:

CACHE_BACKEND = 'locmem:///'

Simple Caching (for Development)

A simple, single-process memory cache is available as 'simple:///', for example:

CACHE_BACKEND = 'simple:///'

This cache merely saves cached data in process, which means it should be used only in development or testing environments.

Dummy Caching (for Development)

Finally, Django comes with a “dummy” cache that doesn’t actually cache; it just implements the cache interface without doing anything.

This is useful if you have a production site that uses heavy-duty caching in various places and a development/test environment on which you don’t want to cache. In that case, set CACHE_BACKEND to 'dummy:///' in the settings file for your development environment, for example:

CACHE_BACKEND = 'dummy:///'

As a result, your development environment won’t use caching, but your production environment still will.

CACHE_BACKEND Arguments

Each cache back-end may take arguments. They’re given in query-string style on the CACHE_BACKEND setting. Valid arguments are as follows:

• timeout: The default timeout, in seconds, to use for the cache. This argument defaults to 300 seconds (5 minutes).

• max_entries: For the simple, local-memory, and database back-ends, the maximum number of entries allowed in the cache before old values are deleted. This argument defaults to 300.

• cull_frequency: The ratio of entries that are culled when max_entries is reached. The actual ratio is 1/cull_frequency, so set cull_frequency=2 to cull half of the entries when max_entries is reached.

  A value of 0 for cull_frequency means that the entire cache will be dumped when max_entries is reached. This makes culling much faster at the expense of more cache misses. This argument defaults to 3.

In this example, timeout is set to 60:

CACHE_BACKEND = "locmem:///?timeout=60"

In this example, timeout is 30 and max_entries is 400:

CACHE_BACKEND = "locmem:///?timeout=30&max_entries=400"

Invalid arguments are silently ignored, as are invalid values of known arguments.

Specifying Per-View Cache in the URLconf

The examples in the previous section have hard-coded the fact that the view is cached, because cache_page alters the my_view function in place. This approach couples your view to the cache system, which is not ideal for several reasons. For instance, you might want to reuse the view functions on another, cacheless site, or you might want to distribute the views to people who might want to use them without being cached. The solution to these problems is to specify the per-view cache in the URLconf rather than next to the view functions themselves.

Doing so is easy: simply wrap the view function with cache_page when you refer to it in the URLconf. Here’s the old URLconf from earlier:

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', my_view),
)

Here’s the same thing, with my_view wrapped in cache_page:

from django.views.decorators.cache import cache_page

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', cache_page(my_view, 60 * 15)),
)

If you take this approach, don’t forget to import cache_page within your URLconf.

Using Vary Headers

The Vary header defines which request headers a cache mechanism should take into account when building its cache key. For example, if the contents of a Web page depend on a user’s language preference, the page is said to “vary on language.”

By default, Django’s cache system creates its cache keys using the requested path (e.g., "/stories/2005/jun/23/bank_robbed/"). This means every request to that URL will use the same cached version, regardless of user-agent differences such as cookies or language preferences. However, if this page produces different content based on some difference in request headers—such as a cookie, or a language, or a user-agent—you’ll need to use the Vary header to tell caching mechanisms that the page output depends on those things.

To do this in Django, use the convenient vary_on_headers view decorator, like so:

from django.views.decorators.vary import vary_on_headers

# Python 2.3 syntax.
def my_view(request):
    # ...
my_view = vary_on_headers(my_view, 'User-Agent')

# Python 2.4+ decorator syntax.
@vary_on_headers('User-Agent')
def my_view(request):
    # ...

In this case, a caching mechanism (such as Django’s own cache middleware) will cache a separate version of the page for each unique user-agent.

The advantage to using the vary_on_headers decorator rather than manually setting the Vary header (using something like response['Vary'] = 'user-agent') is that the decorator adds to the Vary header (which may already exist), rather than setting it from scratch and potentially overriding anything that was already in there.

You can pass multiple headers to vary_on_headers():

@vary_on_headers('User-Agent', 'Cookie')
def my_view(request):
    # ...

This tells upstream caches to vary on both, which means each combination of user-agent and cookie will get its own cache value. For example, a request with the user-agent Mozilla and the cookie value foo=bar will be considered different from a request with the user-agent Mozilla and the cookie value foo=ham.

Because varying on cookie is so common, there’s a vary_on_cookie decorator. These two views are equivalent:

@vary_on_cookie
def my_view(request):
    # ...

@vary_on_headers('Cookie')
def my_view(request):
    # ...

The headers you pass to vary_on_headers are not case sensitive; "User-Agent" is the same thing as "user-agent".

You can also use a helper function, django.utils.cache.patch_vary_headers, directly. This function sets, or adds to, the Vary header, for example:

from django.utils.cache import patch_vary_headers

def my_view(request):
    # ...
    response = render_to_response('template_name', context)
    patch_vary_headers(response, ['Cookie'])
    return response

patch_vary_headers takes an HttpResponse instance as its first argument and a list/tuple of case-insensitive header names as its second argument.

Other Cache Headers

Other problems with caching are the privacy of data and the question of where data should be stored in a cascade of caches.

A user usually faces two kinds of caches: his or her own browser cache (a private cache) and his or her provider’s cache (a public cache). A public cache is used by multiple users and controlled by someone else. This poses problems with sensitive data—you don’t want, say, your bank account number stored in a public cache. So Web applications need a way to tell caches which data is private and which is public.

The solution is to indicate a page’s cache should be “private.” To do this in Django, use the cache_control view decorator:

from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request):
    # ...

This decorator takes care of sending out the appropriate HTTP header behind the scenes.

There are a few other ways to control cache parameters. For example, HTTP allows applications to do the following:

• Define the maximum time a page should be cached.
• Specify whether a cache should always check for newer versions, only delivering the cached content when there are no changes. (Some caches might deliver cached content even if the server page changed, simply because the cache copy isn’t yet expired.)

In Django, use the cache_control view decorator to specify these cache parameters. In this example, cache_control tells caches to revalidate the cache on every access and to store cached versions for, at most, 3,600 seconds:

from django.views.decorators.cache import cache_control
@cache_control(must_revalidate=True, max_age=3600)
def my_view(request):
    ...

Any valid Cache-Control HTTP directive is valid in cache_control(). Here’s a full list:

• public=True
• private=True
• no_cache=True
• no_transform=True
• must_revalidate=True
• proxy_revalidate=True
• max_age=num_seconds
• s_maxage=num_seconds