========================

Django's cache framework

========================

A fundamental trade-off in dynamic Web sites is, well, they're dynamic. Each

time a user requests a page, the Web server makes all sorts of calculations --

from database queries to template rendering to business logic -- to create the

page that your site's visitor sees. This is a lot more expensive, from a

processing-overhead perspective, than your standard

read-a-file-off-the-filesystem server arrangement.

For most Web applications, this overhead isn't a big deal. Most Web

applications aren't washingtonpost.com or slashdot.org; they're simply small-

to medium-sized sites with so-so traffic. But for medium- to high-traffic

sites, it's essential to cut as much overhead as possible.

That's where caching comes in.

To cache something is to save the result of an expensive calculation so that

you don't have to perform the calculation next time. Here's some pseudocode

explaining how this would work for a dynamically generated Web page::

    given a URL, try finding that page in the cache

    if the page is in the cache:

        return the cached page

    else:

        generate the page

        save the generated page in the cache (for next time)

        return the generated page

Django comes with a robust cache system that lets you save dynamic pages so

they don't have to be calculated for each request. For convenience, Django

offers different levels of cache granularity: You can cache the output of

specific views, you can cache only the pieces that are difficult to produce, or

you can cache your entire site.

Django also works well with "upstream" caches, such as `Squid

<http://www.squid-cache.org>`_ and browser-based caches. These are the types of

caches that you don't directly control but to which you can provide hints (via

HTTP headers) about which parts of your site should be cached, and how.

Setting up the cache

====================

The cache system requires a small amount of setup. Namely, you have to tell it

where your cached data should live -- whether in a database, on the filesystem

or directly in memory. This is an important decision that affects your cache's

performance; yes, some cache types are faster than others.

Your cache preference goes in the ``CACHE_BACKEND`` setting in your settings

file. Here's an explanation of all available values for ``CACHE_BACKEND``.

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.com and subsequently open-sourced by Danga Interactive.

It's used by sites such as Facebook and Wikipedia to reduce database access and

dramatically increase site performance.

Memcached is available for free at http://memcached.org/. It runs as a

daemon and is allotted a specified amount of RAM. All it does is provide a

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

``python-memcached``, which provides Python bindings to Memcached.

This is available at ftp://ftp.tummy.com/pub/python-memcached/

.. versionchanged:: 1.2

    In Django 1.0 and 1.1, you could also use ``cmemcache`` as a binding.

    However, support for this library was deprecated in 1.2 due to

    a lack of maintenance on the ``cmemcache`` library itself. Support for

    ``cmemcache`` will be removed completely in Django 1.4.

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,

include all server addresses in ``CACHE_BACKEND``, separated by semicolons.

In this example, the cache is shared over Memcached instances running on IP

address 172.19.26.240 and 172.19.26.242, both 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

disadvantage: Because the cached data is stored 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 backends 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 backend, first create a cache table in

your database 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 that 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 backend uses the same database as specified in your

settings file. You can't use a different database backend for your cache table.

Database caching works best if you've got a fast, well-indexed database server.

Database caching and multiple databases

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you use database caching with multiple databases, you'll also need

to set up routing instructions for your database cache table. For the

purposes of routing, the database cache table appears as a model named

``CacheEntry``, in an application named ``django_cache``. This model

won't appear in the models cache, but the model details can be used

for routing purposes.

For example, the following router would direct all cache read

operations to ``cache_slave``, and all write operations to

``cache_master``. The cache table will only be synchronized onto

``cache_master``::

    class CacheRouter(object):

        """A router to control all database cache operations"""

        def db_for_read(self, model, **hints):

            "All cache read operations go to the slave"

            if model._meta.app_label in ('django_cache',):

                return 'cache_slave'

            return None

        def db_for_write(self, model, **hints):

            "All cache write operations go to master"

            if model._meta.app_label in ('django_cache',):

                return 'cache_master'

            return None

        def allow_syncdb(self, db, model):

            "Only synchronize the cache model on master"

            if model._meta.app_label in ('django_cache',):

                return db == 'cache_master'

            return None

If you don't specify routing directions for the database cache model,

the cache backend will use the ``default`` database.

Of course, if you don't use the database cache backend, you don't need

to worry about providing routing instructions for the database cache

model.

Filesystem caching

------------------

To store cached items on a filesystem, use the ``"file://"`` cache type for

``CACHE_BACKEND``. 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 that 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 this::

    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

above 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 backend. This

cache is multi-process and thread-safe. To use it, set ``CACHE_BACKEND`` to

``"locmem://"``. For example::

    CACHE_BACKEND = 'locmem://'

Note that each process will have its own private cache instance, which means no

cross-process caching is possible. This obviously also means the local memory

cache isn't particularly memory-efficient, so it's probably not a good choice

for production environments. It's nice for development.

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 but a development/test environment where you don't want to cache

and don't want to have to change your code to special-case the latter. To

activate dummy caching, set ``CACHE_BACKEND`` like so::

    CACHE_BACKEND = 'dummy://'

Using a custom cache backend

----------------------------

.. versionadded:: 1.0

While Django includes support for a number of cache backends out-of-the-box,

sometimes you might want to use a customized cache backend. To use an external

cache backend with Django, use a Python import path as the scheme portion (the

part before the initial colon) of the ``CACHE_BACKEND`` URI, like so::

    CACHE_BACKEND = 'path.to.backend://'

If you're building your own backend, you can use the standard cache backends

as reference implementations. You'll find the code in the

``django/core/cache/backends/`` directory of the Django source.

Note: Without a really compelling reason, such as a host that doesn't support

them, you should stick to the cache backends included with Django. They've

been well-tested and are easy to use.

CACHE_BACKEND arguments

-----------------------

Each cache backend 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 ``locmem``, ``filesystem`` and ``database``

      backends, the maximum number of entries allowed in the cache before old

      values are deleted. This argument defaults to 300.

    * ``cull_frequency``: The fraction 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.

In this example, ``timeout`` is set to ``60``::

    CACHE_BACKEND = "memcached://127.0.0.1:11211/?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.

The per-site cache

==================

.. versionchanged:: 1.0

    (previous versions of Django only provided a single ``CacheMiddleware`` instead

    of the two pieces described below).

Once the cache is set up, the simplest way to use caching is to cache your

entire site. You'll need to add

``'django.middleware.cache.UpdateCacheMiddleware'`` and

``'django.middleware.cache.FetchFromCacheMiddleware'`` to your

``MIDDLEWARE_CLASSES`` setting, as in this example::

    MIDDLEWARE_CLASSES = (

        'django.middleware.cache.UpdateCacheMiddleware',

        'django.middleware.common.CommonMiddleware',

        'django.middleware.cache.FetchFromCacheMiddleware',

    )

.. note::

    No, that's not a typo: the "update" middleware must be first in the list,

    and the "fetch" middleware must be last. The details are a bit obscure, but

    see `Order of MIDDLEWARE_CLASSES`_ below if you'd like the full story.

Then, add the following required settings to your Django settings file:

* ``CACHE_MIDDLEWARE_SECONDS`` -- The number of seconds each page should be

  cached.

* ``CACHE_MIDDLEWARE_KEY_PREFIX`` -- If the cache is shared across multiple

  sites using the same Django installation, set this to the name of the site,

  or some other string that is unique to this Django instance, to prevent key

  collisions. Use an empty string if you don't care.

The cache middleware caches every page that doesn't have GET or POST

parameters. Optionally, if the ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting is

``True``, only anonymous requests (i.e., not those made by a logged-in user)

will be cached. This is a simple and effective way of disabling caching for any

user-specific pages (include Django's admin interface). Note that if you use

``CACHE_MIDDLEWARE_ANONYMOUS_ONLY``, you should make sure you've activated

``AuthenticationMiddleware``.

Additionally, the cache middleware automatically sets a few headers in each

:class:`~django.http.HttpResponse`:

    * Sets the ``Last-Modified`` header to the current date/time when a fresh

      (uncached) version of the page is requested.

    * Sets the ``Expires`` header to the current date/time plus the defined

      ``CACHE_MIDDLEWARE_SECONDS``.

    * Sets the ``Cache-Control`` header to give a max age for the page --

      again, from the ``CACHE_MIDDLEWARE_SECONDS`` setting.

See :doc:`/topics/http/middleware` for more on middleware.

.. versionadded:: 1.0

If a view sets its own cache expiry time (i.e. it has a ``max-age`` section in

its ``Cache-Control`` header) then the page will be cached until the expiry

time, rather than ``CACHE_MIDDLEWARE_SECONDS``. Using the decorators in

``django.views.decorators.cache`` you can easily set a view's expiry time

(using the ``cache_control`` decorator) or disable caching for a view (using

the ``never_cache`` decorator). See the `using other headers`__ section for

more on these decorators.

.. _i18n-cache-key:

.. versionadded:: 1.2

If :setting:`USE_I18N` is set to ``True`` then the generated cache key will

include the name of the active :term:`language<language code>`.

This allows you to easily cache multilingual sites without having to create

the cache key yourself.

See :doc:`/topics/i18n/deployment` for more on how Django discovers the active

language.

__ `Controlling cache: Using other headers`_

The per-view cache

==================

A more granular way to use the caching framework is by caching the output of

individual views. ``django.views.decorators.cache`` defines a ``cache_page``

decorator that will automatically cache the view's response for you. It's easy

to use::

    from django.views.decorators.cache import cache_page

    @cache_page(60 * 15)

    def my_view(request):

        ...

``cache_page`` takes a single argument: the cache timeout, in seconds. In the

above example, the result of the ``my_view()`` view will be cached for 15

minutes. (Note that we've written it as ``60 * 15`` for the purpose of

readability. ``60 * 15`` will be evaluated to ``900`` -- that is, 15 minutes

multiplied by 60 seconds per minute.)

The per-view cache, like the per-site cache, is keyed off of the URL. If

multiple URLs point at the same view, each URL will be cached separately.

Continuing the ``my_view`` example, if your URLconf looks like this::

    urlpatterns = ('',

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

    )

then requests to ``/foo/1/`` and ``/foo/23/`` will be cached separately, as

you may expect. But once a particular URL (e.g., ``/foo/23/``) has been

requested, subsequent requests to that URL will use the cache.

``cache_page`` can also take an optional keyword argument, ``key_prefix``, which

works in the same way as the ``CACHE_MIDDLEWARE_KEY_PREFIX`` setting for the

middleware.  It can be used like this::

    @cache_page(60 * 15, key_prefix="site1")

    def my_view(request):

        ...

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,

cache-less 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.

Template fragment caching

=========================

.. versionadded:: 1.0

If you're after even more control, you can also cache template fragments using

the ``cache`` template tag. To give your template access to this tag, put

``{% load cache %}`` near the top of your template.

The ``{% cache %}`` template tag caches the contents of the block for a given

amount of time. It takes at least two arguments: the cache timeout, in seconds,

and the name to give the cache fragment. For example:

.. code-block:: html+django

    {% load cache %}

    {% cache 500 sidebar %}

        .. sidebar ..

    {% endcache %}

Sometimes you might want to cache multiple copies of a fragment depending on

some dynamic data that appears inside the fragment. For example, you might want a

separate cached copy of the sidebar used in the previous example for every user

of your site. Do this by passing additional arguments to the ``{% cache %}``

template tag to uniquely identify the cache fragment:

.. code-block:: html+django

    {% load cache %}

    {% cache 500 sidebar request.user.username %}

        .. sidebar for logged in user ..

    {% endcache %}

It's perfectly fine to specify more than one argument to identify the fragment.

Simply pass as many arguments to ``{% cache %}`` as you need.

If :setting:`USE_I18N` is set to ``True`` the per-site middleware cache will

:ref:`respect the active language<i18n-cache-key>`. For the ``cache`` template

tag you could use one of the

:ref:`translation-specific variables<template-translation-vars>` available in

templates to archieve the same result:

.. code-block:: html+django

    {% load i18n %}

    {% load cache %}

    {% get_current_language as LANGUAGE_CODE %}

    {% cache 600 welcome LANGUAGE_CODE %}

        {% trans "Welcome to example.com" %}

    {% endcache %}

The cache timeout can be a template variable, as long as the template variable

resolves to an integer value. For example, if the template variable

``my_timeout`` is set to the value ``600``, then the following two examples are

equivalent:

.. code-block:: html+django

    {% cache 600 sidebar %} ... {% endcache %}

    {% cache my_timeout sidebar %} ... {% endcache %}

This feature is useful in avoiding repetition in templates. You can set the

timeout in a variable, in one place, and just reuse that value.

The low-level cache API

=======================

.. highlight:: python

Sometimes, caching an entire rendered page doesn't gain you very much and is,

in fact, inconvenient overkill.

Perhaps, for instance, your site includes a view whose results depend on

several expensive queries, the results of which change at different intervals.

In this case, it would not be ideal to use the full-page caching that the

per-site or per-view cache strategies offer, because you wouldn't want to

cache the entire result (since some of the data changes often), but you'd still

want to cache the results that rarely change.

For cases like this, Django exposes a simple, low-level cache API. You can use

this API to store objects in the cache with any level of granularity you like.

You can cache any Python object that can be pickled safely: strings,

dictionaries, lists of model objects, and so forth. (Most common Python objects

can be pickled; refer to the Python documentation for more information about

pickling.)

The cache module, ``django.core.cache``, has a ``cache`` object that's