Django Cache mechanism

Static website content is stored directly on the server by some simple static webpages, which can easily reach amazing access volumes. However, a dynamic website is dynamic. that is to say, every time a user accesses a page, the server needs to execute database queries, start the Template, execute the business logic, and finally generate a webpage you can see, all of these are dynamically and instantly generated. From the processor resource point of view, this is relatively expensive. Static website content is stored directly on the server by some simple static webpages, which can easily reach amazing access volumes. However, a dynamic website is dynamic. that is to say, every time a user accesses a page, the server needs to execute database queries, start the Template, execute the business logic, and finally generate a webpage you can see, all of these are dynamically and instantly generated. From the processor resource point of view, this is relatively expensive.

For most network applications, overload is not a major problem. Because most network applications are not mongoingtopost.com or Slashdot; they are usually very small and simple, or medium-sized sites, with only a small amount of traffic. However, it is necessary for medium-to large-scale traffic sites to solve the overload problem as much as possible. This requires caching.

The purpose of caching is to avoid repeated computation, especially for time-consuming and resource-consuming computation. The following code demonstrates how to cache the results of dynamic pages.

given a URL, try finding that page in the cacheif the page is in the cache:return the cached pageelse:generate the pagesave the generated page in the cache (for next time)return the generated page

Therefore, Django provides a stable cache system that allows you to cache the results of dynamic pages. in this way, you can directly use the data in the cache with the same request to avoid unnecessary repeated computation. In addition, Django also provides data caching at different granularities. for example, you can cache the entire page, a part, or even the entire website.

Django also works well with "upstream" caches, such as Squid (http://www.squid-cache.org) and browser-based caches that you don't directly control, however, you can provide clues (through the HTTP header) about which part of your site should be cached and how it will be cached to them.

Continue to study how to use Django's cache system. When your website becomes like Slashdot, you will be very happy to understand this part of the materials.

Set cache

The cache system requires a small amount of setup, that is, you must tell it where your cache data is-in the database, file system, or directly in the memory, this is an important decision that affects your cache performance. Yes, some cache types are faster than others, and the memory cache is usually faster than the file system or database cache, because the former does not access the file system or the database is over-connected

Your cache is selected in the CACHE_BACKEND settings of your settings file. if you use the cache but do not specify CACHE_BACKEND, Django uses simple: // by default :///, the following describes all the values available for CACHE_BACKEND.

Memory buffer

So far, Django can obtain the fastest and most efficient cache type, namely the memory-based cache framework Memcached, which was initially developed to handle high loads for LiveJournal.com and subsequently developed by Danga
Interactive (http://www.danga.com) open source, which is used by sites such as Slashdot and Wikipedia to reduce database access and dramatic increase in site performance

Memcached can be

After installing Memcached itself, you will need to install MemcachedPython binding, which is not directly bound to Django. these are bound to a separate Python module, 'memcache. py', which can be found in Ghost

Set CACHE_BACKEND to memcached: // ip: port/For Django to use Memcached. here, the ip address is the ip address of the Memcached background process, and the port is the port on which Memcached runs.

In this example, Memcached runs on the local host (127.0.0.1) and port 11211:

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

An excellent feature of Memcached is its ability to share the cache on multiple servers, which means you can run the Memcached process on multiple machines, the program will treat this set of machines as a * separate * cache, instead of copying the cache value on each machine. in order for Django to take advantage of this feature, all server addresses must be included in CACHE_BACKEND and separated by semicolons.

In this example, the cache is shared between IP addresses running on 172.19.26.240 and 172.19.26.242 and Memcached instances running on port 11211:

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

In this example, the cache is shared among Memcached instances running on 172.19.26.240 (port 11211), 172.19.26.242 (Port 11212), and 172.19.26.244 (Port 11213:

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

Finally, Memcached has a major drawback in memory-based caching. because the cached data is only stored in the memory, data will be lost if the server crashes, obviously, the memory is not prepared for persistent data storage. Django does not have a cache backend for persistent storage. they are all cache solutions, not storage. but here we point out that the memory-based cache is particularly short-lived.
.

Database cache

To use a database table as the cache backend, you must create a cache table in the database and direct the Django cache system to the table.

First, use the following statement to create a cache data table:

Python manage. py createcachetable [cache_table_name]

[Cache_table_name] indicates the name of the database table to be created. The name can be whatever you want, as long as it is legal that this command is not used in your database to create a separate table that complies with the expected form of the Django database cache system.

Once you create a database table, set your CACHE_BACKEND to "db: // tablename". here, tablename is the name of the database table. In this example, the name of the cache table is my_cache_table:

CACHE_BACKEND = 'DB: // my_cache_table'

The database cache backend uses the same database specified by your settings file. you cannot use different backend databases for your cache tables.

File system cache

Use the "file: //" cache type as CACHE_BACKEND and specify the file system directory for storing cached data to store cached data in the file system.

For example, use the following settings to store cached data in/var/tmp/django_cache:

CACHE_BACKEND = 'File: // var/tmp/django_cache'

Note that there are three front slashes in the example, the first two are file: //, the third is the first character of the directory path,/var/tmp/django_cache, if you are using a Windows system, put the drive letter behind file: //, like this: 'File: // c:/foo/bar '.

The directory path should be an absolute * path, that is, it should start with the root of your file system. it doesn't matter whether you place a slash at the end of the setting.

Make sure that the directory to which the setting points exists and that the user of the system running on your Web server can read and write the directory. continue with the example above. if your server runs in apache, check whether/var/tmp/django_cache exists and apache can read/write/var/tmp/django_cache directory.

Each cached value is stored as a separate file, whose content is the cache data stored by the Python pickle module in the form of serialization ("pickled"). the file name of each file is the cache key, release for secure file systems

Local memory cache

If you want the speed advantage of memory cache but do not have the ability to run Memcached, you can consider using local memory to cache the backend. this cache is multi-thread and thread-safe, however, because of its simple lock and memory allocation policies, it does not have Memcached efficiency.

Set CACHE_BACKEND to locmem: // to use it. for example:

CACHE_BACKEND = 'locmem :///'

Simple cache (for development)

You can configure 'simple: // 'to use a simple single-process memory cache, for example:

CACHE_BACKEND = 'simple :///'

This cache only saves data in the process, so it should be used only in the development environment or test environment.

Simulation cache (for development)

Finally, Django provides a false cache setting: it only implements the cache interface and does not do anything practical.

This is a useful feature. if your online site uses a lot of heavy caches but does not want to use them in the development environment, you only need to modify the configuration file, set CACHE_BACKEND to 'dummy: // '. for example:

CACHE_BACKEND = 'dummy :///'

The result is that your development environment does not use the cache, and the online environment is still using the cache.

CACHE_BACKEND parameter

Each cache backend may use parameters. they are provided as query strings in CACHE_BACKEND settings. Valid parameters are:

Timeout: the cache expiration time, in seconds. This parameter is set to 300 seconds (five minutes) by default)

Max_entries: for the cache of simple, local-memory and database types, this parameter specifies the maximum number of entries in the cache. if the number is greater than this, the old entries will be deleted. This parameter is 300 by default.

Cull_frequency: the percentage of access received when max_entries is reached. The actual ratio is 1/cull_frequency, so setting cull_frequency = 2 is to remove half of the cache when max_entries reaches.

Setting the value of cull_frequency to 0 means that when max_entries is reached, the cache will be cleared. This will greatly increase the access speed at the cost of a lot of cache loss. The default value is 3.

In this example, timeout is set to 60.

CACHE_BACKEND = "locmem :///? Timeout = 60"

In this example, set timeout to 30 and max_entries to 400:

CACHE_BACKEND = "locmem :///? Timeout = 30 & max_entries = 400"

Invalid parameters and invalid parameter values are ignored.

Site-level Cache

Once you specify "CACHE_BACKEND", the easiest way to use the cache is to cache your entire website. This means that all pages that do not contain the GET or POST parameters will be cached for a specified period of time after the first request.

To activate the cache for each site, add '''django. middleware. cache. CacheMiddleware ''' to the settings of MIDDLEWARE_CLASSES, as shown below:

MIDDLEWARE_CLASSES = ('django.middleware.cache.CacheMiddleware','django.middleware.common.CommonMiddleware',)

Note:

About the MIDDLEWARE_CLASSES sequence. See the MIDDLEWARE_CLASSES sequence section after this chapter.

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

CACHE_MIDDLEWARE_SECONDS: the number of seconds that each page should be cached.

§ "CACHE_MIDDLEWARE_KEY_PREFIX": if the cache is shared by multiple websites installed with the same Django, set this value to the current website name or a unique string that can represent the Django instance, to avoid key conflicts. If you don't care about it, you can set it to a null string.

Cache middleware caches each page without the GET or POST parameters. that is, if the user requests the page and passes the GET or POST parameters in the query string, the middleware will not try to obtain the cached version page, if you plan to use the whole site cache, remember this when designing your program. for example, do not use URLs with query strings unless those pages can not be cached.

Cache middleware (cache middleware) supports another setting option, CACHE_MIDDLEWARE_ANONYMOUS_ONLY. If you set it to "True", the cache middleware will only cache anonymous requests. anonymous requests refer to requests initiated by users who have not logged on. If you want to cancel a user-related page
Pages) cache, such as the Djangos management interface, is a simple and effective method. In addition, if you want to use the CACHE_MIDDLEWARE_ANONYMOUS_ONLY option, you must first activate AuthenticationMiddleware, that is, where your configuration file MIDDLEWARE_CLASSES, AuthenticationMiddleware must appear before CacheMiddleware.

Finally, we will remind you that CacheMiddleware will automatically set some headers in each HttpResponse)

§ Set the Last-Modified header to the current date/time when a new (uncached) page is requested

§ Set the Expires header to the current date/time plus the defined CACHE_MIDDLEWARE_SECONDS

§ Set the Cache-Control header to give the page the maximum time-once again, according to CACHE_MIDDLEWARE_SECONDS settings

View-level cache

A more granular cache framework is used to cache the output of a single view. This has the same effect as the full-site cache (including ignoring GET and POST
Parameter request cache ). It is applied to the view you specified, not the whole site.

The modifier is used to wrap the View function and convert its behavior to use the cache. The View cache modifier is called cache_page and is located in the django. views. decorators. cache module. for example:

from django.views.decorators.cache import cache_pagedef my_view(request, param):# ...my_view = cache_page(my_view, 60 * 15)

If Python 2.4 or later is used,
You can also use the decorator syntax. This example is equivalent to the previous one:

from django.views.decorators.cache import cache_page@cache_page(60 * 15)def my_view(request, param):# ...

Cache_page only accepts one parameter: cache timeout in seconds. In the response, the results of the "my_view ()" view will be cached for 15
Minutes. (Note: to improve readability, this parameter is written as 60*15. 60*15 is calculated as 900, that is, 15 minutes multiplied by every minute
60 seconds .)

Like the site cache, the View Cache has nothing to do with the URL. If multiple URLs
Point to the same view, and each view is cached separately. Continue to the my_view example. if URLconf is as follows:

urlpatterns = ('',(r'^foo/(/d{1,2})/$', my_view),)

As expected, requests sent to/foo/1/and/foo/23/will be cached separately. However, once a specific request (such as/foo/23/) is sent
The URL request will be cached.

Specify view cache in URLconf

The example in the previous section hardcoded the view to use the cache, because cache_page converts the my_view function at an appropriate position. This method coupling the view with the cache system, which is not ideal in several aspects. For example, you may want to reuse the View function on a site without caching, or you may want to publish the view to those who do not want to use it through caching. To solve these problems
Specify the View Cache in URLconf, instead of being specified by these View functions.

It is very easy to do this: a cache_page is simply wrapped when these View functions are used in URLconf. The following are

URLconf: urlpatterns = ('', (r' ^ foo/(/d {1, 2})/$ ', my_view),) The following is the same URLconf, however, cache_page is used to wrap my_view: from django. views. decorators. cache import cache_pageurlpatterns = ('', (r' ^ foo/(/d {1, 2})/$ ', cache_page (my_view, 60*15 )),)

If you use this method, do not forget
Import cache_page.

Low-level cache API

In some cases, caching the entire parsed page won't bring you too much. In fact, it may be too late.

For example, a view in your site may depend on several time-consuming queries, and the results may change at intervals. In this case, the whole page cache provided by the site-level cache or view-level cache policy is not optimal, because you may not want to cache the entire result (because some data changes frequently), but you still want to cache the few changes.

In such a case, Django shows a simple, low-level cache in the django. core. cache module.
API. You can use this low-level cache API to store objects at any level in the cache. You can perform pickle processing on all
Cache Python objects: a list of strings, dictionaries, and model objects.