1, Django caching framework

When a dynamic website receives every user request, it will perform operations such as querying the database and rendering templates. These operations are much more expensive and not necessarily necessary than simply reading files from the file system.

Therefore, we can save the calculation results and directly return to the saved file next time. The way to save resources is caching.

django has its own cache system, which provides different levels of cache granularity: it can cache the output of specific views, the part with large amount of calculation, and even the whole website.

2, Set cache

We need to make settings to tell django where cache data should be placed. This is related to the performance of the cache.

2.1 Memcached

Memcached It is a fully memory based cache server and the fastest and most efficient cache type supported by Django natively. Sites such as Facebook and Wikipedia use it to reduce database access and significantly improve site performance.

Memcached runs as a daemon and is allocated a specified amount of RAM. What 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 is no overhead for database or file system use.

2.1.1 preparation

Memcached needs to be installed by ourselves. The installation method is very simple. Follow Official documents Just come.

After that, install python's memcached client. The two clients supported by Django are pylibmc and pymemcache (new in Django version 3.2).

2.1.2 setting Memcached

According to the installed client, set BACKEND to:

• django.core.cache.backends.memcached.PyMemcacheCache
• django.core.cache.backends.memcached.PyLibMCCache

Set LOCATION to one of the following:

• ip:port value:

  IP is the IP address of the Memcached daemon, and port is the running port of Memcached,

• unix:path value:

  Path is the path to the Memcached Unix socket file.

For example:

• Memcached runs in "127.0.0.1:11211", using pymemcache client:

  CACHES = {
      'default': {
          'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
          'LOCATION': '127.0.0.1:11211',
      }
  }
  

• Memcached through the local Unix socket file / TMP / memcached Sock uses pymemcache ` client:

  CACHES = {
      'default': {
          'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
          'LOCATION': 'unix:/tmp/memcached.sock',
      }
  }
  

2.1.3 using multiple Memcached servers

Memcached can share a cache on multiple servers, which means that we can run the memcached daemon on multiple machines, and the program will treat this group of machines as a single cache without repeating the cache value on each machine.

To use this feature, simply set multiple addresses in LOCATION:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': [
            '172.19.26.240:11211',
            '172.19.26.242:11211',
        ]
    }
}

2.1.4 disadvantages of memcached

Because the data cached by Memcached is stored in memory, if the server crashes, the data will be lost. So don't rely on memory based caching as your only data storage or storage.

2.2 database cache

Django can store cached data in the database. This caching works best if you have a fast, indexed database server.

The setting method is as follows:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',  # The name of the cache table
    }
}

Create cache table

Before using database caching, you must create a cache table through the following command:

python manage.py createcachetable

django will create a table in the database, and the table name of the table is taken from LOCATION.

If you are using multiple database caches, createcache table creates one table for each cache.

2.3 file system cache

The file based caching system serializes the cached data and saves each cached data as a separate file. Obviously, this cache is very slow, but you can barely use it if you don't have a better choice.

The settings are as follows:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',  # Save path of cache file
    }
}

If you use a Windows system, place the drive letter at the beginning of the path as follows:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': 'c:/foo/bar',
    }
}

The directory path should be absolute -- therefore, it should start with the root directory of the file system. Don't worry about whether you need to end with a slash.

2.4 local memory cache

If your local host memory is large and fast enough, you can also directly use it as a cache, and this is also the default cache backend used by Django. The settings are as follows:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'unique-snowflake',
    }
}

LOCATION is used to identify individual memory stores. If there is only one locmem cache, you can ignore LOCATION. However, if there are multiple local memory caches, at least one of them should be named to distinguish them.

2.5 virtual cache (for development mode)

Virtual cache only implements the cache interface and does not do other operations. If we need to use cache, but we don't want to use or can't use the corresponding cache system support in the development process, we can use virtual cache. The settings are as follows:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
    }
}

2.6 custom cache backend

If none of the above cache backend can meet our requirements, we can also customize the cache backend. When setting, you only need to set the back end as a custom back end:

CACHES = {
    'default': {
        'BACKEND': 'path.to.backend',
    }
}

For the customized method of caching backend, it is recommended to refer to the API in the official document: Portal

2.7 cache parameters

Cache parameters are used to control cache behavior. They are still set in CACHES. Details of parameters are as follows:

• TIMEOUT:

  The default expiration time of the cache, in seconds. The default is 300 seconds.

  Set to None to never expire; Setting to 0 means immediate failure (meaningless).

• OPTIONS:

  • MAX_ENTRIES: the maximum number of entries allowed to be cached before deleting old values. The default is 300.

  • CULL_FREQUENCY: when Max is reached_ The actual ratio of some items eliminated during entries is 1 / CULL_FREQUENCY .

    When set to 2, when Max is reached_ Entries will eliminate half of the entries (i.e 1 / 2 1/2 1/2). This parameter should be an integer. The default value is 3.

    When set to 0, it means that when Max is reached_ Entries, the entire cache will be emptied.

• KEY_PREFIX:

  The prefix of all cache keys is a string.

• VERSION:

  The default version number of the cache key generated by the Django server.

• KEY_FUNCTION:
  A string that contains the point separated path of a function that defines how the prefix, version, and key form a final cache key.

The following is a back-end configuration example based on pymemcache. It enables the client pool (to improve performance by maintaining client connections), treats memcache / network errors as cache failures, and sets TCP on the connected socket_ Nodelay flag:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': '127.0.0.1:11211',
        'OPTIONS': {
            'no_delay': True,
            'ignore_exc': True,
            'max_pool_size': 4,
            'use_pooling': True,
        }
    }
}

3, Cache site

After setting, the easiest way to use caching is to cache the entire website. The following two items need to be added to the MIDDLEWARE:

MIDDLEWARE = [
    'django.middleware.cache.UpdateCacheMiddleware',
    ......
    'django.middleware.cache.FetchFromCacheMiddleware',
]

Note: "update" middleware must be first in the list, and "fetch" middleware must be last!

Then, add the following to the project configuration file:

CACHE_MIDDLEWARE_ALIAS : Alias of the cache used for storage
CACHE_MIDDLEWARE_SECONDS : each page How many seconds does it need to be cached
CACHE_MIDDLEWARE_KEY_PREFIX : key When multiple sites use the same configuration, this setting can avoid conflicts

4, Cache view

The most common way to cache the framework is to cache the results of the view. django.views.decorators.cache defines a cache_page decorator, which will automatically cache the response of the view:

rom django.views.decorators.cache import cache_page

@cache_page(60 * 15)  # Cache validity in seconds
def my_view(request):
    ...

Like caching sites, view caching is also based on URL. If the routing configuration is as follows:

urlpatterns = [
    path('foo/<int:code>/', my_view),
]

Then the requests of / foo/1 / and / foo/23 / will be cached separately.

Specify the view cache in the route

The above method forcibly binds the view and cache framework together, increasing the coupling of the system. django provides another caching method to bind the caching framework to the url, so as to free the view, so that other sites that want to use the view but don't want to use the cache can also use the view at ease.

Using cache in URLconf_ page :

urlpatterns = [
    path('foo/<int:code>/', my_view),
]

I_ The view is included in the cache_ On page:

from django.views.decorators.cache import cache_page

urlpatterns = [
    path('foo/<int:code>/', cache_page(60 * 15)(my_view)),
]

5, Cache template fragment

django also provides caching support in the template syntax. Use the cache template tag to cache a part of the page:

{% load cache %}  This sentence should be placed at the top


{% cache 500 sidebar %}
    .. sidebar ..
{% endcache %}

Where 500 is the cache validity period (in seconds), "sidebar" is the name of the fragment and must be globally unique.