The cache system requires a small amount of setup. Namely, you have to tell it where your cached data should live; whether in a database, on the filesystem or directly in memory. This is an important decision that affects your cache\u2019s performance.<\/p>\n
Your cache preference goes in the CACHES setting in your settings file.<\/p>\n
The fastest, most efficient type of cache supported natively by Django, Memcached is an entirely memory-based cache server, originally developed to handle high loads at LiveJournal.com and subsequently open-sourced by Danga Interactive. It\u2019s used by sites such as Facebook and Wikipedia to reduce database access and dramatically increase site performance.
\nMemcached runs as a daemon and is allotted a specified amount of RAM. All it does is provide a fast interface for adding, retrieving and deleting data in the cache. All data is stored directly in memory, so there\u2019s no overhead of database or filesystem usage.<\/p>\n
After installing Memcached itself, you\u2019ll need to install a Memcached binding. There are several Python Memcached bindings available; the two most common are python-memcached and pylibmc. To use Memcached with Django:<\/p>\n
In this example, Memcached is running on localhost (127.0.0.1) port 11211, using the python-memcached binding:<\/p>\n
CACHES = {
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.memcached.MemcachedCache’,
\n‘LOCATION’: ‘127.0.0.1:11211’,
\n}
\n}<\/p>\n
In this example, Memcached is available through a local Unix socket file \/tmp\/memcached.sock using the python-memcached binding:<\/p>\n
CACHES = {
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.memcached.MemcachedCache’,
\n‘LOCATION’: ‘unix:\/tmp\/memcached.sock’,
\n}
\n}<\/p>\n
One excellent feature of Memcached is its ability to share a cache over multiple servers. This means you can run Memcached daemons on multiple machines, and the program will treat the group of machines as a single cache, without the need to duplicate cache values on each machine. To take advantage of this feature, include all server addresses in LOCATION, either separated by semicolons or as a list.<\/p>\n
In this example, the cache is shared over Memcached instances running on IP address 172.19.26.240 and 172.19.26.242, both on port 11211:<\/p>\n
CACHES = {
\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}<\/p>\n
In the following example, the cache is shared over Memcached instances running on the IP addresses 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and 172.19.26.244 (port 11213):<\/p>\n
CACHES = {
\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}<\/p>\n
A final point about Memcached is that memory-based caching has a disadvantage: because the cached data is stored in memory, the data will be lost if your server crashes.<\/p>\n
Clearly, memory isn\u2019t intended for permanent data storage, so don\u2019t rely on memory-based caching as your only data storage. Without a doubt, none of the Django caching backends should be used for permanent storage \u2013 they\u2019re all intended to be solutions for caching, not storage \u2013 but we point this out here because memory-based caching is particularly temporary.<\/p>\n
Django can store its cached data in your database. This works best if you\u2019ve got a fast, well-indexed database server. To use a database table as your cache backend:<\/p>\n
In this example, the cache table\u2019s name is my_cache_table:<\/p>\n
CACHES = {
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.db.DatabaseCache’,
\n‘LOCATION’: ‘my_cache_table’,
\n}
\n}<\/p>\n
Creating The Cache Table<\/strong> – Before using the database cache, you must create the cache table with this command: This creates a table in your database that is in the proper format that Django\u2019s database-cache system expects. The name of the table is taken from LOCATION. If you are using multiple database caches, createcachetable creates one table for each cache. If you are using multiple databases, createcachetable observes the allow_migrate() method of your database routers. Like migrate, createcachetable won\u2019t touch an existing table. It will only create missing tables.<\/p>\n Multiple Databases<\/strong> – If you use database caching with multiple databases, you\u2019ll also need to set up routing instructions for your database cache table. For the purposes of routing, the database cache table appears as a model named CacheEntry, in an application named django_cache. This model won\u2019t appear in the models cache, but the model details can be used for routing purposes.<\/p>\n For example, the following router would direct all cache read operations to cache_replica, and all write operations to cache_primary. The cache table will only be synchronized onto cache_primary:<\/p>\n class CacheRouter(object): def db_for_read(self, model, **hints): def db_for_write(self, model, **hints): def allow_migrate(self, db, model): If you don\u2019t specify routing directions for the database cache model, the cache backend will use the default database. Of course, if you don\u2019t use the database cache backend, you don\u2019t need to worry about providing routing instructions for the database cache model.<\/p>\n The file-based backend serializes and stores each cache value as a separate file. To use this backend set BACKEND to ‘django.core.cache.backends.filebased.FileBasedCache’ and LOCATION to a suitable directory.<\/p>\n For example, to store cached data in \/var\/tmp\/django_cache, use this setting:<\/p>\n CACHES = { If you\u2019re on Windows, put the drive letter at the beginning of the path, like this:<\/p>\n CACHES = { The directory path should be absolute \u2013 that is, it should start at the root of your filesystem. It doesn\u2019t matter whether you put a slash at the end of the setting. Make sure the directory pointed to by this setting exists and is readable and writable by the system user under which your Web server runs. Continuing the above example, if your server runs as the user apache, make sure the directory \/var\/tmp\/django_cache exists and is readable and writable by the user apache.<\/p>\n This is the default cache if another is not specified in your settings file. If you want the speed advantages of in-memory caching but don\u2019t have the capability of running Memcached, consider the local-memory cache backend. To use it, set BACKEND to django.core.cache.backends.locmem.LocMemCache. For example:<\/p>\n CACHES = { The cache LOCATION is used to identify individual memory stores. If you only have one locmem cache, you can omit the LOCATION; however, if you have more than one local memory cache, you will need to assign a name to at least one of them in order to keep them separate.<\/p>\n Note that each process will have its own private cache instance, which means no cross-process caching is possible. This obviously also means the local memory cache isn\u2019t particularly memory-efficient, so it\u2019s probably not a good choice for production environments. It\u2019s nice for development.<\/p>\n Finally, Django comes with a dummy cache that doesn\u2019t actually cache \u2013 it just implements the cache interface without doing anything. This is useful if you have a production site that uses heavy-duty caching in various places but a development\/test environment where you don\u2019t want to cache and don\u2019t want to have to change your code to special-case the latter. To activate dummy caching, set BACKEND like so:<\/p>\n CACHES = { While Django includes support for a number of cache backends out-of-the-box, sometimes you might want to use a customized cache backend. To use an external cache backend with Django, use the Python import path as the BACKEND of the CACHES setting, like so:<\/p>\n CACHES = { If you\u2019re building your own backend, you can use the standard cache backends as reference implementations. You\u2019ll find the code in the django\/core\/cache\/backends\/ directory of the Django source. In this example, a filesystem backend is being configured with a timeout of 60 seconds, and a maximum capacity of 1000 items:<\/p>\n CACHES = {
\npython manage.py createcachetable<\/p>\n
\n“””A router to control all database cache operations”””<\/p>\n
\n# All cache read operations go to the replica
\nif model._meta.app_label in (‘django_cache’,):
\nreturn ‘cache_replica’
\nreturn None<\/p>\n
\n# All cache write operations go to primary
\nif model._meta.app_label in (‘django_cache’,):
\nreturn ‘cache_primary’
\nreturn None<\/p>\n
\n# Only install the cache model on primary
\nif model._meta.app_label in (‘django_cache’,):
\nreturn db == ‘cache_primary’
\nreturn None<\/p>\nFilesystem Caching<\/h3>\n
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.filebased.FileBasedCache’,
\n‘LOCATION’: ‘\/var\/tmp\/django_cache’,
\n}
\n}<\/p>\n
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.filebased.FileBasedCache’,
\n‘LOCATION’: ‘c:\/foo\/bar’,
\n}
\n}<\/p>\nLocal-Memory Caching<\/h3>\n
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.locmem.LocMemCache’,
\n‘LOCATION’: ‘unique-snowflake’
\n}
\n}<\/p>\nDummy Caching (For Development)<\/h3>\n
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.dummy.DummyCache’,
\n}
\n}<\/p>\nUsing A Custom Cache Backend<\/h3>\n
\n‘default’: {
\n‘BACKEND’: ‘path.to.backend’,
\n}
\n}<\/p>\n
\nWithout a really compelling reason, such as a host that doesn\u2019t support them, you should stick to the cache backends included with Django. They\u2019ve been well-tested and are easy to use.
\nCache Arguments
\nEach cache backend can be given additional arguments to control caching behavior. These arguments are provided as additional keys in the CACHES setting. Valid arguments are as follows:<\/p>\n\n
\n‘default’: {
\n‘BACKEND’: ‘django.core.cache.backends.filebased.FileBasedCache’,
\n‘LOCATION’: ‘\/var\/tmp\/django_cache’,
\n‘TIMEOUT’: 60,
\n‘OPTIONS’: {‘MAX_ENTRIES’: 1000}
\n}
\n}<\/p>\n\n\n