Django-Cache framework

Note: 1. Useless, boasting rhetoric is not translated; 2. Free Translation is inaccurate in many places.

The most important thing about dynamic websites is that webpages are dynamic. Every time a user requests a page, the website performs various computations-from database queries, to render templates, to various logical operations-required to generate pages. This process consumes resources abnormally, which is far more expensive than reading a file from the hard disk and then displaying it.

For most small and medium websites, this may not be a problem because they have a low access volume. For large websites, it is necessary to minimize unnecessary server resource costs.

Therefore, the cache technology is available.

Cache stores some computing results that consume a lot of resources. When it is needed next time, it does not need to be computed again and is directly retrieved from the cache, thus saving resources. The cached pseudo code is expressed as follows:

For the specified URL, check whether it exists in the cache;

If yes, return the cached page;

Otherwise:

Generate the page;

Save the page to the cache

Return page

Django's cache system is very robust ..... (For Some boast, the Translator's note ). In short, Django provides caches of different granularities: the cache of specific views, the cache of results of a time-consuming program segment, or the cache of the entire website.

Django can also work with some "upstream" caching technologies, such as squid and browser caching. You do not need to directly control these cache types, but you can use the HTTP head protocol to tell others how to cache those parts of the website.

Create Cache

Some settings are required for the cache system. You need to tell Django where your cache data is stored: file, database, or memory. Different caching methods have different performance.

In the settings. py file, set cache_backend. Below are some available cache_backend values:

Memcached

The fastest and most efficient cache currently.

Memcached's official website: All data in http://danga.com/memcached/ memcached is stored in memory, so there is no database consumption or file read consumption.

After installing memcached, you need to install memcached Python bindings. Currently, two editions are available:

The fastest choice is cmemcache, for http://gijsbert.org/cmemcache/

Django versions earlier than 1.0 are unavailable.

If you cannot installCmemcache, You can choose to installPython-memcached,: Ftp://ftp.tummy.com/pub/python-memcached/. If this URL has expired, go to the memcached official website (http://www.danga.com/memcached/), to "client APIs" to download Python bindings.

To use memcached, you only need to set cache_backend to the memcached: // ip: Port/format. The IP address is the IP address of the machine where the memcached service runs and the port is the port number of the memcached service listener.

For example, if the memcached service runs on the local machine and the port is 11211, the configuration statement is:

Cache_backend = 'memcached: // 127.0.0.1: 11211 /'

A good feature of memcached is that multiple hosts can share the cache. You only need to include the IP addresses and port numbers of all the hosts that provide the cache, and separate them by commas. Example:

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

Memcache may have a disadvantage, that is, because memcached is based on memory, when your server crash, all the cache data will be lost. However, because the cache itself is temporary, there is no major problem with the loss of cache data.

 

 

Translation: Django cache framework (2) (Django cache framework) [reprint] January 17,200 9 by admin · leave a comment
Filed under: Django

I searched on the Internet. Someone has translated this article.

Here: http://www.woodpecker.org.cn/obp/django/django-faq/cache.html

File System Cache

 

To save cache data in the file system, use the "file: //" cache type in cache_backend. in the following example, the cached data is saved in/var/tmp/django_cache and the settings are as follows:

 

Cache_backend = 'file: // var/tmp/django_cache'

Note: file is followed by three diagonal lines instead of two. The first two are file: // protocol, and the third is the first character of path/var/tmp/django_cache.

 

This directory path must be an absolute path-that is, it should start from the root of your file system. As to whether or not to add a slash to the path, Django does not care.

Make sure that the specified path exists and the Web server can read and write data. in the preceding example, if your server runs as an Apache user, make sure that the directory/var/tmp/django_cache exists and can be read and written by the user Apache.

 

Local Memory Cache

 

If you want the high performance of the memory cache but have no conditions to run memcached, you can use the local memory cache backend. the cache backend is multi-process and thread-safe. to use it, set cache_backend to "locmem :///". for example:

 

Cache_backend = 'locmem :///'

Simple cache (for development)

 

"Simple: //" is a simple memory cache type for a single process. It only saves cached data in the process, which means it is only applicable to development or test environments. Example:

 

Cache_backend = 'simple :///'

Virtual cache (for development)

 

Finally, Django also supports a "Dummy" cache (which is not actually cached)-only implements the cache interface but does not actually do anything.

 

Cache_backend Parameter

 

Parameters are accepted for all cache types. parameters are provided in a similar way to query string styles. All valid parameters are listed below:

 

Timeout

The default cache validity period, in seconds. The default value is 300 seconds (five minutes ).

Max_entries

It is used for simple caching and database cache backend. the maximum number of cached items is exceeded. The default value is 300 ).

Cull_percentage

The ratio of items to be retained when the maximum number of items in the cache is reached. the actual value saved is 1/cull_percentage. Therefore, setting cull_percentage = 3 will save the selected 1/3 entries, and the remaining entries will be deleted.

 

If the value of cull_percentage is set to 0, the entire cache is cleared when the maximum number of cached entries is reached. when the cache hit rate is very low, this will greatly improve the efficiency of the selected cache entries (not selected at all ).

In this example, timeout is set to 60:

 

Cache_backend = "memcached: // 127.0.0.1: 11211 /? Timeout = 60 ″

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

 

Cache_backend = "memcached: // 127.0.0.1: 11211 /? Timeout = 30 & max_entries = 400 ″

Invalid parameters are ignored.

 

Cache the entire site

 

After the cache type is set, the easiest way to use the cache is to cache the entire site. Add Django. Middleware. cache. cachemiddleware in the "middleware_classes" setting, just as in the following example:

 

Middleware_classes = (

"Django. Middleware. cache. cachemiddleware ",

"Django. Middleware. Common. commonmiddleware ",

)

(For details about the middleware_classes sequence, see "order of middleware_classes" below ")

 

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

 

Cache_middleware_seconds-Cache Time for each page.

Cache_middleware_key_prefix-if the cache is shared by multiple sites installed in the same Django, set the site name or some other unique strings here to avoid key conflicts. if you don't mind, you can also use an empty string.

Cache middleware caches every page without the get/post parameters. In addition, cachemiddleware automatically sets some headers in each httpresponse:

 

When requesting an Uncached page, set the last-modified header to the current date and time.

Set the Expires header to the current date and time plus the defined cache_middleware_seconds.

Set cache-control header to the lifetime of the page-the lifetime also comes from cache_middleware_seconds settings.

Refer to middleware documentation to learn more about middleware.

 

Cache a single view

 

Django can only cache specific pages. Django. Views. decorators. cache defines a cache_page modifier, which can automatically cache the response of the view. This modifier is extremely easy to use:

 

From Django. Views. decorators. cache import cache_page

 

Def slashdot_this (request ):

...

 

Slashdot_this = cache_page (slashdot_this, 60*15)

Alternatively, use the modifier Syntax of Python 2.4:

 

@ Cache_page (60*15)

Def slashdot_this (request ):

...

Cache_page only accepts one parameter: cache validity period, in seconds. In the preceding example, slashdot_this () view will be cached for 15 minutes.

 

Underlying cache API

 

In some cases, the cache of a complete page does not meet your requirements. for example, you think it is necessary to cache the results only for some high-intensity queries. to achieve this goal, you can use the underlying cache API to save objects to the cache system at any level.

 

The cache API is simple. Export a cache object automatically generated by cache_backend settings from the cache module Django. Core. cache:

 

>>> From Django. Core. cache import Cache

The basic interfaces are set (Key, value, timeout_seconds) and get (key ):

 

>>> Cache. Set ('My _ key', 'Hello, world! ', 30)

>>> Cache. Get ('My _ key ')

'Hello, world! '

The timeout_seconds parameter is optional and its default value is the timeout parameter of cache_backend. If this object is not included in the cache, cache. Get () returns none:

 

>>> Cache. Get ('some _ other_key ')

None

 

# Wait 30 seconds for 'My _ key' to expire...

 

>>> Cache. Get ('My _ key ')

None

Get () can accept a default parameter:

 

>>> Cache. Get ('My _ key', 'has expired ')

'Has expired'

Of course, there is also a get_keys () interface, which only hits the cache once. get_keys () returns a dictionary, including all the keys actually present in your request that have not expired .:

 

>>> Cache. Set ('A', 1)

>>> Cache. Set ('B', 2)

>>> Cache. Set ('C', 3)

>>> Cache. get_many (['A', 'B', 'C'])

{'A': 1, 'B': 2, 'C': 3}

Finally, you can use the delete () Explicit delete key, which is a simple way to clear a specific object in the cache:

 

>>> Cache. Delete ('A ')

This is the case. The cache mechanism has very few restrictions: You can safely cache arbitrary objects that can be pickled (The key must be a string ).

 

Upstream caches

 

So far, our eyes have only focused on your own data. There is another type of cache in Web development:

 

"Upstream" cache. This is the cache implemented by the browser when the user request has not arrived at your site.

 

Below are several examples of upstream cache:

 

Your ISP will cache a specific page. When you request a page in somedomain.com, your ISP will directly send you a cache page (not accessing somedomain.com ).

Your Django web site may be built on a squid (http://www.squid-cache.org/) Web Proxy Server that caches pages to improve performance. in this case, each request is first processed by squid, and it will pass the request to your application only when necessary.

Your browser also caches some pages. If a Web page sends the correct headers, the browser uses a local (cached) copy to respond to the requests sent to the same page.

Upstream cache is a very effective promotion, but it also has considerable shortcomings: many web pages are based on authorization and a bunch of variables, and this cache system blindly relies solely on URL cache pages, this may expose sensitive information to inappropriate users.

 

For example, if you use a web e-mail system, the content on the "inbox" Page obviously depends on the current login user. if an ISP blindly caches your site, then users will see the inbox of the previous user. This is not an interesting thing.

 

Fortunately, HTTP provides a solution to this problem: a series of HTTP headers are used to build a cache mechanism to differentiate the cached content, so that the cache system will not cache certain pages.

 

Use vary Headers

 

One of the headers is vary. it defines the request headers for the cache mechanism when the cache key is created. for example, if the content of a webpage depends on the language settings of a user, the webpage is notified of "vary on language."

 

By default, Django's cache system uses the Request Path to create a cache key-for example, "/stories/2005/Jun/23/bank_robbed /". this means that each request of the URL uses the same Cache version, regardless of the user agent. (cookies and language features ).

 

Therefore, we need vary.

 

If your Django-based page outputs different content based on different request headers-such as a cookie or language, or user proxy-you will need to use vary header to tell the cache system that the page output depends on these items.

 

To do this in Django, use the vary_on_headers view modifier, as shown below:

 

From Django. Views. decorators. Vary import vary_on_headers

 

# Python 2.3 syntax.

Def my_view (request ):

...

My_view = vary_on_headers (my_view, 'user-agent ')

 

# Python 2.4 decorator syntax.

@ Vary_on_headers ('user-agent ')

Def my_view (request ):

...

In this way, the cache system (such as Django's own cache middleware) caches pages of different versions for different user proxies. the advantage of using the vary_on_headers modifier is that (compared with manually setting vary headers: using similar response ['vary '] = 'user-agent ') the modifier is added to the vary header (which may already exist) instead of overwriting it.

 

You can also pass multiple headers to vary_on_headers ():

 

@ Vary_on_headers ('user-agent', 'cooker ')

Def my_view (request ):

...

Because multiple cookies are quite common, there is a vary_on_cookie modifier. The following two views are equivalent:

 

@ Vary_on_cookie

Def my_view (request ):

...

 

@ Vary_on_headers ('cooker ')

Def my_view (request ):

...

Note that the parameters passed to vary_on_headers are case-insensitive. "User-Agent" and "User-Agent" are identical.

 

You can also directly use a help function, Django. utils. cache. patch_vary_headers:

 

From Django. utils. cache import patch_vary_headers

Def my_view (request ):

...

Response = render_to_response ('template _ name', context)

Patch_vary_headers (response, ['cooker'])

Return response

Patch_vary_headers accepts an httpresponse instance as its first parameter and a header name list or tuple as its second parameter.

 

For more information about vary headers, see Official vary spec.

Cache Control: another problem with using other headers caches is data privacy and data storage in waterfall cache mode.

 

Users often have two types of cache: their own browser cache (Private cache) and the cache provided by the site (Public cache ). A public cache is used for multiple users, and its content is controlled by another user. this causes Data Privacy: You certainly do not want your bank account to be stored in the public cache. therefore, applications need to tell the cache system what is private and what is public.

 

The solution is to declare that the cache of a page is "private". In Django, use the cache_control view modifier. Example:

 

From Django. Views. decorators. cache import cache_control

@ Cache_control (Private = true)

Def my_view (request ):

...

This modifier will carefully send appropriate HTTP headers behind the scenes to avoid the above problems.

 

There are other ways to control cache parameters. For example, HTTP allows applications to do the following:

 

Defines the maximum time for a page to be cached. specify whether the cache always needs to check the new version. If there is no change, only the Cache version is transferred. (some caches only pass the cached version even if the server page changes-just because the cache copy has not expired ).

In Django, use the cache_control view modifier to specify the cache parameters. In this example, cache_control notifies the cache to check the Cache version each time until the cache expires in 3600 seconds:

 

From Django. Views. decorators. cache import cache_control

@ Cache_control (must_revalidate = true, max_age = 3600)

Def my_view (request ):

...

All valid cache-control HTTP commands are valid in cache_control (). The following is a complete command list:

 

Public = true

Private = true

No_cache = true

No_transform = true

Must_revalidate = true

Proxy_revalidate = true

Max_age = num_seconds

S_maxage = num_seconds

For details about the cache-control HTTP command, see cache-control spec.

 

(Note that the cache middleware has set the max-age of the cache header by setting the cache_middleware_settings value. if you use a custom max_age in the cache_control modifier, the settings in the modifier will be used first, and the header values will be correctly merged)

 

Other Optimizations

 

Django comes with some middleware to help you improve site performance:

 

Django. Middleware. http. conditionalgetmiddleware adds conditional get support. It uses etag and last-modified headers.

Django.middleware.gzip. gzipmiddleware compresses the sent content in a gzip-enabled browser (all popular browsers support this ).

Middleware_classes Sequence

 

If you use cachemiddleware, it is important to use the correct sequence in the middleware_classes settings. the cache middleware needs to know which headers are stored in the cache. middleware always adds something to the vary Response Header whenever possible.

 

Put cachemiddleware to another middleware that may add something to the vary header. The following middleware will add something to the vary header:

 

Sessionmiddleware adds cookie

Accept-encoding added to gzipmiddleware

Django-Cache framework