Mécanisme de mise en cache Django

Le contenu des sites Web statiques est de simples pages Web statiques stockées directement sur le serveur, qui peuvent facilement générer un nombre incroyable de visites. Mais les sites Web dynamiques sont dynamiques, ce qui signifie que chaque fois qu'un utilisateur visite une page, le serveur doit effectuer des requêtes dans la base de données, démarrer des modèles, exécuter une logique métier et enfin générer la page Web que vous avez dit avoir vue. Tout cela est généré dynamiquement et. immédiatement. Du point de vue des ressources du processeur, cela est relativement coûteux.

Pour la plupart des applications Web, la surcharge n'est pas un gros problème. Parce que la plupart des applications Web ne sont pas washingtopost.com ou Slashdot ; ce sont généralement des sites petits et simples, ou de taille moyenne, avec très peu de trafic. Mais pour les sites à trafic moyen à important, il est nécessaire de résoudre au maximum le problème de surcharge. Cela nécessite l'utilisation du cache.

Le but de la mise en cache est d'éviter les calculs répétés, notamment pour certains calculs qui prennent plus de temps et de ressources. Le code ci-dessous montre comment mettre en cache les résultats d'une page dynamique.

given a URL, try finding that page in the cache
if the page is in the cache:
return the cached page
else:
generate the page
save the generated page in the cache (for next time)
return the generated page

À cette fin, Django fournit un système de mise en cache stable qui vous permet de mettre en cache les résultats des pages dynamiques, afin que les requêtes identiques ultérieures puissent utiliser directement les données du cache pour éviter les duplications inutiles. De plus, Django fournit également une mise en cache des données à différentes granularités. Par exemple, vous pouvez mettre en cache la page entière, une certaine partie ou même l'intégralité du site Web.

Django fonctionne également bien avec les caches « en amont », tels que Squid (http://www.squid-cache.org) et les caches basés sur un navigateur, qui types de mise en cache Vous ne contrôlez pas directement, mais vous pouvez leur fournir des indices (via les en-têtes HTTP) sur les parties de votre site qui doivent être mises en cache et comment

Continuer Lisez la suite pour apprenez à utiliser le système de mise en cache de Django. Vous serez heureux d'avoir compris ce matériel lorsque votre site ressemblera à Slashdot

Configuration de la mise en cache

La mise en cache Le système nécessite quelques travaux de configuration mineurs, c'est-à-dire que vous devez lui indiquer où se trouvent vos données mises en cache - dans la base de données, le système de fichiers ou directement en mémoire. Il s'agit d'une décision importante qui affecte les performances de votre cache, oui, certains types de cache le sont. plus rapides que les autres, les caches en mémoire sont généralement plus rapides que les caches de système de fichiers ou de base de données, car les premiers n'ont pas la surcharge liée à l'accès à un système de fichiers ou à une base de données

votre cache Sélectionnez le paramètre CACHE_BACKEND dans votre fichier de paramètres Si vous utilisez la mise en cache mais ne spécifiez pas CACHE_BACKEND, Django utilisera par défaut simple:///. Toutes les valeurs disponibles pour CACHE_BACKEND sont expliquées ci-dessous

.

Mémoire cache

De loin le type de cache le plus rapide et le plus efficace disponible pour Django est le framework de mise en cache basé sur la mémoire Memcached, qui a été initialement développé pour LiveJournal .com gère des charges élevées et a ensuite été open source par Danga
Interactive (http://www.danga.com), qui est utilisé par des sites comme Slashdot et Wikipedia pour réduire l'accès aux bases de données et augmenter considérablement les performances du site

Memcached est disponible gratuitement sur http://danga.com/memcached/, il s'exécute en arrière-plan et alloue une quantité spécifiée de RAM. Il vous fournit des résultats ultra-rapides dans le cache. Ajoutez, obtenez et supprimez des données arbitraires le plus rapidement possible, toutes les données sont stockées directement en mémoire, il n'y a donc pas de surutilisation des bases de données et des systèmes de fichiers

avec Memcached installé après lui-même , vous devrez installer les liaisons MemcachedPython, qui ne sont pas directement fournies avec Django, ces liaisons se trouvent dans un module Python distinct, 'memcache.py', disponible sur http://www.djangoproject.com/thirdparty/ python-memcached obtient

Définissez CACHE_BACKEND sur memcached://ip:port/ pour permettre à Django d'utiliser Memcached. L'adresse IP ici est l'adresse IP du processus d'arrière-plan Memcached, et le port est. Le port sur lequel Memcached s'exécute

Dans cet exemple, Memcached s'exécute sur l'hôte local (127.0.0.1) et le port est 11211 :

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

L'une des fonctionnalités intéressantes de Memcached est sa capacité à partager le cache sur plusieurs serveurs, ce qui signifie que vous pouvez exécuter le processus Memcached sur plusieurs machines. Le groupe de machines sera traité comme un cache *unique*, sans qu'il soit nécessaire de copier la valeur du cache sur chaque machine. Pour que Django puisse profiter de cette fonctionnalité, vous devez inclure toutes les adresses de serveur dans CACHE_BACKEND séparées par des points-virgules <🎜. >

Dans cet exemple, le cache est partagé entre les instances Memcached exécutées sur les adresses IP 172.19.26.240 et 172.19.26.242 et le port 11211 :

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

Dans cet exemple, le cache fonctionne sur 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), 172.19.26.244 ( port 11213) Partage entre instances Memcached :

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

La dernière chose à propos de Memcached est que la mise en cache basée sur la mémoire présente un inconvénient majeur, car les données mises en cache ne sont stockées qu'en mémoire, elles seront alors perdues si le serveur tombe en panne. Évidemment, la mémoire n'est pas préparée pour le stockage de données persistant, et. Django n'a pas de cache. Le backend est utilisé pour le stockage persistant. Ce sont des solutions de mise en cache, pas de stockage. Mais nous le soulignons ici car la mise en cache basée sur la mémoire est particulièrement de courte durée
.

<🎜. >

Cache de base de données

Afin d'utiliser une table de base de données comme backend de cache, vous devez créer une table de cache dans la base de données et pointer le cache de Django système à cette table

Tout d'abord, utilisez l'instruction suivante pour créer une table de données de cache :

python manage.py createcachetable [cache_table_name]

Le [cache_table_name] ici consiste à créer un nom de table de base de données. Le nom peut être celui que vous voulez, tant qu'il est légal dans votre base de données et n'a pas été utilisé. Cette commande crée une table distincte dans votre base de données qui suit le. forme attendue par le système de mise en cache de base de données de Django.

Une fois que vous avez créé la table de base de données, définissez votre CACHE_BACKEND sur "db://tablename", où tablename est le nom de la table de base de données, dans cet exemple, le cache Le nom de la table est my_cache_table :

CACHE_BACKEND = 'db://my_cache_table'

Le backend du cache de base de données utilise la même base de données spécifiée dans votre fichier de paramètres. Vous ne pouvez pas en utiliser une autre pour votre table de cache.

Cache du système de fichiers

Utilisez "fichier". ://" tapez le cache CACHE_BACKEND et spécifiez le répertoire du système de fichiers pour stocker les données du cache dans le système de fichiers.

Par exemple, utilisez les paramètres suivants pour stocker les données du cache dans / var/tmp/django_cache:

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

Notez qu'il y a trois barres obliques au début de l'exemple, les deux premières sont file://, et le troisième est le chemin du répertoire. Le premier caractère, /var/tmp/django_cache, si vous utilisez le système Windows, placez la lettre du lecteur après file://, comme ceci : 'file://c:/ foo/bar'.

Les chemins de répertoire doivent être des chemins *absolus*, c'est-à-dire qu'ils doivent commencer à la racine de votre système de fichiers, peu importe que vous mettiez un barre oblique à la fin du paramètre ou non.

Confirmez que le répertoire pointé par ce paramètre existe et que le répertoire est lisible et inscriptible par l'utilisateur du système votre Le serveur Web est en cours d'exécution. En continuant avec l'exemple ci-dessus, si votre serveur s'exécute en tant qu'utilisateur Apache, confirmez que /var/tmp/django_cache existe et que l'utilisateur Apache peut lire et écrire le répertoire /var/tmp/django_cache

<🎜. >

Chaque valeur de cache sera stockée dans un fichier séparé dont le contenu est des données Python pickle Cache enregistrées par les modules sous forme sérialisée ("pickled"), le nom de fichier de chaque fichier est la clé de cache, libérée pour sécuriser le système de fichiers, utilisez

cache de mémoire locale

Si vous souhaitez bénéficier des avantages rapides de Memcaching mais ne le faites pas Si vous avez la possibilité d'exécuter Memcached, vous pouvez envisager d'utiliser le backend du cache mémoire local, qui est multithread et thread-safe, mais en raison de sa stratégie simple de verrouillage et d'allocation de mémoire, il n'est pas aussi efficace que Memcached

Définissez CACHE_BACKEND sur locmem :/// pour l'utiliser, par exemple :

CACHE_BACKEND = 'locmem:///'

Cache simple (pour la phase de développement)

Vous pouvez utiliser un cache mémoire simple à processus unique en configurant 'simple : ///', par exemple :

CACHE_BACKEND = 'simple:///'

Ce cache sert uniquement à sauvegarder les données au sein du processus, il ne doit donc être utilisé que dans un développement ou environnement de test

Faux cache (pour utilisation en développement)

Enfin, Django fournit une fausse configuration de cache : il implémente simplement l'interface de cache sans faire quoi que ce soit

C'est une fonctionnalité utile si. votre site en ligne utilise beaucoup de mise en cache lourde, mais vous ne souhaitez pas utiliser la mise en cache dans l'environnement de développement, il vous suffit alors de modifier le fichier de configuration, définissez simplement CACHE_BACKEND sur 'dummy:///', par exemple :

CACHE_BACKEND = 'dummy:///'

Le résultat est que votre environnement de développement n'a pas Le cache est utilisé et l'environnement en ligne utilise toujours le cache.

Paramètre CACHE_BACKEND

Chaque backend de cache Il est possible d'utiliser des paramètres, qui sont donnés sous forme de chaînes de requête dans le paramètre CACHE_BACKEND. :

timeout : délai d'expiration de la mise en cache, en secondes . Ce paramètre est réglé par défaut sur 300 secondes (cinq minutes). Le nombre d'entrées Lorsqu'il est supérieur à ce nombre, les anciennes entrées seront supprimées. La valeur par défaut de ce paramètre est 300.

cull_ Frequency : Lorsque max_entries est atteint, le taux d'accès acceptés. Le rapport réel est de 1/cull_fréquence, donc définir cull_fréquence=2 supprimera la moitié de la quantité de cache lorsque max_entries est atteint

Définir la valeur cull_fréquence sur 0 signifie que lorsque max_entries est atteint max_entries, le cache sera vidé. Cela augmentera considérablement la vitesse d’accès au prix de nombreux échecs de cache. La valeur par défaut est 3

Dans cet exemple, le délai d'attente est défini sur 60

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

而在这个例子中，timeout设为30而max_entries为400:

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

其中，非法的参数与非法的参数值都将被忽略。

站点级 Cache

一旦你指定了”CACHE_BACKEND”，使用缓存的最简单的方法就是缓存你的整个网站。这意味着所有不包含GET或POST参数的页面在第一次被请求之后将被缓存指定好的一段时间。

要激活每个站点的cache，只要将``’django.middleware.cache.CacheMiddleware’``添加到MIDDLEWARE_CLASSES的设置里，就像下面这样：

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

注意

关于MIDDLEWARE_CLASSES顺序的一些事情。请看本章节后面的MIDDLEWARE_CLASSES顺序部分。

然后，在你的Django settings文件里加入下面所需的设置：

CACHE_MIDDLEWARE_SECONDS:每个页面应该被缓存的秒数

§ “CACHE_MIDDLEWARE_KEY_PREFIX”：如果缓存被多个使用相同Django安装的网站所共享，那么把这个值设成当前网站名，或其他能代表这个Django实例的唯一字符串，以避免key发生冲突。如果你不在意的话可以设成空字符串。

缓存中间件缓存每个没有GET或者POST参数的页面，即如果用户请求页面并在查询字符串里传递GET参数或者POST参数，中间件将不会尝试得到缓存版本的页面，如果你打算使用整站缓存，设计你的程序时牢记这点，例如，不要使用拥有查询字符串的URLs，除非那些页面可以不缓存

缓存中间件（ cache middleware）支持另外一种设置选项,CACHE_MIDDLEWARE_ANONYMOUS_ONLY。如果你把它设置为“True”,那么缓存中间件就只会对匿名请求进行缓存，匿名请求是指那些没有登录的用户发起的请求。如果想取消用户相关页面（user-specific
pages）的缓存，例如Djangos的管理界面，这是一种既简单又有效的方法。另外，如果你要使用CACHE_MIDDLEWARE_ANONYMOUS_ONLY选项，你必须先激活AuthenticationMiddleware才行，也就是在你的配置文件MIDDLEWARE_CLASSES的地方，AuthenticationMiddleware必须出现在CacheMiddleware前面。

最后，再提醒一下：CacheMiddleware在每个HttpResponse中都会自动设置一些头部信息（headers）

§ 当一个新(没缓存的)版本的页面被请求时设置Last-Modified头部为当前日期/时间

§ 设置Expires头部为当前日期/时间加上定义的CACHE_MIDDLEWARE_SECONDS

§ 设置Cache-Control头部来给页面一个最大的时间—再一次，根据CACHE_MIDDLEWARE_SECONDS设置

视图级缓存

更加颗粒级的缓存框架使用方法是对单个视图的输出进行缓存。这和整站级缓存有一样的效果（包括忽略对有 GET和 POST
参数的请求的缓存）。它应用于你所指定的视图，而不是整个站点。

完成这项工作的方式是使用修饰器，其作用是包裹视图函数，将其行为转换为使用缓存。视图缓存修饰器称为cache_page，位于django.views.decorators.cache模块中，例如：

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

如果使用 Python 2.4或更高版本,
你也可以使用 decorator语法。这个例子和前面的那个是等同的:

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

cache_page只接受一个参数：以秒计的缓存超时。在前例中， “my_view()”视图的结果将被缓存 15
分钟。（注意：为了提高可读性，该参数被书写为60 * 15。60 * 15将被计算为900，也就是说15分钟乘以每分钟
60 秒。）

和站点缓存一样，视图缓存与 URL无关。如果多个 URL
指向同一视图，每个视图将会分别缓存。继续my_view范例，如果 URLconf如下所示：

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

那么正如你所期待的那样，发送到/foo/1/和/foo/23/的请求将会分别缓存。但一旦发出了特定的请求（如：/foo/23/），之后再度发出的指向该
URL 的请求将使用缓存。

在 URLconf中指定视图缓存

前一节中的范例将视图硬编码为使用缓存，因为cache_page在适当的位置对my_view函数进行了转换。该方法将视图与缓存系统进行了耦合，从几个方面来说并不理想。例如，你可能想在某个无缓存的站点中重用该视图函数，或者你可能想将该视图发布给那些不想通过缓存使用它们的人。解决这些问题的方法是在
URLconf 中指定视图缓存，而不是紧挨着这些视图函数本身来指定。

完成这项工作非常简单：在 URLconf中用到这些视图函数的时候简单地包裹一个cache_page。以下是刚才用到过的

URLconf :
urlpatterns = ('',
(r'^foo/(/d{1,2})/$', my_view),
)
以下是同一个 URLconf，不过用cache_page包裹了my_view：
from django.views.decorators.cache import cache_page
urlpatterns = ('',
(r'^foo/(/d{1,2})/$', cache_page(my_view, 60 * 15)),
)

如果采取这种方法,不要忘记在 URLconf
中导入cache_page.

低层次缓存API

有些时候，对整个经解析的页面进行缓存并不会给你带来太多，事实上可能会过犹不及。

比如说，也许你的站点所包含的一个视图依赖几个费时的查询，每隔一段时间结果就会发生变化。在这种情况下，使用站点级缓存或者视图级缓存策略所提供的整页缓存并不是最理想的，因为你可能不会想对整个结果进行缓存（因为一些数据经常变化），但你仍然会想对很少变化的部分进行缓存。

在像这样的情形下， Django展示了一种位于django.core.cache模块中的简单、低层次的缓存
API。你可以使用这种低层次的缓存 API在缓存中以任何级别粒度进行对象储存。你可以对所有能够安全进行 pickle处理的
Python 对象进行缓存：字符串、字典和模型对象列表等等；查阅 Python文档可以了解到更多关于 pickling的信息。）

下面是如何导入这个 API :

>>> from django.core.cache import cache

基本的接口是set(key, value, timeout_seconds)和get(key):

>>> cache.set('my_key', 'hello, world!', 30)
>>> cache.get('my_key')
'hello, world!'

timeout_seconds参数是可选的,并且默认为前面讲过的CACHE_BACKEND设置中的timeout参数.

如果对象在缓存中不存在,或者缓存后端是不可达的,cache.get()返回None:

# Wait 30 seconds for 'my_key' to expire...
>>> cache.get('my_key')
None
>>> cache.get('some_unset_key')
None

我们不建议在缓存中保存None常量，因为你将无法区分所保存的None变量及由返回值None所标识的缓存未中。

cache.get()接受一个缺省参数。其指定了当缓存中不存在该对象时所返回的值：

>>> cache.get('my_key', 'has expired')

'has expired'

要想一次获取多个缓存值，可以使用cache.get_many()。如果可能的话，对于给定的缓存后端，get_many()将只访问缓存一次，而不是对每个缓存键值都进行一次访问。get_many()所返回的字典包括了你所请求的存在于缓存中且未超时的所有键值。

>>> cache.set('a', 1)
>>> cache.set('b', 2)
>>> cache.set('c', 3)
>>> cache.get_many(['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}

如果某个缓存关键字不存在或者已超时,它将不会被包含在字典中。下面是范例的延续:

>>> cache.get_many(['a', 'b', 'c', 'd'])

{'a': 1, 'b': 2, 'c': 3}

最后,你可以用cache.delete()显式地删除关键字。这是在缓存中清除特定对象的简单途径。

>>> cache.delete('a')

cache.delete()没有返回值,不管给定的缓存关键字对应的值存在与否,它都将以同样方式工作。

上游缓存

目前为止，本章的焦点一直是对你自己的数据进行缓存。但还有一种与 Web开发相关的缓存：由上游高速缓存执行的缓冲。有一些系统甚至在请求到达站点之前就为用户进行页面缓存。

下面是上游缓存的几个例子：

§ 你的 ISP (互联网服务商)可能会对特定的页面进行缓存，因此如果你向http://www.infocool.net/请求一个页面，你的
ISP 可能无需直接访问 www.infocool.net就能将页面发送给你。而 www.infocool.net的维护者们却无从得知这种缓存，ISP位于
www.infocool.net和你的网页浏览器之间，透明底处理所有的缓存。

§ 你的 Django网站可能位于某个代理缓存之后，例如
Squid网页代理缓存 (http://www.squid-cache.org/)，该缓存为提高性能而对页面进行缓存。在此情况下，每个请求将首先由代理服务器进行处理，然后仅在需要的情况下才被传递至你的应用程序。

§ 你的网页浏览器也对页面进行缓存。如果某网页送出了相应的头部，你的浏览器将在为对该网页的后续的访问请求使用本地缓存的拷贝，甚至不会再次联系该网页查看是否发生了变化。

上游缓存将会产生非常明显的效率提升，但也存在一定风险。许多网页的内容依据身份验证以及许多其他变量的情况发生变化，缓存系统仅盲目地根据 URL保存页面，可能会向这些页面的后续访问者暴露不正确或者敏感的数据。

举个例子，假定你在使用网页电邮系统，显然收件箱页面的内容取决于登录的是哪个用户。如果 ISP盲目地缓存了该站点，那么第一个用户通过该 ISP登录之后，他（或她）的用户收件箱页面将会缓存给后续的访问者。这一点也不好玩。

幸运的是， HTTP提供了解决该问题的方案。已有一些 HTTP头标用于指引上游缓存根据指定变量来区分缓存内容，并通知缓存机制不对特定页面进行缓存。我们将在本节后续部分将对这些头标进行阐述。

使用 Vary头标

Vary头标定义了缓存机制在构建其缓存键值时应当将哪个请求头标考虑在内。例如，如果网页的内容取决于用户的语言偏好，该页面被称为根据语言而不同。

缺省情况下，Django的缓存系统使用所请求的路径（比如："/stories/2005/jun/23/bank_robbed/"）来创建其缓存键。这意味着对该
URL的每个请求都将使用同一个已缓存版本，而不考虑 cookies或语言偏好之类的 user-agent差别。然而，如果该页面基于请求头标的区别（例如
cookies、语言或者 user-agent)产生不同内容，你就不得不使用

Vary头标来通知缓存机制：该页面的输出取决与这些东西。

要在 Django完成这项工作，可使用便利的vary_on_headers视图修饰器，如下所示：

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):
# ...

在这种情况下，缓存装置（如 Django自己的缓存中间件）将会为每一个单独的用户浏览器缓存一个独立的页面版本。

使用vary_on_headers修饰器而不是手动设置Vary头标（使用像response['Vary']
= 'user-agent'之类的代码）的好处是修饰器在（可能已经存在的）Vary之上进行添加，而不是从零开始设置，且可能覆盖该处已经存在的设置。

你可以向vary_on_headers()传入多个头标：

@vary_on_headers('User-Agent', 'Cookie')
def my_view(request):
# ...

该段代码通知上游缓存对两者都进行不同操作，也就是说 user-agent和 cookie
的每种组合都应获取自己的缓存值。举例来说，使用Mozilla作为 user-agent而foo=bar作为
cookie值的请求应该和使用Mozilla作为 user-agent而foo=ham的请求应该被视为不同请求。

由于根据 cookie而区分对待是很常见的情况，因此有vary_on_cookie修饰器。以下两个视图是等效的：

@vary_on_cookie
def my_view(request):
# ...
@vary_on_headers('Cookie')
def my_view(request):
# ...

传入vary_on_headers头标是大小写不敏感的；"User-Agent"与"user-agent"完全相同。

你也可以直接使用帮助函数：django.utils.cache.patch_vary_headers。该函数设置或增加Vary header，例如：

from django.utils.cache import patch_vary_headers
def my_view(request):
# ...
response = render_to_response('template_name', context)
patch_vary_headers(response, ['Cookie'])
return response

patch_vary_headers以一个HttpResponse实例为第一个参数，以一个大小写不敏感的头标名称列表或元组为第二个参数。

其它缓存头标

关于缓存剩下的问题是数据的私隐性以及关于在级联缓存中数据应该在何处储存的问题。

通常用户将会面对两种缓存：他或她自己的浏览器缓存（私有缓存）以及他或她的提供者缓存（公共缓存）。公共缓存由多个用户使用，而受其他某人的控制。这就产生了你不想遇到的敏感数据的问题，比如说你的银行账号被存储在公众缓存中。因此，Web应用程序需要以某种方式告诉缓存那些数据是私有的，哪些是公共的。

解决方案是标示出某个页面缓存应当是私有的。要在 Django中完成此项工作，可使用cache_control视图修饰器：

from django.views.decorators.cache import cache_control
@cache_control(private=True)
def my_view(request):
# ...

该修饰器负责在后台发送相应的 HTTP头标。

还有一些其他方法可以控制缓存参数。例如, HTTP允许应用程序执行如下操作:

§ 定义页面可以被缓存的最大次数。

§ 指定某个缓存是否总是检查较新版本，仅当无更新时才传递所缓存内容。（一些缓存即便在服务器页面发生变化的情况下都可能还会传送所缓存的内容，只因为缓存拷贝没有过期。）

在 Django中，可使用cache_control视图修饰器指定这些缓存参数。在本例中，cache_control告诉缓存对每次访问都重新验证缓存并在最长
3600 秒内保存所缓存版本：

from django.views.decorators.cache import cache_control
@cache_control(must_revalidate=True, max_age=3600)
def my_view(request):
...

在cache_control()中，任何有效Cache-ControlHTTP指令都是有效的。以下是一个完整的清单：

§ public=True
§ private=True
§ no_cache=True
§ no_transform=True
§ must_revalidate=True
§ proxy_revalidate=True
§ max_age=num_seconds
§ s_maxage=num_seconds

小提示

要了解有关Cache-ControlHTTP指令的相关解释,
可以查阅http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9的规范文档。

注意

缓存中间件已经使用CACHE_MIDDLEWARE_SETTINGS设置设定了缓存头标max-age。如果你在cache_control修饰器中使用了自定义的max_age，该修饰器将会取得优先权，该头标的值将被正确地被合并。）

其他优化

Django 带有一些其它中间件可帮助您优化应用程序的性能:

§ django.middleware.http.ConditionalGetMiddleware ajoute la prise en charge des réponses GET conditionnelles basées sur les en-têtes ETag et Last-Modified pour les navigateurs modernes.

§ django.middleware.gzip.GZipMiddleware compresse le contenu des réponses pour tous les navigateurs modernes afin d'économiser de la bande passante et des délais de livraison.

Ordre des MIDDLEWARE_CLASSES

Si vous utilisez un middleware de mise en cache, assurez-vous de le placer au bon emplacement des MIDDLEWARE_CLASSES paramètre , car le middleware de cache doit connaître les en-têtes utilisés pour générer différents magasins de cache.

Placer CacheMiddleware après tous les middlewares susceptibles d'ajouter du contenu à l'en-tête Vary, y compris le middleware suivant :

§ Ajouter le SessionMiddleware de Cookie

§ Ajouter le GZipMiddleware d'Accept-Encoding,

Ce qui précède est le contenu du mécanisme de mise en cache de Django, veuillez faire attention au contenu plus connexe PHP chinois site Web (www.php.cn) !