The database backend allows you to create a table in the database that can then be used to store and retrieve cached data. An advantage of using the database backend is that the cached data is persistently stored and is available even after a server reboot.

Before you can enable the database backend, you need to create a table in the database to store the cache using Python’s createcachetable application at the root of your project. The table can be given any valid table name as long as the database doesn’t already have a table with that name. For example, the following command creates a database backend table called mysitecache:

python manage.py createcachetable mysitecache

To enable the database backend in the settings.py file, set the CACHE_BACKEND to the db:// backend and provide the name of the cache table. For example, to enable the database backend using the table just listed, you would use the following setting:

CACHE_BACKEND = 'db://mysitecache'

The file system backend allows you to define a directory in which Django stores and retrieves cached data. An advantage of using the file system backend is that the cached data is stored persistently in the file system and is available even after a server reboot.

Before you can enable the file system backend, you need to create a directory in which to store the cached data.

To enable the file system backend in the settings.py file, you should set the CACHE_BACKEND to the file:// backend and provide the full path to the directory. For example, if you create a directory called /var/temp/mysitecache on a Linux system, you would use the following setting to the settings.py file:

CACHE_BACKEND = 'db:///mysitecache'

As another example, if you create a directory called c: empmysitecache on a Windows system, you would use the following setting to the settings.py file:

CACHE_BACKEND = 'db://c:/temp/mysitecache'

The local memory backend uses the system memory to store and retrieve cached data. An advantage of using the local memory backend is that the cached data is stored in memory, which is extremely quick to access. The local memory backend uses locking to ensure that it is multiprocess and thread-safe.

To enable the local memory backend in the settings.py file, set the CACHE_BACKEND to the locmem:/// backend:

CACHE_BACKEND = 'locmem:///'

The simple backend caches data in memory for a single process. This is useful when you are developing the website and for testing purposes. However, you should not use it in production.

To enable the simple backend in the settings.py file, set the CACHE_BACKEND to the simple:/// backend:

CACHE_BACKEND = 'simple:///'

The dummy backend does not cache any data, but it enables the cache interface. The dummy backend should be used only in development or test websites.

To enable the dummy backend in the settings.py file, set the CACHE_BACKEND to the dummy:/// backend:

CACHE_BACKEND = 'dummy:///'

The fastest and most efficient backend available for Django is the Memcached backend. It runs as a daemon that stores and retrieves data into a memory cache.

The Memcached backend is not distributed with Django; you must obtain it from www.django.com/memcached/. Before you can enable Memcached, you must install it, along with the Memcached Python bindings. The Memcached Python bindings are in the Python module, memcache.py, which you can find at www.djangoproject.com/thirdparty/python-memcached/.

To enable the Memcached backend in the settings.py file, you should set the CACHE_BACKEND to the memcached:// backend and provide the IP address and port that the Memcached daemon is running on. For example, if the Memcached daemon is running on the local host (127.0.0.1) using port 12221, you would use the following setting:

CACHE_BACKEND = 'memcached://127.0.0.1:12221'

One of the best features of Memcached is that you can distribute the cache over multiple servers by running the Memcached daemon on multiple machines. Memcached treats the servers as a single cache.

The Vary header allows you to define headers that an upstream cache engine checks when building its cache key. Then the cached page is used only if the values of headers in the Vary header of the request match those in the database.

The Vary header can be set in several different ways in the view function. The simplest way is to set the header manually in the HttpResponse object using the following syntax:

def myView(request):
    . . .
    response = HttpResponse()
    response['Vary'] = 'User-Agent'

Setting the Vary header manually in this way can potentially overwrite items that are already there. Django provides the django.views.decorators.vary.vary_on_headers() decorator function so that you can easily add headers to the Vary header for the view function.

The vary_on_headers() decorator function adds headers to the Vary header instead of overwriting headers that are already there. The vary_on_headers() decorator function can accept multiple headers as arguments. For example, the following code adds both the User-Agent and Content-Language headers to the Vary header:

from django.views.decorators import vary_on_headers
@vary_on_headers('User-Agent', 'Content-Language')
def myView(request):
    . . .

Another useful function to modify the Vary header is the django.utils.cache.patch_vary_headers(response, [headers]) function. The patch_vary_headers() function requires a response object as the first argument and a list of headers as the second. All headers listed in the second argument are added to the Vary header of the response object. For example, the following code adds the User-Agent and Content-Language headers to the Vary header inside the view function:

from django.utils.cache import patch_vary_headers
def myView(request):
    . . .
    response = HttpResponse()
    patch_vary_headers(response, ['User-Agent', 'Content-Language'])

One of the biggest advantages of using the patch_vary_headers() function is that you can selectively set which headers to add using code inside the view function. For example, you might want to add the Cookie header only if your view function actually sets a cookie.

One of the most common headers that you will want to add to the Vary header is the Cookie header. For that reason, Django has added the django.views.decorators.vary_on_cookie() decorator function to add just the Cookie header to the Vary header. The vary_on_cookie() decorator function does not accept any parameters and simply adds the Cookie header to Vary:

from django.views.decorators import vary_on_cookie
@vary_on_cookie
def myView(request):
    . . .

One of the biggest problems with caching is keeping data that should remain private, private. Users basically use two types of caches—the private cache stored in the user’s web browser, and the public cache stored by ISPs or other upstream caches. Private data, such as credit card numbers and account numbers, should only be stored in the private cache.

HTTP handles the issue of keeping data private using the Cache-Control header. The Cache-Control header allows you to define directives that caching engines will use to determine if data is public or private and if it should even be cached.

The following are the currently valid directives for the Cache-Control header:

Django provides the django.views.decorators.cache.cache_control() decorator function to configure the directives in the Cache-Control header. The cache_control() decorator function accepts any valid Cache-Control directive as an argument. For example, the following code sets the private and max_age directives in the Cache-Control header for a view function:

from django.views.decorators.cache import cache_control
@ cache_control(private=True, max_age=600)
def myView(request):
    . . .