Un site Web crée avec Django est dynamique. Chaque fois qu’un utilisateur demande l’affichage d’une page, le serveur Web effectue toutes sortes d’opérations – des requêtes de bases de données au rendu des gabarits, en plus de la logique métier de l’application – afin de créer les pages que vos visiteurs verront. Ces opérations sont bien plus chères en temps de calcul qu’un site Web statique, ou des pages seraient directement lues depuis le système de fichier.
\nPour la plupart des applications Web, cette charge supplémentaire n’est pas un problème. En effet, la plupart des sites Web n’ont pas la popularité de washingtonpost.com ou slashdot.org, mais sont simplement des sites petits ou moyens, avec un trafic bien plus faible. En revanche, pour les sites à trafic moyen ou lourd, il est essentiel de réduire la charge de travail du serveur au maximum.
C’est là que le cache intervient.
\nMettre quelque chose « en cache » est le fait de sauvegarder le résultat d’une opération chère en temps de calcul, afin de ne pas avoir à ré-effectuer cette opération la fois suivante.
\ngiven a URL, try finding that page in the cache\nif the page is in the cache:\n return the cached page\nelse:\n generate the page\n save the generated page in the cache (for next time)\n return the generated page\nDjango mets un système de cache robuste à disposition, qui permet de sauvegarder les pages dynamiques afin d’éviter leur calcul pour chaque requête. Pour plus de souplesse, Django propose différents niveaux de granularité de cache: il est possible de mettre en cache le résultat de vues spécifiques, seulement les parties difficiles à produire, ou l’intégralité de votre site.
\nDjango fonctionne aussi très bien avec des caches externes tels que Squid, ainsi que les caches des navigateurs.\nCes types de caches ne sont pas controlés directement par l’application. Il est en revanche possible de leur fournir des indices (via les entêtes HTTP) sur quelles parties de votre site mettre en cache, et comment.
\n\nLe système de cache nécessite un peu de mise en place. En particulier, il faut indiquer où les données mises en cache doivent être stockées – dans une base de données, dans le système de fichiers ou directement en mémoire. C’est une décision importante qui influe sur les performances de votre cache: oui, certains systèmes sont plus rapides que d’autres.
\nLe choix de votre lieu de stockage de données de cache s’effectue à l’aide de l’entrée CACHES de votre fichier de réglages. Voici les valeurs possibles de CACHES.
Le type de cache le plus rapide et le plus efficace parmi ceux pris en charge nativement par Django, Memcached est un serveur de cache entièrement basé en mémoire, développé à l’origine pour soutenir la charge de travail élevée de LiveJournal.com, et dont la source a été par la suite ouverte par Danga Interactive. De gros sites tels que Facebook et Wikipedia l’utilisent pour réduire le nombre d’accès à leurs bases de données et accroître les performances de leurs sites en général.
\nMemcached fonctionne comme un service et reçoit une quantité de mémoire vive définie. Son unique rôle est de fournir une interface rapide pour ajouter, récupérer et supprimer des données dans le cache. Toutes les données sont stockées directement en mémoire, il n’y a donc aucune charge induite par une base de données ou par le système de fichiers.
\nAprès avoir installé Memcached, il s’agit d’installer le code de liaison Memcached. Il existe plusieurs codes de liaison Memcached disponibles en Python ; les deux les plus populaires sont python-memcached et pylibmc.
\nPour utiliser Memcached avec Django :
\nDéfinissez BACKEND à django.core.cache.backends.memcached.MemcachedCache ou à django.core.cache.backends.memcached.PyLibMCCache (selon votre choix de code de liaison memcached)
Définissez LOCATION aux valeurs ip:port, où ip est l’adresse IP du service Memcached et port est le port de fonctionnement de Memcached, ou à une valeur unix:path, où path est le chemin vers le fichier connecteur Unix de Memcached.
Dans cet exemple, Memcached tourne sur localhost (127.0.0.1) port 11211, utilisant la liaison python-memcached:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': '127.0.0.1:11211',\n }\n}\nDans cet exemple, Memcached est disponible par un connecteur Unix local /tmp/memcached.sock en utilisant la liaison python-memcached:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': 'unix:/tmp/memcached.sock',\n }\n}\nSi vous utilisez le code de liaison pylibmc, n’utilisez pas le préfixe unix:/:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',\n 'LOCATION': '/tmp/memcached.sock',\n }\n}\nL’une des fonctionnalités très intéressantes de Memcached est de pouvoir répartir un cache sur plusieurs serveurs. Cela signifie que vous pouvez faire fonctionner des services Memcached sur plusieurs machines et le programme va considérer le groupe de machines comme un seul cache, sans devoir dupliquer les valeurs du cache sur chaque machine. Pour tirer profit de cette fonctionnalité, ajoutez toutes les adresses des serveurs impliqués dans LOCATION, soit en les séparant par des points-virgules ou sous forme de liste.
Dans cet exemple, le cache est distribué sur des instances Memcached fonctionnant aux adresses IP 172.19.26.240 et 172.19.26.242, les deux sur le port 11211 :
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': [\n '172.19.26.240:11211',\n '172.19.26.242:11211',\n ]\n }\n}\nDans l’exemple suivant, le cache est distribué sur des instances Memcached fonctionnant aux adresses IP 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and 172.19.26.244 (port 11213) :
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': [\n '172.19.26.240:11211',\n '172.19.26.242:11212',\n '172.19.26.244:11213',\n ]\n }\n}\nUn dernier point au sujet de Memcached est que le cache basé sur la mémoire présente un désavantage : en raison du stockage en mémoire, les données du cache sont perdues si le serveur s’arrête. Il est clair que la mémoire n’est pas prévue pour contenir des données de manière permanente, il ne faut donc pas se baser sur du cache en mémoire comme seul stockage de données. Sans aucun doute, aucun des moteurs de cache de Django ne devrait être utilisé pour du stockage permanent, ils sont tous prévus pour être des solutions de mise en cache et non pour du stockage ; mais nous signalons cela ici car le cache basé sur la mémoire est particulièrement volatile.
\nDjango peut stocker ses données mises en cache dans votre base de données. Cela fonctionne mieux si vous avez un serveur de base de données rapide et bien indexé.
\nPour utiliser une table de base de données comme cache :
\nDéfinissez BACKEND à django.core.cache.backends.db.DatabaseCache
Pour LOCATION, indiquez tablename, le nom de la table de base de données. Ce nom peut être librement choisi, pour autant qu’il corresponde à un nom de table valide qui n’est pas déjà utilisé dans votre base de données.
Dans cet exemple, le nom de la table du cache est my_cache_table:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.db.DatabaseCache',\n 'LOCATION': 'my_cache_table',\n }\n}\nAvant d’utiliser le cache en base de données, vous devez créer la table du cache avec cette commande :
\npython manage.py createcachetable\nCela crée une table dans votre base de données qui est dans le format attendu par le système de cache de Django. Le nom de la table est extrait de LOCATION.
Si vous utilisez plusieurs caches en base de données, createcachetable crée une table pour chaque cache.
Si vous utilisez plusieurs bases de données, createcachetable respecte la méthode allow_migrate () de vos routeurs de base de données (voir ci-dessous).
Comme migrate, createcachetable ne touchera pas à une table existante. Il ne fera que créer les tables manquantes.
Pour afficher le code SQL qui serait exécuté plutôt que de l’exécuter réellement, utilisez l’option createcachetable --dry-run.
Si vous utilisez le cache en base de données avec plusieurs bases de données, vous devrez également indiquer des instructions de routage pour la table de base de données du cache. Dans l’optique du routage, la table de base de données du cache apparaît en tant que modèle nommé CacheEntry dans une application nommée django_cache. Ce modèle n’est pas présent dans le cache des modèles, mais il est possible d’utiliser les détails du modèle dans un contexte de routage.
Par exemple, le routeur suivant redirige toutes les opérations de lecture de cache vers cache_replica et toutes les opérations d’écriture en cache vers cache_primary. La table de cache ne sera synchronisée que vers cache_primary:
class CacheRouter(object):\n """A router to control all database cache operations"""\n\n def db_for_read(self, model, **hints):\n "All cache read operations go to the replica"\n if model._meta.app_label == 'django_cache':\n return 'cache_replica'\n return None\n\n def db_for_write(self, model, **hints):\n "All cache write operations go to primary"\n if model._meta.app_label == 'django_cache':\n return 'cache_primary'\n return None\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n "Only install the cache model on primary"\n if app_label == 'django_cache':\n return db == 'cache_primary'\n return None\nSi vous n’indiquez aucune information de routage pour le modèle de cache en base de données, le moteur de cache utilise la base de données default.
Naturellement, si vous n’utilisez pas le moteur de cache en base de données, il n’est pas nécessaire de fournir des instructions de routage pour le modèle de cache en base de données.
\nLe moteur de cache basé sur des fichiers sérialise et stocke chaque valeur de cache dans un fichier séparé. Pour utiliser ce moteur, définissez BACKEND à "django.core.cache.backends.filebased.FileBasedCache" et renseignez LOCATION avec un répertoire approprié. Par exemple, pour stocker vos données en mémoire cache dans /var/tmp/django_cache, utilisez ce paramètre :
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': '/var/tmp/django_cache',\n }\n}\nSi vous êtes sur Windows, indiquez la lettre de lecteur au début du chemin, comme ceci :
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': 'c:/foo/bar',\n }\n}\nLe chemin de répertoire doit être absolu, c’est-à-dire qu’il doit commencer à la racine du système de fichiers. La barre oblique en fin de chemin est facultative.
\nAssurez-vous que le répertoire indiqué par ce réglage existe bel et bien et qu’il est accessible en lecture et écriture par l’utilisateur système avec lequel tourne votre serveur Web. Poursuivant l’exemple ci-dessus, si votre serveur tourne avec l’utilisateur apache, vérifiez que le répertoire /var/tmp/django_cache existe et qu’il est accessible en lecture et écriture par l’utilisateur apache.
Il s’agit du cache par défaut s’il n’y en a pas un autre défini dans votre fichier de réglages. Si vous souhaitez obtenir les avantages de rapidité du cache en mémoire mais que vous n’avez pas la possibilité de faire fonctionner Memcached, considérez la possibilité d’utiliser le moteur de cache en mémoire locale. Ce cache est par processus (voir ci-dessous) et gère la concurrence entre fils d’exécution (thread-safe). Pour l’utiliser, définissez BACKEND à "django.core.cache.backends.locmem.LocMemCache". Par exemple :
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',\n 'LOCATION': 'unique-snowflake',\n }\n}\nLe réglage de cache LOCATION est utilisé pour identifier les stockages individuels en mémoire. Si vous n’avez qu’un seul cache locmem`, vous pouvez omettre de configurer LOCATION; Cependant, si vous avez plus d’un stockage en mémoire locale, vous devrez attribuer un nom à au moins l’un d’entre eux afin de pouvoir les distinguer.
Notez que chaque processus aura sa propre instance de cache privée, ce qui signifie qu’il n’est pas possible de faire du cache inter-processus. Cela signifie évidemment aussi que le cache en mémoire locale n’est pas particulièrement efficace en mémoire, ce qui n’en fait pas un très bon choix en environnement de production. Mais il est pratique pour le développement.
\nPour terminer, Django fournit un « pseudo-cache » qui ne fait pas réellement de cache, mais qui ne fait qu’implémenter l’interface de cache sans action réelle.
\nIl est utile dans le cas où un site utilise intensivement le cache en production dans différents endroits, mais que l’environnement de test ou de développement n’est pas censé exploiter le cache et que vous ne souhaitez pas changer le code pour distinguer les types d’environnement au cas par cas. Pour activer le pseudo-cache, définissez BACKEND comme ceci :
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.dummy.DummyCache',\n }\n}\nBien que Django soit livré avec un certain nombre de moteurs de cache, il peut parfois être nécessaire de créer son propre moteur de cache. Pour utiliser un moteur de cache personnalisé avec Django, il s’agit d’indiquer le chemin d’importation Python dans la clé BACKEND du réglage CACHES, comme ceci :
CACHES = {\n 'default': {\n 'BACKEND': 'path.to.backend',\n }\n}\nSi vous créez votre propre moteur, vous pouvez considérer les moteurs de cache standards comme les implémentations de référence. Le code se trouve dans le répertoire django/core/cache/backends/ du code source de Django.
Note : sans raison impérieuse, comme par exemple un hôte qui ne les prend pas en charge, il est recommandé de se restreindre aux moteurs de cache inclus dans Django. Ils sont intensivement testés et simples d’emploi.
\nChaque moteur de cache accepte des paramètres supplémentaires pour contrôler le comportement du cache. Ces paramètres sont transmis sous la forme de clés supplémentaires dans le réglage CACHES. Les paramètres valides sont les suivants :
TIMEOUT: le délai d’expiration du cache par défaut, en secondes. Ce paramètre contient 300 secondes (5 minutes) par défaut. Vous pouvez définir TIMEOUT à la valeur None de sorte que, par défaut, les clés de cache n’expirent jamais. Une valeur de 0 implique que les clés expirent immédiatement (dans les faits on « ne met pas en cache »).
OPTIONS: toute option devant être transmise au moteur de cache. La liste des options valides dépend de chaque moteur et les moteurs s’appuyant sur une bibliothèque tierce transmettent directement ces options à la bibliothèque de cache sous-jacente.
Les moteurs de cache implémentant leur propre stratégie de purge (« culling »), c’est-à-dire les moteurs locmem, filesystem et database, acceptent les options suivantes :
MAX_ENTRIES: le nombre maximum d’éléments autorisés dans le cache avant que des valeurs plus anciennes ne soient supprimées. Ce paramètre vaut 300 par défaut.
CULL_FREQUENCY: la quantité d’éléments effacés lorsque le nombre MAX_ENTRIES est atteint. Le taux effectif est 1 / CULL_FREQUENCY, il faut donc indiquer 2 dans CULL_FREQUENCY pour purger la moitié des éléments lorsque MAX_ENTRIES est atteint. Ce paramètre doit être un nombre entier, et sa valeur par défaut est 3.
Une valeur de CULL_FREQUENCY à 0 signifie que tout le cache est effacé lorsque MAX_ENTRIES est atteint. Sur certains moteurs (database en particulier), cela accélère nettement la purge du cache au dépend de davantage de défauts de cache.
KEY_PREFIX: une chaîne étant systématiquement incluse (en préfixe par défaut) dans toutes les clés de cache utilisées par le serveur Django.
Consultez la documentation du cache pour plus d’informations.
\nVERSION: le numéro de version par défaut des clés de cache générées par le serveur Django.
Consultez la documentation du cache pour plus d’informations.
\nKEY_FUNCTION: une chaîne contenant un chemin pointé vers une fonction qui définit la manière de composer un préfixe, une version et une clé pour former une clé de cache finale.
Consultez la documentation du cache pour plus d’informations.
\nDans cet exemple, un moteur basé sur le système de fichiers est configuré avec un délai d’expiration de 60 secondes et une capacité maximale de 1000 éléments :
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': '/var/tmp/django_cache',\n 'TIMEOUT': 60,\n 'OPTIONS': {\n 'MAX_ENTRIES': 1000\n }\n }\n}\nLes paramètres non valables sont ignorés en silence, tout comme les valeurs non valides de paramètres connus.
\nUne fois le cache configuré, la manière la plus simple d’utiliser le cache est de mettre en cache tout le site. Il s’agit alors d’ajouter 'django.middleware.cache.UpdateCacheMiddleware' et 'django.middleware.cache.FetchFromCacheMiddleware' au réglage MIDDLEWARE, comme dans cet exemple :
MIDDLEWARE = [\n 'django.middleware.cache.UpdateCacheMiddleware',\n 'django.middleware.common.CommonMiddleware',\n 'django.middleware.cache.FetchFromCacheMiddleware',\n]\nPuis, ajoutez les réglages obligatoires suivants dans votre fichier de réglages Django :
\nCACHE_MIDDLEWARE_ALIAS – L’alias de cache à utiliser pour le stockage.
CACHE_MIDDLEWARE_SECONDS – le nombre de secondes durant lequel chaque page doit être conservée en cache.
CACHE_MIDDLEWARE_KEY_PREFIX – Si le cache est partagé par plusieurs sites utilisant la même installation de Django, définissez cette valeur au nom du site ou à un nom unique de cette instance de Django, afin d’éviter des collisions de clés. Indiquez une chaîne vide si cela ne vous concerne pas.
L’intergiciel FetchFromCacheMiddleware met en mémoire cache les réponses GET et HEAD ayant le statut 200, pour autant que les en-têtes de requête et de réponse le permettent. Les réponses aux requêtes à une même URL ayant des paramètres de requête différents sont considérées comme des pages distinctes et sont mises en cache séparément. Cet intergiciel s’attend à ce que la réponse à une requête HEAD possède les mêmes en-têtes de réponse que la requête GET équivalente ; et dans ce cas, il peut renvoyer une réponse GET à partir du cache lors d’une requête HEAD.
De plus, l’intergiciel UpdateCacheMiddleware définit automatiquement quelques en-têtes dans chaque réponse HttpResponse:
L’en-tête Last-Modified est défini à la date/heure courante lorsqu’une version fraîche (pas dans le cache) d’une page est demandée.
L’en-tête Expires est défini à la date/heure courante additionnée de CACHE_MIDDLEWARE_SECONDS.
L’en-tête Cache-Control est défini à un âge maximal de la page, aussi selon le réglage CACHE_MIDDLEWARE_SECONDS.
Voir Intergiciels (« Middleware ») pour plus d’informations sur les intergiciels.
\nSi une vue définit son propre délai d’expiration de cache (par ex. avec une section max-age dans son en-tête Cache-Control), la page sera mise en cache jusqu’à la fin de ce délai d’expiration, sans tenir compte du temps défini dans CACHE_MIDDLEWARE_SECONDS. À l’aide des décorateurs de django.views.decorators.cache, vous pouvez facilement définir le délai d’expiration d’une vue (par le décorateur cache_control()) ou désactiver la mise en cache d’une vue (par le décorateur never_cache()). Consultez la section utilisation d’autres en-têtes pour en savoir plus sur ces décorateurs.
Si USE_I18N est défini à True, la clé de cache générée inclut le nom de la langue active, voir aussi Processus de découverte de la préférence de langue par Django). Cela permet de facilement mettre en cache des sites multilingues sans devoir créer soi-même les clés de cache.
Les clés de cache incluent également la langue active lorsque USE_L10N est défini à True ainsi que le fuseau horaire actuel lorsque USE_TZ est défini à True.
Une manière plus fine d’utiliser l’infrastructure de cache est de mettre en cache le résultat de vues individuelles. django.views.decorators.cache définit un décorateur cache_page qui se charge de mettre en cache la réponse de la vue. Il est simple à mettre en place :
from django.views.decorators.cache import cache_page\n\n@cache_page(60 * 15)\ndef my_view(request):\n ...\ncache_page accepte un seul paramètre : le délai d’expiration du cache en secondes. Dans l’exemple ci-dessus, le résultat de la vue my_view() reste en cache pendant 15 minutes (remarquez que nous avons écrit 60 * 15 par souci de lisibilité, le résultat donne 900, c’est-à-dire 15 minutes multipliées par 60 secondes).
Le cache par vue, comme le cache par site, construit ses clés d’après les URL. Si des URL différentes pointent vers la même vue, chaque URL aura son propre cache. En reprenant l’exemple my_view, si votre configuration d’URL ressemble à ceci :
urlpatterns = [\n url(r'^foo/([0-9]{1,2})/$', my_view),\n]\nalors les requêtes vers /foo/1/ et /foo/23/ seront mises en cache séparément, comme prévu. Dès qu’une des URL a été accédée (par ex. /foo/23/), les requêtes suivantes à cette même URL utiliseront le cache.
cache_page accepte également un paramètre nommé facultatif, cache, qui indique au décorateur d’utiliser un cache spécifique (parmi ceux du réglage CACHES) lors de la mise en cache des résultats de la vue. Par défaut, c’est le cache default qui est utilisé, mais vous pouvez indiquer le cache que vous souhaitez :
@cache_page(60 * 15, cache="special_cache")\ndef my_view(request):\n ...\nIl est aussi possible de surcharger le préfixe de cache par vue. cache_page accepte un paramètre nommé facultatif, key_prefix, qui joue le même rôle que le réglage CACHE_MIDDLEWARE_KEY_PREFIX pour l’intergiciel. Il peut être utilisé comme suit :
@cache_page(60 * 15, key_prefix="site1")\ndef my_view(request):\n ...\nLes paramètres key_prefix et cache peuvent être tous deux spécifiés. Le paramètre key_prefix et la clé KEY_PREFIX du réglage CACHES sont combinés.
Les exemples de la section précédente ont figé dans le code le fait que la vue est mise en cache, car cache_page modifie la fonction my_view sur place. Cette approche lie la vue au système de cache, ce qui n’est pas idéal pour plusieurs raisons. Par exemple, il est possible que les vues puissent être réutilisées pour un autre site sans cache, ou peut-être qu’à un moment donné les vues seront mises à disposition d’autres personnes qui voudront les utiliser sans cache. La solution à ces problèmes est de définir le cache par vue dans la configuration d’URL plutôt qu’autour des fonctions de vue elles-mêmes.
C’est simple à faire : il suffit d’entourer la fonction de vue par cache_page lorsque vous la mentionnez dans la configuration d’URL. Voici la configuration que nous avons déjà vue précédemment :
urlpatterns = [\n url(r'^foo/([0-9]{1,2})/$', my_view),\n]\nEt la même chose, avec my_view entourée par cache_page:
from django.views.decorators.cache import cache_page\n\nurlpatterns = [\n url(r'^foo/([0-9]{1,2})/$', cache_page(60 * 15)(my_view)),\n]\nSi vous recherchez encore plus de contrôle, il est encore possible de mettre en cache des bouts de gabarits avec la balise de gabarit cache. Pour que vos gabarits aient accès à cette balise, placez {% load cache %} au début du gabarit.
La balise de gabarit {% cache %} met en cache le contenu du bloc pour un temps donné. Il accepte au moins deux paramètres : le délai d’expiration de cache en secondes et le nom à donner au fragment de cache. Le nom est accepté tel quel, n’utilisez pas de variable. Par exemple :
{% load cache %}\n{% cache 500 sidebar %}\n .. sidebar ..\n{% endcache %}\nIl peut arriver que vous souhaitiez mettre en cache plusieurs copies d’un fragment en fonction de certaines données dynamiques apparaissant dans le fragment. Par exemple, la barre latérale de l’exemple précédent pourrait être mise en cache séparément pour chaque utilisateur du site. Cela se fait en passant des paramètres supplémentaires à la balise de gabarit {% cache %} afin d’identifier le fragment de cache de manière unique :
{% load cache %}\n{% cache 500 sidebar request.user.username %}\n .. sidebar for logged in user ..\n{% endcache %}\nIl est tout à fait correct d’indiquer plus d’un paramètre pour identifier le fragment. Il suffit de transmettre autant de paramètres que nécessaire à {% cache %}.
Quand USE_I18N est défini à True, le cache intergiciel par site respecte la langue active. Pour la balise de gabarit cache, il est possible d’utiliser l’une des variables spécifiques aux traductions disponibles dans les gabarits pour obtenir le même résultat :
{% load i18n %}\n{% load cache %}\n\n{% get_current_language as LANGUAGE_CODE %}\n\n{% cache 600 welcome LANGUAGE_CODE %}\n {% trans "Welcome to example.com" %}\n{% endcache %}\nLe délai d’expiration de cache peut être une variable de gabarit, pour autant que la variable de gabarit corresponde à un nombre entier. Par exemple, si la variable de gabarit my_timeout contient la valeur 600, les deux exemples suivants sont alors équivalents :
{% cache 600 sidebar %} ... {% endcache %}\n{% cache my_timeout sidebar %} ... {% endcache %}\nCette fonctionnalité est utile pour éviter les répétitions dans les gabarits. Vous pouvez définir le délai d’expiration dans une variable à un seul endroit, puis simplement réutiliser cette valeur.
\nPar défaut, la balise cache va essayer d’utiliser le cache appelé « template_fragments ». Si aucun cache de ce type n’existe, il se replie sur l’utilisation du cache par défaut. Vous pouvez définir un moteur de cache alternatif à utiliser au moyen du paramètre nommé using, qui doit être le dernier paramètre de la balise.
{% cache 300 local-thing ... using="localcache" %}\nL’indication d’un nom de cache qui n’est pas configuré est considéré comme une erreur.
\nSi vous souhaitez obtenir la clé de cache utilisée pour un fragment en cache, vous pouvez utiliser make_template_fragment_key. fragment_name est comme le second paramètre de la balise de gabarit cache. vary_on est une liste de tous les paramètres supplémentaires transmis à la balise. Cette fonction peut être utile pour invalider ou écraser un élément du cache, par exemple :
>>> from django.core.cache import cache\n>>> from django.core.cache.utils import make_template_fragment_key\n# cache key for {% cache 500 sidebar username %}\n>>> key = make_template_fragment_key('sidebar', [username])\n>>> cache.delete(key) # invalidates cached template fragment\nDans certains cas, la mise en cache d’une page entière ne donne pas d’avantage significatif et peut même se révéler totalement inutile.
\nImaginons par exemple que votre site contienne une vue dont les résultats dépendent de plusieurs requêtes coûteuses dont les résultats changent à des moments différents. Dans ce cas, il ne serait pas idéal d’utiliser la mise en cache de pages entières telles que l’offrent les stratégies de cache par site ou par vue, parce qu’il n’est pas souhaitable de mettre en cache la totalité du résultat (étant donné que certaines données changent souvent), mais il reste intéressant de mettre en cache les résultats qui changent rarement.
\nDans de telles situations, Django expose une API de cache simple et de bas niveau. Vous pouvez utiliser cette API pour stocker des objets dans le cache avec la granularité de votre choix. Vous pouvez placer dans ce cache tout objet Python pouvant être sérialisée par pickle: chaînes, dictionnaires, listes d’objets de modèle, etc. (la plupart des objets Python courants peuvent être ainsi sérialisés, référez-vous à la documentation de Python pour plus d’informations sur la sérialisation pickle).
Vous pouvez accéder aux caches configurés dans le réglage CACHES par un objet de type dictionnaire : django.core.cache.caches. Les requêtes successives du même alias dans le même fil d’exécution renvoient le même objet.
>>> from django.core.cache import caches\n>>> cache1 = caches['myalias']\n>>> cache2 = caches['myalias']\n>>> cache1 is cache2\nTrue\nSi l’alias indiqué n’existe pas, une exception InvalidCacheBackendError est générée.
Pour respecter la concurrence des fils d’exécution, une instance différente du moteur de cache est renvoyée pour chaque fil d’exécution.
\nEn raccourci, le cache par défaut est disponible dans django.core.cache.cache:
>>> from django.core.cache import cache\nCet objet est équivalent à caches['default'].
L’interface de base est set(key, value, timeout) et get(key):
>>> cache.set('my_key', 'hello, world!', 30)\n>>> cache.get('my_key')\n'hello, world!'\nkey doit être de type str (ou unicode avec Python 2), et value peut être n’importe quel objet Python sérialisé par « pickle ».
Le paramètre timeout est optionnel et est par défaut à la même valeur que le paramètre timeout du backend approprié défini dans le réglage de CACHES (expliqué ci-dessus). Il correspond au nombre de secondes pendant lesquelles la valeur doit être stockée dans le cache. Si timeout a la valeur None la valeur reste en cache pour toujours. Un timeout de 0 ne met pas en cache la valeur.
Si l’objet n’existe pas dans le cache, cache.get() renvoie None:
>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get('my_key')\nNone\nNous déconseillons de stocker la valeur littérale None dans le cache, car il ne sera pas possible de distinguer entre votre valeur stockée None et un défaut de cache signifié par une valeur de renvoi None.
cache.get() accepte un paramètre default. Ceci permet d’indiquer la valeur à renvoyer si l’objet n’existe pas dans le cache :
>>> cache.get('my_key', 'has expired')\n'has expired'\nPour ajouter une clé dans le seul cas où elle n’existe pas encore, utilisez la méthode add(). Elle accepte les mêmes paramètres que set(), mais elle n’essaie pas de mettre à jour le cache si la clé indiquée est déjà présente :
>>> cache.set('add_key', 'Initial value')\n>>> cache.add('add_key', 'New value')\n>>> cache.get('add_key')\n'Initial value'\nSi vous avez besoin de savoir si add() a bien stocké une valeur dans le cache, vous pouvez consulter la valeur renvoyée : True si la valeur a été stockée et False dans le cas contraire.
Si vous souhaitez obtenir la valeur d’une clé ou définir cette valeur si la clé ne se trouve pas dans le cache, il existe une méthode get_or_set(). Elle accepte les mêmes paramètres que get() mais la valeur par défaut est définie comme nouvelle valeur de cette clé dans le cache, plutôt que d’être simplement renvoyée :
>>> cache.get('my_new_key') # returns None\n>>> cache.get_or_set('my_new_key', 'my new value', 100)\n'my new value'\nVous pouvez également passer n’importe quel objet exécutable comme valeur par défaut :
\n>>> import datetime\n>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)\ndatetime.datetime(2014, 12, 11, 0, 15, 49, 457920)\nIl existe aussi une interface get_many() qui n’interroge le cache qu’une seule fois. get_many() renvoie un dictionnaire contenant toutes les clés demandées qui existent réellement dans le cache (et qui n’ont pas expiré) :
>>> cache.set('a', 1)\n>>> cache.set('b', 2)\n>>> cache.set('c', 3)\n>>> cache.get_many(['a', 'b', 'c'])\n{'a': 1, 'b': 2, 'c': 3}\nPour définir plusieurs valeurs de manière plus efficace, utilisez set_many() pour transmettre un dictionnaire de paires clé-valeur :
>>> cache.set_many({'a': 1, 'b': 2, 'c': 3})\n>>> cache.get_many(['a', 'b', 'c'])\n{'a': 1, 'b': 2, 'c': 3}\nTout comme cache.set(), set_many() accepte un paramètre facultatif timeout (délai d’expiration).
Vous pouvez supprimer explicitement des clés avec delete(). C’est une façon simple d’effacer le cache pour un objet particulier :
>>> cache.delete('a')\nSi vous voulez effacer plusieurs clés en une seule opération, delete_many() accepte une liste de clés à effacer :
>>> cache.delete_many(['a', 'b', 'c'])\nPour finir, si vous voulez effacer toutes les clés du cache, utilisez cache.clear(). Mais soyez prudent ; clear() efface tout ce qui se trouve dans le cache, et pas seulement les clés définies par votre application :
>>> cache.clear()\nVous pouvez aussi incrémenter ou décrémenter une clé existante au moyen des méthodes incr() et decr(), respectivement. Par défaut, l’incrément des valeurs de cache existantes est de 1. D’autre valeurs d’incrément peuvent être fournies en indiquant un paramètre lors de l’appel aux méthodes correspondantes. Une exception ValueError est générée si vous essayez d’incrémenter ou de décrémenter une clé de cache non existante :
>>> cache.set('num', 1)\n>>> cache.incr('num')\n2\n>>> cache.incr('num', 10)\n12\n>>> cache.decr('num')\n11\n>>> cache.decr('num', 5)\n6\nVous pouvez fermer la connexion au cache avec close() si le moteur de cache prend en charge cette opération.
>>> cache.close()\nSi une instance de cache est partagée entre plusieurs serveurs ou entre l’environnement de production et de développement, il est possible que des données mises en cache par un serveur soient lues par un autre serveur. Si le format des données mises en cache est différent d’un serveur à l’autre, cela peut conduire à des problèmes très difficiles à diagnostiquer.
\nPour éviter cela, Django offre la possibilité de préfixer toutes les clés de cache utilisées par un serveur. Pour chaque clé de cache enregistrée ou lue, Django préfixe automatiquement la clé de cache par la valeur du réglage de cache KEY_PREFIX.
En prenant soin de définir des valeurs KEY_PREFIX différentes pour chaque instance de Django, vous pouvez vous assurer qu’il n’y aura pas de collisions de valeurs de cache.
Lorsque vous modifiez du code utilisant des valeurs en cache, il peut être nécessaire de purger toutes les valeurs en cache. La manière la plus simple de le faire est d’effacer tout le cache, mais cela peut aussi effacer des valeurs en cache qui resteraient valides et utiles.
\nDjango met à disposition une façon plus subtile de cibler certaines valeurs de cache. Le système de cache de Django dispose d’un identifiant de version global défini dans le réglage de cache VERSION. La valeur de ce réglage est automatiquement combinée au préfixe de cache et à la clé de cache fournie par l’utilisateur pour obtenir la clé de cache finale.
Par défaut, toute lecture de clé inclut automatiquement la version de clé de cache par défaut du site. Cependant, les fonctions de cache primitives proposent toutes un paramètre version, afin de pouvoir indiquer une version de clé de cache particulière, que ce soit en lecture ou en écriture. Par exemple :
>>> # Set version 2 of a cache key\n>>> cache.set('my_key', 'hello world!', version=2)\n>>> # Get the default version (assuming version=1)\n>>> cache.get('my_key')\nNone\n>>> # Get version 2 of the same key\n>>> cache.get('my_key', version=2)\n'hello world!'\nLa version d’une clé particulière peut être incrémentée ou décrémentée par les méthodes incr_version() et decr_version(). Cela permet de mettre à jour des clés spécifiques à une nouvelle version sans toucher aux autres clés. En poursuivant l’exemple précédent :
>>> # Increment the version of 'my_key'\n>>> cache.incr_version('my_key')\n>>> # The default version still isn't available\n>>> cache.get('my_key')\nNone\n# Version 2 isn't available, either\n>>> cache.get('my_key', version=2)\nNone\n>>> # But version 3 *is* available\n>>> cache.get('my_key', version=3)\n'hello world!'\nComme expliqué dans les deux précédentes sections, la clé de cache indiquée par un utilisateur n’est pas employée telle quelle – elle est combinée au préfixe de cache et à la version de clé pour composer une clé de cache finale. Par défaut, les trois parties sont combinées par des deux-points pour produire la clé finale :
\ndef make_key(key, key_prefix, version):\n return ':'.join([key_prefix, str(version), key])\nSi vous souhaitez combiner les parties d’une autre manière ou appliquer un autre traitement à la clé finale (par ex. en produisant une empreinte numérique des parties de la clé), vous pouvez définir une fonction de clé personnalisée.
\nLe réglage de cache KEY_FUNCTION indique un chemin en syntaxe pointée vers une fonction correspondant au prototype de make_key() (voir ci-dessus). Lorsqu’elle est définie, cette fonction de clé personnalisée sera utilisée en lieu et place de la fonction par défaut de combinaison de clé.
Memcached, le moteur de cache le plus souvent utilisé en production, n’autorise pas de clés de cache plus longues que 250 caractères ou qui contient des espaces ou des caractères de contrôle. De telles clés génèrent des exceptions. Pour promouvoir du code compatible entre caches et minimiser les mauvaises surprises, les autres moteurs de cache intégrés génèrent un avertissement (django.core.cache.backends.base.CacheKeyWarning) si un nom de clé produirait une erreur avec memcached.
Si vous utilisez un moteur de cache en production qui accepte un plus large éventail de clés (moteur personnalisé ou l’un des moteurs intégrés autres que memcached) et que vous ne voulez par être dérangé par les avertissements CacheKeyWarning, vous pouvez les masquer par ce code placé dans le module management de l’une des applications dans INSTALLED_APPS:
import warnings\n\nfrom django.core.cache import CacheKeyWarning\n\nwarnings.simplefilter("ignore", CacheKeyWarning)\nSi vous préférez plutôt définir une logique de validation de clé personnalisée pour l’un des moteurs intégrés, vous pouvez créer une sous-classe qui ne surcharge que la méthode validate_key et suivre les instructions données dans utilisation d’un moteur de cache personnalisé. Par exemple, pour faire cela avec le moteur locmem, placez ce code dans un module :
from django.core.cache.backends.locmem import LocMemCache\n\nclass CustomLocMemCache(LocMemCache):\n def validate_key(self, key):\n """Custom validation, raising exceptions or warnings as needed."""\n ...\n…et utilisez le chemin Python pointé vers cette classe dans la partie BACKEND de votre réglage CACHES.
Jusqu’ici, ce document s’est concentré sur le cache de vos propres données. Mais dans le cadre du développement Web, un autre type de cache doit être considéré : le cache effectué par des caches « amonts ». Ce sont des systèmes qui mettent des pages en cache pour les utilisateurs avant même que les requêtes n’atteignent votre serveur Web.
\nVoici quelques exemples de caches amonts :
\nVotre fournisseur de services Internet (ISP) peut mettre certaines pages en cache, donc en demandant une page à l’adresse https://example.com/, vous recevez la page de la part de votre fournisseur sans que la requête n’ait atteint directement example.com. Les mainteneurs de example.com n’ont pas conscience de ce processus de cache. Le fournisseur se place entre votre navigateur Web et le serveur example.com et se charge du cache de manière transparente.
Votre site Web Django peut se trouver derrière un cache mandataire tel que Squid (http://www.squid-cache.org/), qui met des pages en cache pour améliorer les performances du réseau. Dans ce cas, chaque requête est d’abord traitée par le serveur mandataire et n’est transmise à votre application que s’il le juge nécessaire.
Votre navigateur Web met aussi des pages en cache. Si une page Web envoie des en-têtes appropriés, le navigateur utilise la copie d’une page dans le cache local pour toute nouvelle requête vers cette même page, sans même redemander la page Web au serveur pour savoir si elle a changé.
Les caches amonts améliorent bien les performances, mais il y a un risque : de nombreuses pages Web produisent du contenu différent selon la personne authentifiée ou selon d’autres paramètres, et donc des systèmes qui mettent aveuglément des pages en cache en ne se basant que sur l’URL pourraient exposer des données incorrectes ou sensibles à tout visiteur consultant ces pages.
\nPar exemple, supposons que vous gériez un système de messagerie Web ; le contenu de la page « boîte de réception » dépend bien évidemment de l’utilisateur connecté. Si un fournisseur d’accès se met à mettre en cache votre site sans précaution, le premier utilisateur se connectant par l’intermédiaire de ce fournisseur verrait sa propre page de la boîte de réception placée dans le cache et à disposition des visiteurs suivants du site. Ce n’est pas sympa du tout.
\nHeureusement, HTTP fournit une solution à ce problème. Il existe un certain nombre d’en-têtes HTTP indiquant aux caches amonts de différencier les contenus en cache selon certaines variables précises et d’indiquer aux mécanismes de cache de ne pas mettre en cache certaines pages. Nous allons examiner certains de ces en-têtes dans les sections qui suivent.
\nVaryLien vers cette rubrique#L’en-tête Vary définit quels en-têtes de requête un cache doit prendre en considération pour générer sa clé de cache. Par exemple, si le contenu d’une page Web dépend de la préférence de langue d’un utilisateur, on dit que la page « varie en fonction de la langue » (vary on language).
Par défaut, le système de cache de Django crée ses clés de cache en utilisant l’URL complète de la requête, par exemple "https://www.example.com/stories/2005/?order_by=author". Cela signifie que chaque requête vers cette URL utilisera la même version en cache, quels que soient les différences du client (« user-agent ») tels que ses cookies ou préférences de langue. Cependant, si cette page produit du contenu différent en fonction de certaines différences dans les en-têtes de la requête, tels qu’un cookie, une langue, une signature de client, etc. il est alors nécessaire d’utiliser l’en-tête Vary pour signifier aux mécanismes de cache que le contenu de la page dépend de ces éléments.
Pour faire cela avec Django, utilisez le décorateur de vue bien pratique django.views.decorators.vary.vary_on_headers(), comme ceci :
from django.views.decorators.vary import vary_on_headers\n\n@vary_on_headers('User-Agent')\ndef my_view(request):\n ...\nDans ce cas, un mécanisme de cache (tel que le propre intergiciel de cache de Django) mettra en cache des versions séparées de la page pour chaque type de client (« user-agent ») différent.
\nL’avantage d’utiliser le décorateur vary_on_headers plutôt que de définir manuellement l’en-tête Vary (en écrivant quelque chose comme response['Vary'] = 'user-agent') est que le décorateur complète l’en-tête Vary (qui peut déjà exister) au lieu de le redéfinir complètement ce qui pourrait écraser un éventuel contenu d’en-tête existant.
Il est possible de transmettre plusieurs en-têtes à vary_on_headers():
@vary_on_headers('User-Agent', 'Cookie')\ndef my_view(request):\n ...\nCela indique aux caches amonts de différencier les deux, ce qui signifie qu’à chaque combinaison de type de client et de cookie correspondra une valeur de cache propre. Par exemple, une requête avec le type de client Mozilla et la valeur de cookie foo=bar sera considérée différente d’une requête avec le type de client Mozilla et la valeur de cookie foo=ham.
Comme la variation selon les cookies est très courante, il existe un décorateur django.views.decorators.vary.vary_on_cookie(). Ces deux vues sont équivalentes :
@vary_on_cookie\ndef my_view(request):\n ...\n\n@vary_on_headers('Cookie')\ndef my_view(request):\n ...\nLes en-têtes transmis à vary_on_headers ne sont pas sensibles à la casse ; "User-Agent" est équivalent à "user-agent".
Vous pouvez aussi utiliser directement une fonction utilitaire django.utils.cache.patch_vary_headers(). Celle-ci définit ou complète l’en-tête Vary. Par exemple :
from django.shortcuts import render\nfrom django.utils.cache import patch_vary_headers\n\ndef my_view(request):\n ...\n response = render(request, 'template_name', context)\n patch_vary_headers(response, ['Cookie'])\n return response\npatch_vary_headers accepte une instance HttpResponse comme premier paramètre et une liste de noms d’en-têtes insensibles à la casse comme second paramètre.
Pour plus de détails sur les en-têtes Vary, consultez la spécification officielle de Vary.
D’autres problèmes de cache incluent la confidentialité des données et la problématique de l’emplacement de stockage des données en cas de caches en cascade.
\nUn utilisateur est généralement confronté à deux sortes de caches : son propre cache de navigateur (cache privé) et le cache de son fournisseur d’accès (cache public). Un cache public est partagé par de nombreux utilisateurs et contrôlé de manière externe. Cela pose des problèmes avec les données sensibles ; vous ne souhaitez probablement pas que votre numéro de compte bancaire soit stocké dans un cache public. Les applications Web doivent donc pouvoir indiquer aux caches quelles sont les données privées et celles qui sont publiques.
\nLa solution est d’indiquer que le contenu d’une page en cache devrait être « privé ». Pour faire cela avec Django, utilisez le décorateur de vue cache_control(). Exemple :
from django.views.decorators.cache import cache_control\n\n@cache_control(private=True)\ndef my_view(request):\n ...\nCe décorateur se charge d’envoyer les en-têtes HTTP appropriés en arrière-plan.
\nSignalons que les réglages de contrôle de cache « private » et « public » sont mutuellement exclusifs. Le décorateur s’assure que la directive « public » est enlevée si « private » doit être défini (et vice versa). Un exemple d’utilisation de ces deux directives pourrait être un site de blog qui propose à la fois des articles privés et publics. Les articles publics peuvent être mis en cache dans n’importe quel cache partagé. Le code suivant utilise django.utils.cache.patch_cache_control(), la façon manuelle de modifier l’en-tête de contrôle de cache (elle est appelée en interne par le décorateur cache_control()) :
from django.views.decorators.cache import patch_cache_control\nfrom django.views.decorators.vary import vary_on_cookie\n\n@vary_on_cookie\ndef list_blog_entries_view(request):\n if request.user.is_anonymous:\n response = render_only_public_entries()\n patch_cache_control(response, public=True)\n else:\n response = render_private_and_public_entries(request.user)\n patch_cache_control(response, private=True)\n\n return response\nIl est aussi possible de contrôler les caches amonts par d’autres moyens (voir RFC 7234 pour des détails sur le cache HTTP). Par exemple, même si vous n’exploitez pas l’infrastructure de cache du côté serveur Django, il est tout de même possible de demander aux clients de mettre en cache une vue pour un certain temps à l’aide de la directive max-age:
\nfrom django.views.decorators.cache import cache_control\n\n@cache_control(max_age=3600)\ndef my_view(request):\n ...\nSi vous utilisez l’intergiciel de cache, celui-ci définit déjà l’en-tête max-age avec la valeur du réglage CACHE_MIDDLEWARE_SECONDS. Dans ce cas, la valeur max_age personnalisée par le décorateur cache_control() est prioritaire et les valeurs d’en-têtes seront fusionnées correctement.
Toute directive de réponse Cache-Control valide est acceptée dans cache_control(). Voici quelques exemples supplémentaires :
no_transform=True
must_revalidate=True
stale_while_revalidate=nombre_secondes
La liste complète des directives connues se trouve dans le registre IANA (notez que toutes ne s’appliquent pas aux réponses).
\nSi vous souhaitez utiliser des en-têtes pour désactiver totalement le cache, never_cache() est un décorateur de vue qui ajoute les en-têtes nécessaires pour s’assurer que la réponse ne sera pas mise en cache par les navigateurs ou d’autres caches. Exemple :
from django.views.decorators.cache import never_cache\n\n@never_cache\ndef myview(request):\n ...\nMIDDLEWARELien vers cette rubrique#Si vous utilisez l’intergiciel de cache, il est important de placer chacun des deux éléments au bon endroit dans le réglage MIDDLEWARE. Ceci parce que l’intergiciel de cache a besoin de savoir à partir de quels en-têtes le stockage de cache doit varier. L’intergiciel ajoute toujours quelque chose à l’en-tête de réponse Vary autant qu’il le peut.
UpdateCacheMiddleware s’exécute durant la phase de réponse, lorsque les intergiciels sont exécutés en ordre inverse, et qu’un élément en haut de liste s’exécute en dernier pendant la phase de réponse. Ainsi donc, vous devez prendre soin de placer UpdateCacheMiddleware avant tout autre intergiciel susceptible d’ajouter quelque chose à l’en-tête Vary. Les modules d’intergiciel suivants sont concernés :
SessionMiddleware ajoute Cookie
GZipMiddleware ajoute Accept-Encoding
LocaleMiddleware ajoute Accept-Language
FetchFromCacheMiddleware, de son côté, s’exécute durant la phase de requête, lorsque les intergiciels sont exécutés de haut en bas, et qu’un élément en haut de liste s’exécute en premier pendant la phase de requête. L’intergiciel FetchFromCacheMiddleware doit également être exécuté après que tout autre intergiciel ne modifie l’en-tête Vary, c’est pourquoi il doit figurer dans la liste après ceux qui effectuent une telle modification.