The remaining question about caching is the privacy of the data and the question of where the data should be stored in the cascading cache.
Typically the user will face two caches: his or her own browser cache (private cache) and his or her provider cache (public cache). The public cache is used by multiple users and is controlled by someone else. This creates a problem with sensitive data that you don't want to encounter, such as your bank account is stored in the public cache. Therefore, the WEB application needs to somehow tell the cache which data is private and which is public.
The solution is to indicate that a page cache should be private. To do this work in Django, you can use the Cache_control view decorator: for example:
From Django.views.decorators.cache import Cache_control@cache_control (private=true) def my_view (Request): # ...
The decorator is responsible for sending the appropriate HTTP headers in the background.
There are other ways to control cache parameters. For example, HTTP allows an application to perform the following actions:
- Defines the maximum time that a page can be cached.
- Specifies whether a cache always checks for a newer version and passes the cached content only if no updates are available. (some caches still deliver cached content even if the server page changes, because the cached copy is not expired.) )
In Django, these cache parameters can be specified using the Cache_control view decorator. In this example, Cache_control tells the cache to re-validate the cache for each access and save the cached version for a maximum of 3,600 seconds:
From Django.views.decorators.cache import Cache_control@cache_control (Must_revalidate=true, max_age=3600) def My_ View (Request): # ...
In Cache_control (), any legitimate Cache-control HTTP instructions are valid. The following is a complete 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
The cache middleware has set the cache header Max-age with the Cache_middleware_settings setting. If you use a custom max_age in the Cache_control decorator, the decorator will take precedence and the value of the header will be correctly merged.
If you want to completely disable the cache with your head, the Django.views.decorators.cache.never_cache decorator can add header information that ensures that the response is not cached. For example:
From Django.views.decorators.cache import never_cache@never_cachedef myview (Request): # ...
Other optimizations
Django comes with some other middleware to help you optimize your application's performance:
- Django.middleware.http.ConditionalGetMiddleware adds conditional support for modern browsers with get responses based on ETag and last-modified headers.
- Django.middleware.gzip.GZipMiddleware compresses response content for all modern browsers to conserve bandwidth and transfer time.
Order of the Middleware_classes
If you use cache middleware, be aware that it is configured correctly in the Middleware_classes settings. Because the cache middleware needs to know what header information is differentiated by which buffers. Middleware always wants to add information to the vary response header whenever possible.
The updatecachemiddleware runs at the appropriate stage. Because middleware runs in reverse order, the middleware at the top of all lists runs last at the end of the corresponding phase. All, you need to make sure that Updatecachemiddleware is ranked before any middleware that might add information to the vary header. This is how the following middleware modules are:
- Sessionmiddleware of adding cookies
- Add Accept-encoding's Gzipmiddleware
- Add Accept-language's Localemiddleware
On the other hand, Fetchfromcachemiddleware runs in the request phase, when the middleware executes sequentially, so the items at the top of the list are executed first. Fetchfromcachemiddleware also needs to run after the middleware that modifies the vary head, so fetchfromcachemiddleware must be placed behind them.