1 ========================

     2 Django's cache framework

     3 ========================

     4 

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

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

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

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

     9 processing-overhead perspective, than your standard

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

    11 

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

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

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

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

    16 

    17 That's where caching comes in.

    18 

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

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

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

    22 

    23     given a URL, try finding that page in the cache

    24     if the page is in the cache:

    25         return the cached page

    26     else:

    27         generate the page

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

    29         return the generated page

    30 

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

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

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

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

    35 you can cache your entire site.

    36 

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

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

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

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

    41 

    42 Setting up the cache

    43 ====================

    44 

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

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

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

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

    49 

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

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

    52 

    53 Memcached

    54 ---------

    55 

    56 By far the fastest, most efficient type of cache available to Django, Memcached

    57 is an entirely memory-based cache framework originally developed to handle high

    58 loads at LiveJournal.com and subsequently open-sourced by Danga Interactive.

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

    60 dramatically increase site performance.

    61 

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

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

    64 fast interface for adding, retrieving and deleting arbitrary data in the cache.

    65 All data is stored directly in memory, so there's no overhead of database or

    66 filesystem usage.

    67 

    68 After installing Memcached itself, you'll need to install

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

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

    71 

    72 .. versionchanged:: 1.2

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

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

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

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

    77 

    78 To use Memcached with Django, set ``CACHE_BACKEND`` to

    79 ``memcached://ip:port/``, where ``ip`` is the IP address of the Memcached

    80 daemon and ``port`` is the port on which Memcached is running.

    81 

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

    83 

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

    85 

    86 One excellent feature of Memcached is its ability to share cache over multiple

    87 servers. This means you can run Memcached daemons on multiple machines, and the

    88 program will treat the group of machines as a *single* cache, without the need

    89 to duplicate cache values on each machine. To take advantage of this feature,

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

    91 

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

    93 address 172.19.26.240 and 172.19.26.242, both on port 11211::

    94 

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

    96 

    97 In the following example, the cache is shared over Memcached instances running

    98 on the IP addresses 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and

    99 172.19.26.244 (port 11213)::

   100 

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

   102 

   103 A final point about Memcached is that memory-based caching has one

   104 disadvantage: Because the cached data is stored in memory, the data will be

   105 lost if your server crashes. Clearly, memory isn't intended for permanent data

   106 storage, so don't rely on memory-based caching as your only data storage.

   107 Without a doubt, *none* of the Django caching backends should be used for

   108 permanent storage -- they're all intended to be solutions for caching, not

   109 storage -- but we point this out here because memory-based caching is

   110 particularly temporary.

   111 

   112 Database caching

   113 ----------------

   114 

   115 To use a database table as your cache backend, first create a cache table in

   116 your database by running this command::

   117 

   118     python manage.py createcachetable [cache_table_name]

   119 

   120 ...where ``[cache_table_name]`` is the name of the database table to create.

   121 (This name can be whatever you want, as long as it's a valid table name that's

   122 not already being used in your database.) This command creates a single table

   123 in your database that is in the proper format that Django's database-cache

   124 system expects.

   125 

   126 Once you've created that database table, set your ``CACHE_BACKEND`` setting to

   127 ``"db://tablename"``, where ``tablename`` is the name of the database table.

   128 In this example, the cache table's name is ``my_cache_table``::

   129 

   130     CACHE_BACKEND = 'db://my_cache_table'

   131 

   132 The database caching backend uses the same database as specified in your

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

   134 

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

   136 

   137 Database caching and multiple databases

   138 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   139 

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

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

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

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

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

   145 for routing purposes.

   146 

   147 For example, the following router would direct all cache read

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

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

   150 ``cache_master``::

   151 

   152     class CacheRouter(object):

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

   154 

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

   156             "All cache read operations go to the slave"

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

   158                 return 'cache_slave'

   159             return None

   160 

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

   162             "All cache write operations go to master"

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

   164                 return 'cache_master'

   165             return None

   166 

   167         def allow_syncdb(self, db, model):

   168             "Only synchronize the cache model on master"

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

   170                 return db == 'cache_master'

   171             return None

   172 

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

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

   175 

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

   177 to worry about providing routing instructions for the database cache

   178 model.

   179 

   180 Filesystem caching

   181 ------------------

   182 

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

   184 ``CACHE_BACKEND``. For example, to store cached data in ``/var/tmp/django_cache``,

   185 use this setting::

   186 

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

   188 

   189 Note that there are three forward slashes toward the beginning of that example.

   190 The first two are for ``file://``, and the third is the first character of the

   191 directory path, ``/var/tmp/django_cache``. If you're on Windows, put the

   192 drive letter after the ``file://``, like this::

   193 

   194     file://c:/foo/bar

   195 

   196 The directory path should be absolute -- that is, it should start at the root

   197 of your filesystem. It doesn't matter whether you put a slash at the end of the

   198 setting.

   199 

   200 Make sure the directory pointed-to by this setting exists and is readable and

   201 writable by the system user under which your Web server runs. Continuing the

   202 above example, if your server runs as the user ``apache``, make sure the

   203 directory ``/var/tmp/django_cache`` exists and is readable and writable by the

   204 user ``apache``.

   205 

   206 Each cache value will be stored as a separate file whose contents are the

   207 cache data saved in a serialized ("pickled") format, using Python's ``pickle``

   208 module. Each file's name is the cache key, escaped for safe filesystem use.

   209 

   210 Local-memory caching

   211 --------------------

   212 

   213 If you want the speed advantages of in-memory caching but don't have the

   214 capability of running Memcached, consider the local-memory cache backend. This

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

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

   217 

   218     CACHE_BACKEND = 'locmem://'

   219 

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

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

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

   223 for production environments. It's nice for development.

   224 

   225 Dummy caching (for development)

   226 -------------------------------

   227 

   228 Finally, Django comes with a "dummy" cache that doesn't actually cache -- it

   229 just implements the cache interface without doing anything.

   230 

   231 This is useful if you have a production site that uses heavy-duty caching in

   232 various places but a development/test environment where you don't want to cache

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

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

   235 

   236     CACHE_BACKEND = 'dummy://'

   237 

   238 Using a custom cache backend

   239 ----------------------------

   240 

   241 .. versionadded:: 1.0

   242 

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

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

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

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

   247 

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

   249 

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

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

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

   253 

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

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

   256 been well-tested and are easy to use.

   257 

   258 CACHE_BACKEND arguments

   259 -----------------------

   260 

   261 Each cache backend may take arguments. They're given in query-string style on

   262 the ``CACHE_BACKEND`` setting. Valid arguments are as follows:

   263 

   264     * ``timeout``: The default timeout, in seconds, to use for the cache.

   265       This argument defaults to 300 seconds (5 minutes).

   266 

   267     * ``max_entries``: For the ``locmem``, ``filesystem`` and ``database``

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

   269       values are deleted. This argument defaults to 300.

   270 

   271     * ``cull_frequency``: The fraction of entries that are culled when

   272       ``max_entries`` is reached. The actual ratio is ``1/cull_frequency``, so

   273       set ``cull_frequency=2`` to cull half of the entries when ``max_entries``

   274       is reached.

   275 

   276       A value of ``0`` for ``cull_frequency`` means that the entire cache will

   277       be dumped when ``max_entries`` is reached. This makes culling *much*

   278       faster at the expense of more cache misses.

   279 

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

   281 

   282     CACHE_BACKEND = "memcached://127.0.0.1:11211/?timeout=60"

   283 

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

   285 

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

   287 

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

   289 arguments.

   290 

   291 The per-site cache

   292 ==================

   293 

   294 .. versionchanged:: 1.0

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

   296     of the two pieces described below).

   297 

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

   299 entire site. You'll need to add

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

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

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

   303 

   304     MIDDLEWARE_CLASSES = (

   305         'django.middleware.cache.UpdateCacheMiddleware',

   306         'django.middleware.common.CommonMiddleware',

   307         'django.middleware.cache.FetchFromCacheMiddleware',

   308     )

   309 

   310 .. note::

   311 

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

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

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

   315 

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

   317 

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

   319   cached.

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

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

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

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

   324 

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

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

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

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

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

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

   331 ``AuthenticationMiddleware``.

   332 

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

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

   335 

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

   337       (uncached) version of the page is requested.

   338 

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

   340       ``CACHE_MIDDLEWARE_SECONDS``.

   341 

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

   343       again, from the ``CACHE_MIDDLEWARE_SECONDS`` setting.

   344 

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

   346 

   347 .. versionadded:: 1.0

   348 

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

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

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

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

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

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

   355 more on these decorators.

   356 

   357 .. _i18n-cache-key:

   358 

   359 .. versionadded:: 1.2

   360 

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

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

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

   364 the cache key yourself.

   365 

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

   367 language.

   368 

   369 __ `Controlling cache: Using other headers`_

   370 

   371 The per-view cache

   372 ==================

   373 

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

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

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

   377 to use::

   378 

   379     from django.views.decorators.cache import cache_page

   380 

   381     @cache_page(60 * 15)

   382     def my_view(request):

   383         ...

   384 

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

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

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

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

   389 multiplied by 60 seconds per minute.)

   390 

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

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

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

   394 

   395     urlpatterns = ('',

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

   397     )

   398 

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

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

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

   402 

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

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

   405 middleware.  It can be used like this::

   406 

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

   408     def my_view(request):

   409         ...

   410 

   411 Specifying per-view cache in the URLconf

   412 ----------------------------------------

   413 

   414 The examples in the previous section have hard-coded the fact that the view is

   415 cached, because ``cache_page`` alters the ``my_view`` function in place. This

   416 approach couples your view to the cache system, which is not ideal for several

   417 reasons. For instance, you might want to reuse the view functions on another,

   418 cache-less site, or you might want to distribute the views to people who might

   419 want to use them without being cached. The solution to these problems is to

   420 specify the per-view cache in the URLconf rather than next to the view functions

   421 themselves.

   422 

   423 Doing so is easy: simply wrap the view function with ``cache_page`` when you

   424 refer to it in the URLconf. Here's the old URLconf from earlier::

   425 

   426     urlpatterns = ('',

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

   428     )

   429 

   430 Here's the same thing, with ``my_view`` wrapped in ``cache_page``::

   431 

   432     from django.views.decorators.cache import cache_page

   433 

   434     urlpatterns = ('',

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

   436     )

   437 

   438 If you take this approach, don't forget to import ``cache_page`` within your

   439 URLconf.

   440 

   441 Template fragment caching

   442 =========================

   443 

   444 .. versionadded:: 1.0

   445 

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

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

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

   449 

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

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

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

   453 

   454 .. code-block:: html+django

   455 

   456     {% load cache %}

   457     {% cache 500 sidebar %}

   458         .. sidebar ..

   459     {% endcache %}

   460 

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

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

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

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

   465 template tag to uniquely identify the cache fragment:

   466 

   467 .. code-block:: html+django

   468 

   469     {% load cache %}

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

   471         .. sidebar for logged in user ..

   472     {% endcache %}

   473 

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

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

   476 

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

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

   479 tag you could use one of the

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

   481 templates to archieve the same result:

   482 

   483 .. code-block:: html+django

   484 

   485     {% load i18n %}

   486     {% load cache %}

   487 

   488     {% get_current_language as LANGUAGE_CODE %}

   489 

   490     {% cache 600 welcome LANGUAGE_CODE %}

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

   492     {% endcache %}

   493 

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

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

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

   497 equivalent:

   498 

   499 .. code-block:: html+django

   500 

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

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

   503 

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

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

   506 

   507 The low-level cache API

   508 =======================

   509 

   510 .. highlight:: python

   511 

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

   513 in fact, inconvenient overkill.

   514 

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

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

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

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

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

   520 want to cache the results that rarely change.

   521 

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

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

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

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

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

   527 pickling.)

   528 

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

   530 automatically created from the ``CACHE_BACKEND`` setting::

   531 

   532     >>> from django.core.cache import cache

   533 

   534 The basic interface is ``set(key, value, timeout)`` and ``get(key)``::

   535 

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

   537     >>> cache.get('my_key')

   538     'hello, world!'

   539 

   540 The ``timeout`` argument is optional and defaults to the ``timeout``

   541 argument in the ``CACHE_BACKEND`` setting (explained above). It's the number of

   542 seconds the value should be stored in the cache.

   543 

   544 If the object doesn't exist in the cache, ``cache.get()`` returns ``None``::

   545 

   546     # Wait 30 seconds for 'my_key' to expire...

   547 

   548     >>> cache.get('my_key')

   549     None

   550 

   551 We advise against storing the literal value ``None`` in the cache, because you

   552 won't be able to distinguish between your stored ``None`` value and a cache

   553 miss signified by a return value of ``None``.

   554 

   555 ``cache.get()`` can take a ``default`` argument. This specifies which value to

   556 return if the object doesn't exist in the cache::

   557 

   558     >>> cache.get('my_key', 'has expired')

   559     'has expired'

   560 

   561 .. versionadded:: 1.0

   562 

   563 To add a key only if it doesn't already exist, use the ``add()`` method.

   564 It takes the same parameters as ``set()``, but it will not attempt to

   565 update the cache if the key specified is already present::

   566 

   567     >>> cache.set('add_key', 'Initial value')

   568     >>> cache.add('add_key', 'New value')

   569     >>> cache.get('add_key')

   570     'Initial value'

   571 

   572 If you need to know whether ``add()`` stored a value in the cache, you can

   573 check the return value. It will return ``True`` if the value was stored,

   574 ``False`` otherwise.

   575 

   576 There's also a ``get_many()`` interface that only hits the cache once.

   577 ``get_many()`` returns a dictionary with all the keys you asked for that

   578 actually exist in the cache (and haven't expired)::

   579 

   580     >>> cache.set('a', 1)

   581     >>> cache.set('b', 2)

   582     >>> cache.set('c', 3)

   583     >>> cache.get_many(['a', 'b', 'c'])

   584     {'a': 1, 'b': 2, 'c': 3}

   585 

   586 .. versionadded:: 1.2

   587 

   588 To set multiple values more efficiently, use ``set_many()`` to pass a dictionary

   589 of key-value pairs::

   590 

   591     >>> cache.set_many({'a': 1, 'b': 2, 'c': 3})

   592     >>> cache.get_many(['a', 'b', 'c'])

   593     {'a': 1, 'b': 2, 'c': 3}

   594 

   595 Like ``cache.set()``, ``set_many()`` takes an optional ``timeout`` parameter.

   596 

   597 You can delete keys explicitly with ``delete()``. This is an easy way of

   598 clearing the cache for a particular object::

   599 

   600     >>> cache.delete('a')

   601 

   602 .. versionadded:: 1.2

   603 

   604 If you want to clear a bunch of keys at once, ``delete_many()`` can take a list

   605 of keys to be cleared::

   606 

   607     >>> cache.delete_many(['a', 'b', 'c'])

   608 

   609 .. versionadded:: 1.2

   610 

   611 Finally, if you want to delete all the keys in the cache, use

   612 ``cache.clear()``.  Be careful with this; ``clear()`` will remove *everything*

   613 from the cache, not just the keys set by your application. ::

   614 

   615     >>> cache.clear()

   616 

   617 .. versionadded:: 1.1

   618 

   619 You can also increment or decrement a key that already exists using the

   620 ``incr()`` or ``decr()`` methods, respectively. By default, the existing cache

   621 value will incremented or decremented by 1. Other increment/decrement values

   622 can be specified by providing an argument to the increment/decrement call. A

   623 ValueError will be raised if you attempt to increment or decrement a

   624 nonexistent cache key.::

   625 

   626     >>> cache.set('num', 1)

   627     >>> cache.incr('num')

   628     2

   629     >>> cache.incr('num', 10)

   630     12

   631     >>> cache.decr('num')

   632     11

   633     >>> cache.decr('num', 5)

   634     6

   635 

   636 .. note::

   637 

   638     ``incr()``/``decr()`` methods are not guaranteed to be atomic. On those

   639     backends that support atomic increment/decrement (most notably, the

   640     memcached backend), increment and decrement operations will be atomic.

   641     However, if the backend doesn't natively provide an increment/decrement

   642     operation, it will be implemented using a two-step retrieve/update.

   643 

   644 Cache key warnings

   645 ------------------

   646 

   647 .. versionadded:: 1.3

   648 

   649 Memcached, the most commonly-used production cache backend, does not allow

   650 cache keys longer than 250 characters or containing whitespace or control

   651 characters, and using such keys will cause an exception. To encourage

   652 cache-portable code and minimize unpleasant surprises, the other built-in cache

   653 backends issue a warning (``django.core.cache.backends.base.CacheKeyWarning``)

   654 if a key is used that would cause an error on memcached.

   655 

   656 If you are using a production backend that can accept a wider range of keys (a

   657 custom backend, or one of the non-memcached built-in backends), and want to use

   658 this wider range without warnings, you can silence ``CacheKeyWarning`` with

   659 this code in the ``management`` module of one of your

   660 :setting:`INSTALLED_APPS`::

   661 

   662      import warnings

   663 

   664      from django.core.cache import CacheKeyWarning

   665 

   666      warnings.simplefilter("ignore", CacheKeyWarning)

   667 

   668 If you want to instead provide custom key validation logic for one of the

   669 built-in backends, you can subclass it, override just the ``validate_key``

   670 method, and follow the instructions for `using a custom cache backend`_. For

   671 instance, to do this for the ``locmem`` backend, put this code in a module::

   672 

   673     from django.core.cache.backends.locmem import CacheClass as LocMemCacheClass

   674 

   675     class CacheClass(LocMemCacheClass):

   676         def validate_key(self, key):

   677             """Custom validation, raising exceptions or warnings as needed."""

   678             # ...

   679 

   680 ...and use the dotted Python path to this module as the scheme portion of your

   681 :setting:`CACHE_BACKEND`.

   682 

   683 Upstream caches

   684 ===============

   685 

   686 So far, this document has focused on caching your *own* data. But another type

   687 of caching is relevant to Web development, too: caching performed by "upstream"

   688 caches. These are systems that cache pages for users even before the request

   689 reaches your Web site.

   690 

   691 Here are a few examples of upstream caches:

   692 

   693     * Your ISP may cache certain pages, so if you requested a page from

   694       http://example.com/, your ISP would send you the page without having to

   695       access example.com directly. The maintainers of example.com have no

   696       knowledge of this caching; the ISP sits between example.com and your Web

   697       browser, handling all of the caching transparently.

   698 

   699     * Your Django Web site may sit behind a *proxy cache*, such as Squid Web

   700       Proxy Cache (http://www.squid-cache.org/), that caches pages for

   701       performance. In this case, each request first would be handled by the

   702       proxy, and it would be passed to your application only if needed.

   703 

   704     * Your Web browser caches pages, too. If a Web page sends out the

   705       appropriate headers, your browser will use the local cached copy for

   706       subsequent requests to that page, without even contacting the Web page

   707       again to see whether it has changed.

   708 

   709 Upstream caching is a nice efficiency boost, but there's a danger to it:

   710 Many Web pages' contents differ based on authentication and a host of other

   711 variables, and cache systems that blindly save pages based purely on URLs could

   712 expose incorrect or sensitive data to subsequent visitors to those pages.

   713 

   714 For example, say you operate a Web e-mail system, and the contents of the

   715 "inbox" page obviously depend on which user is logged in. If an ISP blindly

   716 cached your site, then the first user who logged in through that ISP would have

   717 his user-specific inbox page cached for subsequent visitors to the site. That's

   718 not cool.

   719 

   720 Fortunately, HTTP provides a solution to this problem. A number of HTTP headers

   721 exist to instruct upstream caches to differ their cache contents depending on

   722 designated variables, and to tell caching mechanisms not to cache particular

   723 pages. We'll look at some of these headers in the sections that follow.

   724 

   725 Using Vary headers

   726 ==================

   727 

   728 The ``Vary`` header defines which request headers a cache

   729 mechanism should take into account when building its cache key. For example, if

   730 the contents of a Web page depend on a user's language preference, the page is

   731 said to "vary on language."

   732 

   733 By default, Django's cache system creates its cache keys using the requested

   734 path (e.g., ``"/stories/2005/jun/23/bank_robbed/"``). This means every request

   735 to that URL will use the same cached version, regardless of user-agent

   736 differences such as cookies or language preferences. However, if this page

   737 produces different content based on some difference in request headers -- such

   738 as a cookie, or a language, or a user-agent -- you'll need to use the ``Vary``

   739 header to tell caching mechanisms that the page output depends on those things.

   740 

   741 To do this in Django, use the convenient ``vary_on_headers`` view decorator,

   742 like so::

   743 

   744     from django.views.decorators.vary import vary_on_headers

   745 

   746     @vary_on_headers('User-Agent')

   747     def my_view(request):

   748         # ...

   749 

   750 In this case, a caching mechanism (such as Django's own cache middleware) will

   751 cache a separate version of the page for each unique user-agent.

   752 

   753 The advantage to using the ``vary_on_headers`` decorator rather than manually

   754 setting the ``Vary`` header (using something like

   755 ``response['Vary'] = 'user-agent'``) is that the decorator *adds* to the

   756 ``Vary`` header (which may already exist), rather than setting it from scratch

   757 and potentially overriding anything that was already in there.

   758 

   759 You can pass multiple headers to ``vary_on_headers()``::

   760 

   761     @vary_on_headers('User-Agent', 'Cookie')

   762     def my_view(request):

   763         # ...

   764 

   765 This tells upstream caches to vary on *both*, which means each combination of

   766 user-agent and cookie will get its own cache value. For example, a request with

   767 the user-agent ``Mozilla`` and the cookie value ``foo=bar`` will be considered

   768 different from a request with the user-agent ``Mozilla`` and the cookie value

   769 ``foo=ham``.

   770 

   771 Because varying on cookie is so common, there's a ``vary_on_cookie``

   772 decorator. These two views are equivalent::

   773 

   774     @vary_on_cookie

   775     def my_view(request):

   776         # ...

   777 

   778     @vary_on_headers('Cookie')

   779     def my_view(request):

   780         # ...

   781 

   782 The headers you pass to ``vary_on_headers`` are not case sensitive;

   783 ``"User-Agent"`` is the same thing as ``"user-agent"``.

   784 

   785 You can also use a helper function, ``django.utils.cache.patch_vary_headers``,

   786 directly. This function sets, or adds to, the ``Vary header``. For example::

   787 

   788     from django.utils.cache import patch_vary_headers

   789 

   790     def my_view(request):

   791         # ...

   792         response = render_to_response('template_name', context)

   793         patch_vary_headers(response, ['Cookie'])

   794         return response

   795 

   796 ``patch_vary_headers`` takes an :class:`~django.http.HttpResponse` instance as

   797 its first argument and a list/tuple of case-insensitive header names as its

   798 second argument.

   799 

   800 For more on Vary headers, see the `official Vary spec`_.

   801 

   802 .. _`official Vary spec`: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44

   803 

   804 Controlling cache: Using other headers

   805 ======================================

   806 

   807 Other problems with caching are the privacy of data and the question of where

   808 data should be stored in a cascade of caches.

   809 

   810 A user usually faces two kinds of caches: his or her own browser cache (a

   811 private cache) and his or her provider's cache (a public cache). A public cache

   812 is used by multiple users and controlled by someone else. This poses problems

   813 with sensitive data--you don't want, say, your bank account number stored in a

   814 public cache. So Web applications need a way to tell caches which data is

   815 private and which is public.

   816 

   817 The solution is to indicate a page's cache should be "private." To do this in

   818 Django, use the ``cache_control`` view decorator. Example::

   819 

   820     from django.views.decorators.cache import cache_control

   821 

   822     @cache_control(private=True)

   823     def my_view(request):

   824         # ...

   825 

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

   827 scenes.

   828 

   829 There are a few other ways to control cache parameters. For example, HTTP

   830 allows applications to do the following:

   831 

   832     * Define the maximum time a page should be cached.

   833 

   834     * Specify whether a cache should always check for newer versions, only

   835       delivering the cached content when there are no changes. (Some caches

   836       might deliver cached content even if the server page changed, simply

   837       because the cache copy isn't yet expired.)

   838 

   839 In Django, use the ``cache_control`` view decorator to specify these cache

   840 parameters. In this example, ``cache_control`` tells caches to revalidate the

   841 cache on every access and to store cached versions for, at most, 3,600 seconds::

   842 

   843     from django.views.decorators.cache import cache_control

   844 

   845     @cache_control(must_revalidate=True, max_age=3600)

   846     def my_view(request):

   847         # ...

   848 

   849 Any valid ``Cache-Control`` HTTP directive is valid in ``cache_control()``.

   850 Here's a full list:

   851 

   852     * ``public=True``

   853     * ``private=True``

   854     * ``no_cache=True``

   855     * ``no_transform=True``

   856     * ``must_revalidate=True``

   857     * ``proxy_revalidate=True``

   858     * ``max_age=num_seconds``

   859     * ``s_maxage=num_seconds``

   860 

   861 For explanation of Cache-Control HTTP directives, see the `Cache-Control spec`_.

   862 

   863 (Note that the caching middleware already sets the cache header's max-age with

   864 the value of the :setting:`CACHE_MIDDLEWARE_SECONDS` setting. If you use a custom

   865 ``max_age`` in a ``cache_control`` decorator, the decorator will take

   866 precedence, and the header values will be merged correctly.)

   867 

   868 If you want to use headers to disable caching altogether,

   869 ``django.views.decorators.cache.never_cache`` is a view decorator that adds

   870 headers to ensure the response won't be cached by browsers or other caches.

   871 Example::

   872 

   873     from django.views.decorators.cache import never_cache

   874 

   875     @never_cache

   876     def myview(request):

   877         # ...

   878 

   879 .. _`Cache-Control spec`: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

   880 

   881 Other optimizations

   882 ===================

   883 

   884 Django comes with a few other pieces of middleware that can help optimize your

   885 site's performance:

   886 

   887     * ``django.middleware.http.ConditionalGetMiddleware`` adds support for

   888       modern browsers to conditionally GET responses based on the ``ETag``

   889       and ``Last-Modified`` headers.

   890 

   891     * ``django.middleware.gzip.GZipMiddleware`` compresses responses for all

   892       moderns browsers, saving bandwidth and transfer time.

   893 

   894 Order of MIDDLEWARE_CLASSES

   895 ===========================

   896 

   897 If you use caching middleware, it's important to put each half in the right

   898 place within the ``MIDDLEWARE_CLASSES`` setting. That's because the cache

   899 middleware needs to know which headers by which to vary the cache storage.

   900 Middleware always adds something to the ``Vary`` response header when it can.

   901 

   902 ``UpdateCacheMiddleware`` runs during the response phase, where middleware is

   903 run in reverse order, so an item at the top of the list runs *last* during the

   904 response phase. Thus, you need to make sure that ``UpdateCacheMiddleware``

   905 appears *before* any other middleware that might add something to the ``Vary``

   906 header. The following middleware modules do so:

   907 

   908     * ``SessionMiddleware`` adds ``Cookie``

   909     * ``GZipMiddleware`` adds ``Accept-Encoding``

   910     * ``LocaleMiddleware`` adds ``Accept-Language``

   911 

   912 ``FetchFromCacheMiddleware``, on the other hand, runs during the request phase,

   913 where middleware is applied first-to-last, so an item at the top of the list

   914 runs *first* during the request phase. The ``FetchFromCacheMiddleware`` also

   915 needs to run after other middleware updates the ``Vary`` header, so

   916 ``FetchFromCacheMiddleware`` must be *after* any item that does so.

   917