mirror of https://github.com/django/django.git
140 lines
5.3 KiB
Plaintext
140 lines
5.3 KiB
Plaintext
========================
|
|
Django's cache framework
|
|
========================
|
|
|
|
So, you got slashdotted. Now what?
|
|
|
|
Django's cache framework gives you two methods of caching dynamic pages in
|
|
memory or in a database: you can automatically cache the entire page, or you can manually
|
|
cache only the pieces that are difficult to produce.
|
|
|
|
Setting up the cache
|
|
====================
|
|
|
|
The cache framework is split into a set of "backends" that provide different
|
|
methods of caching data. There's a simple single-process memory cache
|
|
(mostly useful as a fallback), a database-backed cache, and a memcached_
|
|
backend (by far the fastest option if you've got the RAM).
|
|
|
|
Before using the cache, you'll need to tell Django which cache backend you'd
|
|
like to use; do this by setting the ``CACHE_BACKEND`` in your settings file.
|
|
|
|
The CACHE_BACKEND setting is a quasi-URI; examples are:
|
|
|
|
============================== ===========================================
|
|
CACHE_BACKEND Explanation
|
|
============================== ===========================================
|
|
memcached://127.0.0.1:11211/ A memcached backend; the server is running
|
|
on localhost port 11211.
|
|
|
|
db://tablename/ A database backend (the db backend uses
|
|
the same database/username as the rest of
|
|
the CMS, so only a table name is needed.)
|
|
|
|
simple:/// A simple single-process memory cache; you
|
|
probably don't want to use this except for
|
|
testing. Note that this cache backend is
|
|
NOT threadsafe!
|
|
============================== ===========================================
|
|
|
|
All caches may take arguments; these are given in query-string style. Valid
|
|
arguments are:
|
|
|
|
timeout
|
|
Default timeout, in seconds, to use for the cache. Defaults
|
|
to 5 minutes (300 seconds).
|
|
|
|
max_entries
|
|
For the simple and database backends, the maximum number of entries
|
|
allowed in the cache before it is cleaned. Defaults to 300.
|
|
|
|
cull_percentage
|
|
The percentage of entries that are culled when max_entries is reached.
|
|
The actual percentage is 1/cull_percentage, so set cull_percentage=3 to
|
|
cull 1/3 of the entries when max_entries is reached.
|
|
|
|
A value of 0 for cull_percentage 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.
|
|
|
|
For example::
|
|
|
|
DB_CACHE = "memcached://127.0.0.1:11211/?timeout=60"
|
|
DB_CACHE = "db://tablename/?timeout=120&max_entries=500&cull_percentage=4"
|
|
|
|
Invalid arguments are silently ignored, as are invalid values of known
|
|
arguments.
|
|
|
|
The per-page cache
|
|
==================
|
|
|
|
Once the cache is set up, the simplest way to use the cache is to simply
|
|
cache entire view functions. ``django.views.decorators.cache`` defines
|
|
a ``cache_page`` decorator that will automatically cache the view's response
|
|
for you. Using it couldn't be easier::
|
|
|
|
from django.views.decorators.cache import cache_page
|
|
|
|
def slashdot_this(request):
|
|
...
|
|
|
|
slashdot_this = cache_page(slashdot_this, 60 * 15):
|
|
|
|
Or, using Python 2.4's decorator syntax::
|
|
|
|
@cache_page(60 * 15)
|
|
def slashdot_this(request):
|
|
...
|
|
|
|
This will cache the result of that view for 15 minutes (the cache timeout is
|
|
in seconds).
|
|
|
|
The low-level cache API
|
|
=======================
|
|
|
|
There are times, however, that caching an entire rendered page doesn't gain
|
|
you very much. We often find that we only need to cache a list of object IDs
|
|
from an intensive database query, for example. In cases like these, you
|
|
can use the cache API to store objects in the cache with any level of
|
|
granularity you like.
|
|
|
|
The cache API is almost shockingly simple::
|
|
|
|
# the cache module exports a cache object that's automatically
|
|
# created from the CACHE_BACKEND setting
|
|
>>> from django.core.cache import cache
|
|
|
|
# The basic interface is set(key, value, timeout_seconds) and get(key)
|
|
>>> cache.set('my_key', 'hello, world!', 30)
|
|
>>> cache.get('my_key')
|
|
'hello, world!'
|
|
|
|
# (wait 30 seconds...)
|
|
>>> cache.get('my_key')
|
|
None
|
|
|
|
# get can take a default argument
|
|
>>> cache.get('my_key', 'has_expired')
|
|
'has_expired'
|
|
|
|
# there's also a get_many interface that only hits the cache once
|
|
# also, note that the timeout argument is optional and defaults
|
|
# to what you've given in the settings file.
|
|
>>> cache.set('a', 1)
|
|
>>> cache.set('b', 2)
|
|
>>> cache.set('c', 3)
|
|
>>> cache.get_many(['a', 'b', 'c'])
|
|
{'a': 1, 'b': 2, 'c': 3}
|
|
# get_many returns a dict with all the keys you asked for that
|
|
# actually exist in the cache (and haven't expired)
|
|
|
|
# there's also a way to explicitly delete keys
|
|
>>> cache.delete('a')
|
|
|
|
Really, that's the entire API! There's very few restrictions on what you can
|
|
use the cache for; you can store any object in the cache that can be pickled
|
|
safely, although keys must be strings.
|
|
|
|
.. _memcached: http://www.danga.com/memcached/
|
|
|