A fundamental trade-off in dynamic websites is, well, they're dynamic. Each\ntime a user requests a page, the Web server makes all sorts of calculations --\nfrom database queries to template rendering to business logic -- to create the\npage that your site's visitor sees. This is a lot more expensive, from a\nprocessing-overhead perspective, than your standard\nread-a-file-off-the-filesystem server arrangement.
\nFor most Web applications, this overhead isn't a big deal. Most Web\napplications aren't washingtonpost.com or slashdot.org; they're small-\nto medium-sized sites with so-so traffic. But for medium- to high-traffic\nsites, it's essential to cut as much overhead as possible.
That's where caching comes in.
\nTo cache something is to save the result of an expensive calculation so that\nyou don't have to perform the calculation next time. Here's some pseudocode\nexplaining how this would work for a dynamically generated Web page:
\ngiven a URL, try finding that page in the cache\nif the page is in the cache:\n return the cached page\nelse:\n generate the page\n save the generated page in the cache (for next time)\n return the generated page\nDjango comes with a robust cache system that lets you save dynamic pages so\nthey don't have to be calculated for each request. For convenience, Django\noffers different levels of cache granularity: You can cache the output of\nspecific views, you can cache only the pieces that are difficult to produce,\nor you can cache your entire site.
\nDjango also works well with "downstream" caches, such as Squid and browser-based caches. These are the types of\ncaches that you don't directly control but to which you can provide hints (via\nHTTP headers) about which parts of your site should be cached, and how.
\n\nThe cache system requires a small amount of setup. Namely, you have to tell it\nwhere your cached data should live -- whether in a database, on the filesystem\nor directly in memory. This is an important decision that affects your cache's\nperformance; yes, some cache types are faster than others.
\nYour cache preference goes in the CACHES setting in your\nsettings file. Here's an explanation of all available values for\nCACHES.
The fastest, most efficient type of cache supported natively by Django,\nMemcached is an entirely memory-based cache server, originally developed\nto handle high loads at LiveJournal.com and subsequently open-sourced by\nDanga Interactive. It is used by sites such as Facebook and Wikipedia to\nreduce database access and dramatically increase site performance.
\nMemcached runs as a daemon and is allotted a specified amount of RAM. All it\ndoes is provide a fast interface for adding, retrieving and deleting data in\nthe cache. All data is stored directly in memory, so there's no overhead of\ndatabase or filesystem usage.
\nAfter installing Memcached itself, you'll need to install a Memcached\nbinding. There are several Python Memcached bindings available; the\ntwo most common are python-memcached and pylibmc.
\nTo use Memcached with Django:
\nSet BACKEND to\ndjango.core.cache.backends.memcached.MemcachedCache or\ndjango.core.cache.backends.memcached.PyLibMCCache (depending\non your chosen memcached binding)
Set LOCATION to ip:port values,\nwhere ip is the IP address of the Memcached daemon and port is the\nport on which Memcached is running, or to a unix:path value, where\npath is the path to a Memcached Unix socket file.
In this example, Memcached is running on localhost (127.0.0.1) port 11211, using\nthe python-memcached binding:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': '127.0.0.1:11211',\n }\n}\nIn this example, Memcached is available through a local Unix socket file\n/tmp/memcached.sock using the python-memcached binding:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': 'unix:/tmp/memcached.sock',\n }\n}\nWhen using the pylibmc binding, do not include the unix:/ prefix:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',\n 'LOCATION': '/tmp/memcached.sock',\n }\n}\nOne excellent feature of Memcached is its ability to share a cache over\nmultiple servers. This means you can run Memcached daemons on multiple\nmachines, and the program will treat the group of machines as a single\ncache, without the need to duplicate cache values on each machine. To take\nadvantage of this feature, include all server addresses in\nLOCATION, either as a semicolon or comma\ndelimited string, or as a list.
In this example, the cache is shared over Memcached instances running on IP\naddress 172.19.26.240 and 172.19.26.242, both on port 11211:
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': [\n '172.19.26.240:11211',\n '172.19.26.242:11211',\n ]\n }\n}\nIn the following example, the cache is shared over Memcached instances running\non the IP addresses 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and\n172.19.26.244 (port 11213):
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': [\n '172.19.26.240:11211',\n '172.19.26.242:11212',\n '172.19.26.244:11213',\n ]\n }\n}\nA final point about Memcached is that memory-based caching has a\ndisadvantage: because the cached data is stored in memory, the data will be\nlost if your server crashes. Clearly, memory isn't intended for permanent data\nstorage, so don't rely on memory-based caching as your only data storage.\nWithout a doubt, none of the Django caching backends should be used for\npermanent storage -- they're all intended to be solutions for caching, not\nstorage -- but we point this out here because memory-based caching is\nparticularly temporary.
\nDjango はキャッシュデータをデータベース中に保存できます。この仕組みは、高速で適切にインデックス付けされたデータベースサーバーがある場合に、有効に機能します。
\nデータベースのテーブルをキャッシュのバックエンドに使用する場合には、以下のように設定します。
\nBACKEND を django.core.cache.backends.db.DatabaseCache に設定する
LOCATION の tablename にデータベーステーブルの名前を設定します。この名前は、データベースで未使用かつ有効な名前であれば、自分が好きな名前で構いません。
この例では、キャッシュテーブルの名前を my_cache_table と設定しています。
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.db.DatabaseCache',\n 'LOCATION': 'my_cache_table',\n }\n}\nデータベースキャッシュを使用する前に、キャッシュテーブルをコマンドで作成する必要がある。
\npython manage.py createcachetable\nこのコマンドにより、データベース内に1つのテーブルが作成され、Django のデータベースキャッシュシステムに必要な適切なフォーマットが生成されます。テーブルの名前は LOCATION が使用されます。
複数のデータベースキャッシュが使用される場合、createcachetable は1つのキャッシュごとに、対応する1つのテーブルを作成します。
複数のデータベースを使用する場合、createcachetable は、データベースのルートの allow_migrate() メソッド (以下を参照) を監視します。
migrate と同様に、createcachetable は既に存在する既存のテーブルにたいしては手を触れません。存在しないテーブルのみを生成します。
実行される予定の SQL を実行せずに表示するためには、createcachetable --dry-run オプションを使用します。
If you use database caching with multiple databases, you'll also need\nto set up routing instructions for your database cache table. For the\npurposes of routing, the database cache table appears as a model named\nCacheEntry, in an application named django_cache. This model\nwon't appear in the models cache, but the model details can be used\nfor routing purposes.
For example, the following router would direct all cache read\noperations to cache_replica, and all write operations to\ncache_primary. The cache table will only be synchronized onto\ncache_primary:
class CacheRouter:\n """A router to control all database cache operations"""\n\n def db_for_read(self, model, **hints):\n "All cache read operations go to the replica"\n if model._meta.app_label == 'django_cache':\n return 'cache_replica'\n return None\n\n def db_for_write(self, model, **hints):\n "All cache write operations go to primary"\n if model._meta.app_label == 'django_cache':\n return 'cache_primary'\n return None\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n "Only install the cache model on primary"\n if app_label == 'django_cache':\n return db == 'cache_primary'\n return None\nIf you don't specify routing directions for the database cache model,\nthe cache backend will use the default database.
And if you don't use the database cache backend, you don't need to worry about\nproviding routing instructions for the database cache model.
\nThe file-based backend serializes and stores each cache value as a separate\nfile. To use this backend set BACKEND to\n"django.core.cache.backends.filebased.FileBasedCache" and\nLOCATION to a suitable directory. For example,\nto store cached data in /var/tmp/django_cache, use this setting:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': '/var/tmp/django_cache',\n }\n}\nIf you're on Windows, put the drive letter at the beginning of the path,\nlike this:
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': 'c:/foo/bar',\n }\n}\nThe directory path should be absolute -- that is, it should start at the root\nof your filesystem. It doesn't matter whether you put a slash at the end of the\nsetting.
\nMake sure the directory pointed-to by this setting either exists and is\nreadable and writable, or that it can be created by the system user under which\nyour Web server runs. Continuing the above example, if your server runs as the\nuser apache, make sure the directory /var/tmp/django_cache exists and\nis readable and writable by the user apache, or that it can be created by\nthe user apache.
This is the default cache if another is not specified in your settings file. If\nyou want the speed advantages of in-memory caching but don't have the capability\nof running Memcached, consider the local-memory cache backend. This cache is\nper-process (see below) and thread-safe. To use it, set BACKEND to "django.core.cache.backends.locmem.LocMemCache". For\nexample:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',\n 'LOCATION': 'unique-snowflake',\n }\n}\nThe cache LOCATION is used to identify individual\nmemory stores. If you only have one locmem cache, you can omit the\nLOCATION; however, if you have more than one local\nmemory cache, you will need to assign a name to at least one of them in\norder to keep them separate.
The cache uses a least-recently-used (LRU) culling strategy.
\nNote that each process will have its own private cache instance, which means no\ncross-process caching is possible. This also means the local memory cache isn't\nparticularly memory-efficient, so it's probably not a good choice for\nproduction environments. It's nice for development.
\nFinally, Django comes with a "dummy" cache that doesn't actually cache -- it\njust implements the cache interface without doing anything.
\nThis is useful if you have a production site that uses heavy-duty caching in\nvarious places but a development/test environment where you don't want to cache\nand don't want to have to change your code to special-case the latter. To\nactivate dummy caching, set BACKEND like so:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.dummy.DummyCache',\n }\n}\nWhile Django includes support for a number of cache backends out-of-the-box,\nsometimes you might want to use a customized cache backend. To use an external\ncache backend with Django, use the Python import path as the\nBACKEND of the CACHES setting, like so:
CACHES = {\n 'default': {\n 'BACKEND': 'path.to.backend',\n }\n}\nIf you're building your own backend, you can use the standard cache backends\nas reference implementations. You'll find the code in the\ndjango/core/cache/backends/ directory of the Django source.
Note: Without a really compelling reason, such as a host that doesn't support\nthem, you should stick to the cache backends included with Django. They've\nbeen well-tested and are well-documented.
\nEach cache backend can be given additional arguments to control caching\nbehavior. These arguments are provided as additional keys in the\nCACHES setting. Valid arguments are as follows:
TIMEOUT: The default timeout, in\nseconds, to use for the cache. This argument defaults to 300 seconds (5 minutes).\nYou can set TIMEOUT to None so that, by default, cache keys never\nexpire. A value of 0 causes keys to immediately expire (effectively\n"don't cache").
OPTIONS: Any options that should be\npassed to the cache backend. The list of valid options will vary\nwith each backend, and cache backends backed by a third-party library\nwill pass their options directly to the underlying cache library.
Cache backends that implement their own culling strategy (i.e.,\nthe locmem, filesystem and database backends) will\nhonor the following options:
MAX_ENTRIES: The maximum number of entries allowed in\nthe cache before old values are deleted. This argument\ndefaults to 300.
CULL_FREQUENCY: The fraction of entries that are culled\nwhen MAX_ENTRIES is reached. The actual ratio is\n1 / CULL_FREQUENCY, so set CULL_FREQUENCY to 2 to\ncull half the entries when MAX_ENTRIES is reached. This argument\nshould be an integer and defaults to 3.
A value of 0 for CULL_FREQUENCY means that the\nentire cache will be dumped when MAX_ENTRIES is reached.\nOn some backends (database in particular) this makes culling much\nfaster at the expense of more cache misses.
Memcached backends pass the contents of OPTIONS\nas keyword arguments to the client constructors, allowing for more advanced\ncontrol of client behavior. For example usage, see below.
KEY_PREFIX: A string that will be\nautomatically included (prepended by default) to all cache keys\nused by the Django server.
See the cache documentation for\nmore information.
\nVERSION: The default version number\nfor cache keys generated by the Django server.
See the cache documentation for more\ninformation.
\nKEY_FUNCTION\nA string containing a dotted path to a function that defines how\nto compose a prefix, version and key into a final cache key.
See the cache documentation\nfor more information.
\nIn this example, a filesystem backend is being configured with a timeout\nof 60 seconds, and a maximum capacity of 1000 items:
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': '/var/tmp/django_cache',\n 'TIMEOUT': 60,\n 'OPTIONS': {\n 'MAX_ENTRIES': 1000\n }\n }\n}\nHere's an example configuration for a python-memcached based backend with\nan object size limit of 2MB:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': '127.0.0.1:11211',\n 'OPTIONS': {\n 'server_max_value_length': 1024 * 1024 * 2,\n }\n }\n}\nHere's an example configuration for a pylibmc based backend that enables\nthe binary protocol, SASL authentication, and the ketama behavior mode:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',\n 'LOCATION': '127.0.0.1:11211',\n 'OPTIONS': {\n 'binary': True,\n 'username': 'user',\n 'password': 'pass',\n 'behaviors': {\n 'ketama': True,\n }\n }\n }\n}\nOnce the cache is set up, the simplest way to use caching is to cache your\nentire site. You'll need to add\n'django.middleware.cache.UpdateCacheMiddleware' and\n'django.middleware.cache.FetchFromCacheMiddleware' to your\nMIDDLEWARE setting, as in this example:
MIDDLEWARE = [\n 'django.middleware.cache.UpdateCacheMiddleware',\n 'django.middleware.common.CommonMiddleware',\n 'django.middleware.cache.FetchFromCacheMiddleware',\n]\nThen, add the following required settings to your Django settings file:
\nCACHE_MIDDLEWARE_ALIAS -- The cache alias to use for storage.
CACHE_MIDDLEWARE_SECONDS -- The number of seconds each page should\nbe cached.
CACHE_MIDDLEWARE_KEY_PREFIX -- If the cache is shared across\nmultiple sites using the same Django installation, set this to the name of\nthe site, or some other string that is unique to this Django instance, to\nprevent key collisions. Use an empty string if you don't care.
FetchFromCacheMiddleware caches GET and HEAD responses with status 200,\nwhere the request and response headers allow. Responses to requests for the same\nURL with different query parameters are considered to be unique pages and are\ncached separately. This middleware expects that a HEAD request is answered with\nthe same response headers as the corresponding GET request; in which case it can\nreturn a cached GET response for HEAD request.
Additionally, UpdateCacheMiddleware automatically sets a few headers in\neach HttpResponse which affect downstream caches:
Sets the Expires header to the current date/time plus the defined\nCACHE_MIDDLEWARE_SECONDS.
Sets the Cache-Control header to give a max age for the page --\nagain, from the CACHE_MIDDLEWARE_SECONDS setting.
See ミドルウェア (Middleware) for more on middleware.
\nIf a view sets its own cache expiry time (i.e. it has a max-age section in\nits Cache-Control header) then the page will be cached until the expiry\ntime, rather than CACHE_MIDDLEWARE_SECONDS. Using the decorators in\ndjango.views.decorators.cache you can easily set a view's expiry time\n(using the cache_control() decorator) or\ndisable caching for a view (using the\nnever_cache() decorator). See the\nusing other headers section for more on these decorators.
If USE_I18N is set to True then the generated cache key will\ninclude the name of the active language -- see also\nHow Django discovers language preference). This allows you to easily\ncache multilingual sites without having to create the cache key yourself.
Cache keys also include the active language when\nUSE_L10N is set to True and the current time zone when USE_TZ is set to True.
A more granular way to use the caching framework is by caching the output of\nindividual views. django.views.decorators.cache defines a cache_page\ndecorator that will automatically cache the view's response for you:
from django.views.decorators.cache import cache_page\n\n@cache_page(60 * 15)\ndef my_view(request):\n ...\ncache_page takes a single argument: the cache timeout, in seconds. In the\nabove example, the result of the my_view() view will be cached for 15\nminutes. (Note that we've written it as 60 * 15 for the purpose of\nreadability. 60 * 15 will be evaluated to 900 -- that is, 15 minutes\nmultiplied by 60 seconds per minute.)
The cache timeout set by cache_page takes precedence over the max-age\ndirective from the Cache-Control header.
The per-view cache, like the per-site cache, is keyed off of the URL. If\nmultiple URLs point at the same view, each URL will be cached separately.\nContinuing the my_view example, if your URLconf looks like this:
urlpatterns = [\n path('foo/<int:code>/', my_view),\n]\nthen requests to /foo/1/ and /foo/23/ will be cached separately, as\nyou may expect. But once a particular URL (e.g., /foo/23/) has been\nrequested, subsequent requests to that URL will use the cache.
cache_page can also take an optional keyword argument, cache,\nwhich directs the decorator to use a specific cache (from your\nCACHES setting) when caching view results. By default, the\ndefault cache will be used, but you can specify any cache you\nwant:
@cache_page(60 * 15, cache="special_cache")\ndef my_view(request):\n ...\nYou can also override the cache prefix on a per-view basis. cache_page\ntakes an optional keyword argument, key_prefix,\nwhich works in the same way as the CACHE_MIDDLEWARE_KEY_PREFIX\nsetting for the middleware. It can be used like this:
@cache_page(60 * 15, key_prefix="site1")\ndef my_view(request):\n ...\nThe key_prefix and cache arguments may be specified together. The\nkey_prefix argument and the KEY_PREFIX\nspecified under CACHES will be concatenated.
Additionally, cache_page automatically sets Cache-Control and\nExpires headers in the response which affect downstream caches.
The examples in the previous section have hard-coded the fact that the view is\ncached, because cache_page alters the my_view function in place. This\napproach couples your view to the cache system, which is not ideal for several\nreasons. For instance, you might want to reuse the view functions on another,\ncache-less site, or you might want to distribute the views to people who might\nwant to use them without being cached. The solution to these problems is to\nspecify the per-view cache in the URLconf rather than next to the view functions\nthemselves.
You can do so by wrapping the view function with cache_page when you refer\nto it in the URLconf. Here's the old URLconf from earlier:
urlpatterns = [\n path('foo/<int:code>/', my_view),\n]\nHere's the same thing, with my_view wrapped in cache_page:
from django.views.decorators.cache import cache_page\n\nurlpatterns = [\n path('foo/<int:code>/', cache_page(60 * 15)(my_view)),\n]\nIf you're after even more control, you can also cache template fragments using\nthe cache template tag. To give your template access to this tag, put\n{% load cache %} near the top of your template.
The {% cache %} template tag caches the contents of the block for a given\namount of time. It takes at least two arguments: the cache timeout, in seconds,\nand the name to give the cache fragment. The fragment is cached forever if\ntimeout is None. The name will be taken as is, do not use a variable. For\nexample:
{% load cache %}\n{% cache 500 sidebar %}\n .. sidebar ..\n{% endcache %}\nSometimes you might want to cache multiple copies of a fragment depending on\nsome dynamic data that appears inside the fragment. For example, you might want a\nseparate cached copy of the sidebar used in the previous example for every user\nof your site. Do this by passing one or more additional arguments, which may be\nvariables with or without filters, to the {% cache %} template tag to\nuniquely identify the cache fragment:
{% load cache %}\n{% cache 500 sidebar request.user.username %}\n .. sidebar for logged in user ..\n{% endcache %}\nIf USE_I18N is set to True the per-site middleware cache will\nrespect the active language. For the cache template\ntag you could use one of the\ntranslation-specific variables available in\ntemplates to achieve the same result:
{% load i18n %}\n{% load cache %}\n\n{% get_current_language as LANGUAGE_CODE %}\n\n{% cache 600 welcome LANGUAGE_CODE %}\n {% translate "Welcome to example.com" %}\n{% endcache %}\nThe cache timeout can be a template variable, as long as the template variable\nresolves to an integer value. For example, if the template variable\nmy_timeout is set to the value 600, then the following two examples are\nequivalent:
{% cache 600 sidebar %} ... {% endcache %}\n{% cache my_timeout sidebar %} ... {% endcache %}\nThis feature is useful in avoiding repetition in templates. You can set the\ntimeout in a variable, in one place, and reuse that value.
\nBy default, the cache tag will try to use the cache called "template_fragments".\nIf no such cache exists, it will fall back to using the default cache. You may\nselect an alternate cache backend to use with the using keyword argument,\nwhich must be the last argument to the tag.
{% cache 300 local-thing ... using="localcache" %}\nIt is considered an error to specify a cache name that is not configured.
\nIf you want to obtain the cache key used for a cached fragment, you can use\nmake_template_fragment_key. fragment_name is the same as second argument\nto the cache template tag; vary_on is a list of all additional arguments\npassed to the tag. This function can be useful for invalidating or overwriting\na cached item, for example:
>>> from django.core.cache import cache\n>>> from django.core.cache.utils import make_template_fragment_key\n# cache key for {% cache 500 sidebar username %}\n>>> key = make_template_fragment_key('sidebar', [username])\n>>> cache.delete(key) # invalidates cached template fragment\nTrue\nSometimes, caching an entire rendered page doesn't gain you very much and is,\nin fact, inconvenient overkill.
\nPerhaps, for instance, your site includes a view whose results depend on\nseveral expensive queries, the results of which change at different intervals.\nIn this case, it would not be ideal to use the full-page caching that the\nper-site or per-view cache strategies offer, because you wouldn't want to\ncache the entire result (since some of the data changes often), but you'd still\nwant to cache the results that rarely change.
\nFor cases like this, Django exposes a low-level cache API. You can use this API\nto store objects in the cache with any level of granularity you like. You can\ncache any Python object that can be pickled safely: strings, dictionaries,\nlists of model objects, and so forth. (Most common Python objects can be\npickled; refer to the Python documentation for more information about\npickling.)
\nYou can access the caches configured in the CACHES setting\nthrough a dict-like object: django.core.cache.caches. Repeated\nrequests for the same alias in the same thread will return the same\nobject.
>>> from django.core.cache import caches\n>>> cache1 = caches['myalias']\n>>> cache2 = caches['myalias']\n>>> cache1 is cache2\nTrue\nIf the named key does not exist, InvalidCacheBackendError will be\nraised.
To provide thread-safety, a different instance of the cache backend will\nbe returned for each thread.
\nAs a shortcut, the default cache is available as\ndjango.core.cache.cache:
>>> from django.core.cache import cache\nThis object is equivalent to caches['default'].
The basic interface is:
\n>>> cache.set('my_key', 'hello, world!', 30)\n>>> cache.get('my_key')\n'hello, world!'\nkey should be a str, and value can be any picklable Python object.
The timeout argument is optional and defaults to the timeout argument\nof the appropriate backend in the CACHES setting (explained above).\nIt's the number of seconds the value should be stored in the cache. Passing in\nNone for timeout will cache the value forever. A timeout of 0\nwon't cache the value.
If the object doesn't exist in the cache, cache.get() returns None:
>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get('my_key')\nNone\nIf you need to determine whether the object exists in the cache and you have\nstored a literal value None, use a sentinel object as the default:
>>> sentinel = object()\n>>> cache.get('my_key', sentinel) is sentinel\nFalse\n>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get('my_key', sentinel) is sentinel\nTrue\ncache.get() can take a default argument. This specifies which value to\nreturn if the object doesn't exist in the cache:
>>> cache.get('my_key', 'has expired')\n'has expired'\nTo add a key only if it doesn't already exist, use the add() method.\nIt takes the same parameters as set(), but it will not attempt to\nupdate the cache if the key specified is already present:
>>> cache.set('add_key', 'Initial value')\n>>> cache.add('add_key', 'New value')\n>>> cache.get('add_key')\n'Initial value'\nIf you need to know whether add() stored a value in the cache, you can\ncheck the return value. It will return True if the value was stored,\nFalse otherwise.
If you want to get a key's value or set a value if the key isn't in the cache,\nthere is the get_or_set() method. It takes the same parameters as get()\nbut the default is set as the new cache value for that key, rather than\nreturned:
>>> cache.get('my_new_key') # returns None\n>>> cache.get_or_set('my_new_key', 'my new value', 100)\n'my new value'\nYou can also pass any callable as a default value:
\n>>> import datetime\n>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)\ndatetime.datetime(2014, 12, 11, 0, 15, 49, 457920)\nThere's also a get_many() interface that only hits the cache once.\nget_many() returns a dictionary with all the keys you asked for that\nactually exist in the cache (and haven't expired):
>>> cache.set('a', 1)\n>>> cache.set('b', 2)\n>>> cache.set('c', 3)\n>>> cache.get_many(['a', 'b', 'c'])\n{'a': 1, 'b': 2, 'c': 3}\nTo set multiple values more efficiently, use set_many() to pass a dictionary\nof key-value pairs:
>>> cache.set_many({'a': 1, 'b': 2, 'c': 3})\n>>> cache.get_many(['a', 'b', 'c'])\n{'a': 1, 'b': 2, 'c': 3}\nLike cache.set(), set_many() takes an optional timeout parameter.
On supported backends (memcached), set_many() returns a list of keys that\nfailed to be inserted.
You can delete keys explicitly with delete() to clear the cache for a\nparticular object:
>>> cache.delete('a')\nTrue\ndelete() returns True if the key was successfully deleted, False\notherwise.
If you want to clear a bunch of keys at once, delete_many() can take a list\nof keys to be cleared:
>>> cache.delete_many(['a', 'b', 'c'])\nFinally, if you want to delete all the keys in the cache, use\ncache.clear(). Be careful with this; clear() will remove everything\nfrom the cache, not just the keys set by your application.
>>> cache.clear()\ncache.touch() sets a new expiration for a key. For example, to update a key\nto expire 10 seconds from now:
>>> cache.touch('a', 10)\nTrue\nLike other methods, the timeout argument is optional and defaults to the\nTIMEOUT option of the appropriate backend in the CACHES setting.
touch() returns True if the key was successfully touched, False\notherwise.
You can also increment or decrement a key that already exists using the\nincr() or decr() methods, respectively. By default, the existing cache\nvalue will be incremented or decremented by 1. Other increment/decrement values\ncan be specified by providing an argument to the increment/decrement call. A\nValueError will be raised if you attempt to increment or decrement a\nnonexistent cache key.:
>>> cache.set('num', 1)\n>>> cache.incr('num')\n2\n>>> cache.incr('num', 10)\n12\n>>> cache.decr('num')\n11\n>>> cache.decr('num', 5)\n6\nYou can close the connection to your cache with close() if implemented by\nthe cache backend.
>>> cache.close()\nIf you are sharing a cache instance between servers, or between your\nproduction and development environments, it's possible for data cached\nby one server to be used by another server. If the format of cached\ndata is different between servers, this can lead to some very hard to\ndiagnose problems.
\nTo prevent this, Django provides the ability to prefix all cache keys\nused by a server. When a particular cache key is saved or retrieved,\nDjango will automatically prefix the cache key with the value of the\nKEY_PREFIX cache setting.
By ensuring each Django instance has a different\nKEY_PREFIX, you can ensure that there will be no\ncollisions in cache values.
When you change running code that uses cached values, you may need to\npurge any existing cached values. The easiest way to do this is to\nflush the entire cache, but this can lead to the loss of cache values\nthat are still valid and useful.
\nDjango provides a better way to target individual cache values.\nDjango's cache framework has a system-wide version identifier,\nspecified using the VERSION cache setting.\nThe value of this setting is automatically combined with the cache\nprefix and the user-provided cache key to obtain the final cache key.
By default, any key request will automatically include the site\ndefault cache key version. However, the primitive cache functions all\ninclude a version argument, so you can specify a particular cache\nkey version to set or get. For example:
>>> # Set version 2 of a cache key\n>>> cache.set('my_key', 'hello world!', version=2)\n>>> # Get the default version (assuming version=1)\n>>> cache.get('my_key')\nNone\n>>> # Get version 2 of the same key\n>>> cache.get('my_key', version=2)\n'hello world!'\nThe version of a specific key can be incremented and decremented using\nthe incr_version() and decr_version() methods. This\nenables specific keys to be bumped to a new version, leaving other\nkeys unaffected. Continuing our previous example:
>>> # Increment the version of 'my_key'\n>>> cache.incr_version('my_key')\n>>> # The default version still isn't available\n>>> cache.get('my_key')\nNone\n# Version 2 isn't available, either\n>>> cache.get('my_key', version=2)\nNone\n>>> # But version 3 *is* available\n>>> cache.get('my_key', version=3)\n'hello world!'\nAs described in the previous two sections, the cache key provided by a\nuser is not used verbatim -- it is combined with the cache prefix and\nkey version to provide a final cache key. By default, the three parts\nare joined using colons to produce a final string:
\ndef make_key(key, key_prefix, version):\n return '%s:%s:%s' % (key_prefix, version, key)\nIf you want to combine the parts in different ways, or apply other\nprocessing to the final key (e.g., taking a hash digest of the key\nparts), you can provide a custom key function.
\nThe KEY_FUNCTION cache setting\nspecifies a dotted-path to a function matching the prototype of\nmake_key() above. If provided, this custom key function will\nbe used instead of the default key combining function.
Memcached, the most commonly-used production cache backend, does not allow\ncache keys longer than 250 characters or containing whitespace or control\ncharacters, and using such keys will cause an exception. To encourage\ncache-portable code and minimize unpleasant surprises, the other built-in cache\nbackends issue a warning (django.core.cache.backends.base.CacheKeyWarning)\nif a key is used that would cause an error on memcached.
If you are using a production backend that can accept a wider range of keys (a\ncustom backend, or one of the non-memcached built-in backends), and want to use\nthis wider range without warnings, you can silence CacheKeyWarning with\nthis code in the management module of one of your\nINSTALLED_APPS:
import warnings\n\nfrom django.core.cache import CacheKeyWarning\n\nwarnings.simplefilter("ignore", CacheKeyWarning)\nIf you want to instead provide custom key validation logic for one of the\nbuilt-in backends, you can subclass it, override just the validate_key\nmethod, and follow the instructions for using a custom cache backend. For\ninstance, to do this for the locmem backend, put this code in a module:
from django.core.cache.backends.locmem import LocMemCache\n\nclass CustomLocMemCache(LocMemCache):\n def validate_key(self, key):\n """Custom validation, raising exceptions or warnings as needed."""\n ...\n...and use the dotted Python path to this class in the\nBACKEND portion of your CACHES setting.
So far, this document has focused on caching your own data. But another type\nof caching is relevant to Web development, too: caching performed by\n"downstream" caches. These are systems that cache pages for users even before\nthe request reaches your website.
\nHere are a few examples of downstream caches:
\nYour ISP may cache certain pages, so if you requested a page from\nhttps://example.com/, your ISP would send you the page without having to\naccess example.com directly. The maintainers of example.com have no\nknowledge of this caching; the ISP sits between example.com and your Web\nbrowser, handling all of the caching transparently.
Your Django website may sit behind a proxy cache, such as Squid Web\nProxy Cache (http://www.squid-cache.org/), that caches pages for\nperformance. In this case, each request first would be handled by the\nproxy, and it would be passed to your application only if needed.
Your Web browser caches pages, too. If a Web page sends out the\nappropriate headers, your browser will use the local cached copy for\nsubsequent requests to that page, without even contacting the Web page\nagain to see whether it has changed.
Downstream caching is a nice efficiency boost, but there's a danger to it:\nMany Web pages' contents differ based on authentication and a host of other\nvariables, and cache systems that blindly save pages based purely on URLs could\nexpose incorrect or sensitive data to subsequent visitors to those pages.
\nFor example, if you operate a Web email system, then the contents of the\n"inbox" page depend on which user is logged in. If an ISP blindly cached your\nsite, then the first user who logged in through that ISP would have their\nuser-specific inbox page cached for subsequent visitors to the site. That's\nnot cool.
\nFortunately, HTTP provides a solution to this problem. A number of HTTP headers\nexist to instruct downstream caches to differ their cache contents depending on\ndesignated variables, and to tell caching mechanisms not to cache particular\npages. We'll look at some of these headers in the sections that follow.
\nVary headersLink to this heading#The Vary header defines which request headers a cache\nmechanism should take into account when building its cache key. For example, if\nthe contents of a Web page depend on a user's language preference, the page is\nsaid to "vary on language."
By default, Django's cache system creates its cache keys using the requested\nfully-qualified URL -- e.g.,\n"https://www.example.com/stories/2005/?order_by=author". This means every\nrequest to that URL will use the same cached version, regardless of user-agent\ndifferences such as cookies or language preferences. However, if this page\nproduces different content based on some difference in request headers -- such\nas a cookie, or a language, or a user-agent -- you'll need to use the Vary\nheader to tell caching mechanisms that the page output depends on those things.
To do this in Django, use the convenient\ndjango.views.decorators.vary.vary_on_headers() view decorator, like so:
from django.views.decorators.vary import vary_on_headers\n\n@vary_on_headers('User-Agent')\ndef my_view(request):\n ...\nIn this case, a caching mechanism (such as Django's own cache middleware) will\ncache a separate version of the page for each unique user-agent.
\nThe advantage to using the vary_on_headers decorator rather than manually\nsetting the Vary header (using something like\nresponse['Vary'] = 'user-agent') is that the decorator adds to the\nVary header (which may already exist), rather than setting it from scratch\nand potentially overriding anything that was already in there.
You can pass multiple headers to vary_on_headers():
@vary_on_headers('User-Agent', 'Cookie')\ndef my_view(request):\n ...\nThis tells downstream caches to vary on both, which means each combination of\nuser-agent and cookie will get its own cache value. For example, a request with\nthe user-agent Mozilla and the cookie value foo=bar will be considered\ndifferent from a request with the user-agent Mozilla and the cookie value\nfoo=ham.
Because varying on cookie is so common, there's a\ndjango.views.decorators.vary.vary_on_cookie() decorator. These two views\nare equivalent:
@vary_on_cookie\ndef my_view(request):\n ...\n\n@vary_on_headers('Cookie')\ndef my_view(request):\n ...\nThe headers you pass to vary_on_headers are not case sensitive;\n"User-Agent" is the same thing as "user-agent".
You can also use a helper function, django.utils.cache.patch_vary_headers(),\ndirectly. This function sets, or adds to, the Vary header. For example:
from django.shortcuts import render\nfrom django.utils.cache import patch_vary_headers\n\ndef my_view(request):\n ...\n response = render(request, 'template_name', context)\n patch_vary_headers(response, ['Cookie'])\n return response\npatch_vary_headers takes an HttpResponse instance as\nits first argument and a list/tuple of case-insensitive header names as its\nsecond argument.
For more on Vary headers, see the official Vary spec.
\nOther problems with caching are the privacy of data and the question of where\ndata should be stored in a cascade of caches.
\nA user usually faces two kinds of caches: their own browser cache (a private\ncache) and their provider's cache (a public cache). A public cache is used by\nmultiple users and controlled by someone else. This poses problems with\nsensitive data--you don't want, say, your bank account number stored in a\npublic cache. So Web applications need a way to tell caches which data is\nprivate and which is public.
\nThe solution is to indicate a page's cache should be "private." To do this in\nDjango, use the cache_control() view\ndecorator. Example:
from django.views.decorators.cache import cache_control\n\n@cache_control(private=True)\ndef my_view(request):\n ...\nThis decorator takes care of sending out the appropriate HTTP header behind the\nscenes.
\nNote that the cache control settings "private" and "public" are mutually\nexclusive. The decorator ensures that the "public" directive is removed if\n"private" should be set (and vice versa). An example use of the two directives\nwould be a blog site that offers both private and public entries. Public\nentries may be cached on any shared cache. The following code uses\npatch_cache_control(), the manual way to modify the\ncache control header (it is internally called by the\ncache_control() decorator):
from django.views.decorators.cache import patch_cache_control\nfrom django.views.decorators.vary import vary_on_cookie\n\n@vary_on_cookie\ndef list_blog_entries_view(request):\n if request.user.is_anonymous:\n response = render_only_public_entries()\n patch_cache_control(response, public=True)\n else:\n response = render_private_and_public_entries(request.user)\n patch_cache_control(response, private=True)\n\n return response\nYou can control downstream caches in other ways as well (see RFC 7234 for\ndetails on HTTP caching). For example, even if you don't use Django's\nserver-side cache framework, you can still tell clients to cache a view for a\ncertain amount of time with the max-age\ndirective:
\nfrom django.views.decorators.cache import cache_control\n\n@cache_control(max_age=3600)\ndef my_view(request):\n ...\n(If you do use the caching middleware, it already sets the max-age with\nthe value of the CACHE_MIDDLEWARE_SECONDS setting. In that case,\nthe custom max_age from the\ncache_control() decorator will take\nprecedence, and the header values will be merged correctly.)
Any valid Cache-Control response directive is valid in cache_control().\nHere are some more examples:
no_transform=True
must_revalidate=True
stale_while_revalidate=num_seconds
no_cache=True
The full list of known directives can be found in the IANA registry\n(note that not all of them apply to responses).
\nIf you want to use headers to disable caching altogether,\nnever_cache() is a view decorator that\nadds headers to ensure the response won't be cached by browsers or other\ncaches. Example:
from django.views.decorators.cache import never_cache\n\n@never_cache\ndef myview(request):\n ...\nMIDDLEWARELink to this heading#If you use caching middleware, it's important to put each half in the right\nplace within the MIDDLEWARE setting. That's because the cache\nmiddleware needs to know which headers by which to vary the cache storage.\nMiddleware always adds something to the Vary response header when it can.
UpdateCacheMiddleware runs during the response phase, where middleware is\nrun in reverse order, so an item at the top of the list runs last during the\nresponse phase. Thus, you need to make sure that UpdateCacheMiddleware\nappears before any other middleware that might add something to the Vary\nheader. The following middleware modules do so:
SessionMiddleware adds Cookie
GZipMiddleware adds Accept-Encoding
LocaleMiddleware adds Accept-Language
FetchFromCacheMiddleware, on the other hand, runs during the request phase,\nwhere middleware is applied first-to-last, so an item at the top of the list\nruns first during the request phase. The FetchFromCacheMiddleware also\nneeds to run after other middleware updates the Vary header, so\nFetchFromCacheMiddleware must be after any item that does so.