Le livre de

Memcached

De loin le plus rapide et le type le plus efficace de cache disponible sous Django, Memcached est un framework de cache entièrement basé sur la mémoire et développé à l’origine pour gérer les fortes charges de LiveJournal (http://www.livejournal.com/) et ensuite rendu open-source par Danga Interactive (http://danga.com/). Il est utilisé par des sites tel que Slashdot et Wikipédia pour réduire les accès en base de données et dramatiquement augmenter les performances du site.

Memcached est disponible librement à l’adresse http://danga.com/memcached/. Il tourne en tant que démon et une quantité précise de RAM lui est alloué. Sa première caractéristique est de fournir une interface - une interface rapide commme la lumière - pour ajouter, récupérer et supprimer des données arbitraires du cache. Toutes les données sont stockées directement en mémoire, il n’y a donc pas de surcharge liée à la base de données ou au système de fichier.

Après avoir installé Memcached, vous devrez installer la liaison Python Memcached, qui n’est pas directement livrée avec Django. Ces liaisons se trouvent dans un unique module Python, memcache.py, disponible à l’adresse http://www.tummy.com/Community/software/python-memcached/.

Pour utiliser Memcached avec Django, placez CACHE_BACKEND à memcached://ip:port/, où ip est l’adresse IP du démon Memcached et port est le port sur lequel tourne Memcached.

Dans cet exemple, Memcached tourne sur le port 11211 de localhost (127.0.0.1):

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

Une fonctionnalité excellente de Memcached est sa capacité à partager le cache sur de multiples serveurs. Cela signifi que vouspouvez lancer les démons Memcached sur de multiples machines, et que le programme traitera le groupe de machines comme un cache unique, sans avoir besoin de dupliquer les valeurs de cache sur chacune des machines. Pour tirer partie de cette fonctionnalité sous Django, incluez toutes les adresses de serveur dans CACHE_BACKEND, séparées par des point virgules.

Dans cet exemple, la cache est partagé sur les instances memcached tournant sur les adresses IP 172.19.26.240 et 172.19.26.242, toutes deux sur le port 11211:

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

Dans l’exemple suivant, le cache est réparti sur les instances Memcached tournant sur les adresses IP 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), et 172.19.26.244 (port 11213):

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

Une dernière chose au sujet de Memcached est que le cache basé sur la mémoire présente un désavantage important. Puisque les données mises en cache sont stockées uniquement en mémoire, les données seront perdues si votre serveur plante. Clairement, la mémoire n’est pas destinée à un stockage permanent des données, aussi ne comptez pas sur le cache en mémoire comme unique source de stockage des données. Sans aucun doute, aucun des moteurs de cache Django ne doit être utilisé pour le stockage permanent - ils sont tous destinés à la mise en cache, et non pas au stockage - mais nous éclairons ce point parce que la mise en cache en mémoire est particulièrement temporaire.

Cache en base de données

Pour utiliser une table de la base de données en guise de cache, créez une table cache dans votre base et pointez le système de cache Django sur celle-ci:

Tout d’abord, créez une table cache grâce à cette commande:

python manage.py createcachetable [cache_table_name]

où [cache_table_name] est le nom de la table de la base de données à créer. Ce nom peut être celui que vous désirez, du moment qu’il sagisse d’un nom de table valide qui ne soit pas déjà utilisé dans votre base de données. Cette commande crée un table unique dans la base, au format propre au système de cache que Django attends.

Une fois que vous avez créez la table, fixez votre paramètre CACHE_BACKEND à "db://tablename", où tablename est le nom de table de votre base de données. Dans cet exemple, le nom de la table est my_cache_table:

CACHE_BACKEND = 'db://my_cache_table'

L’arrière-plan de la mise en cache en base de données utilise la même base que celle précisée dans votre fichier de paramètres. Vous ne pouvez pas utiliser un arrière-plan de base de données différent pour votre table de cache.

Cache sur le système de fichier

Pour stocker les éléments cachés sur un système de fichier, utilisez le type de cache "file://" en guise de CACHE_BACKEND, en précisant le répertoire de votre système de fichier qui doit stocker les données mises en cache.

Par exemple, pour stocker les données cachées dans /var/tmp/django_cache, utilisez ce paramètre:

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

Notez les trois barres obliques au début de l’exemple précédent. Les deux premiers correspondent à file://, et le troisième correspond au premier caractère du chemin vers le répertoire, /var/tmp/django_cache. Si vous êtes sous Windows, placez la lettre correspondant au lecteur après file://, comme ceci: file://c:/foo/bar.

Le chemin du répertoire doit être absolut - c’est à dire qu’il doit commencer à la racine de votre système de fichier. Que vous placiez une barre oblique à la fin du paramètre importe peu.

Assurez vous que le répertoire sur lequel pointe ce paramètre existe bine et qu’il soit accessible en lecture et en écriture par l’utilisateur système sous lequel tourne votre serveur web. En continuant avec l’exemple précédent, si votre serveur tourne sous l’utilisateur apache, assurez vous que le répertoire /var/tmp/django_cache existe et est accessible à l’utilisateur apache en écriture et en lecture.

Chaque valeur de cache sera stocké dans un fichier séparé dont le contenu sont les données du cache sérialisées («picklées»), grâce au module Python pickle. Chaque nom de fichier est la clef du cache, échappé pour être utilisé sans soucis par le système de fichier.

Cache en mémoire locale

Si vous voulez les avantages de la vitesse du cache en mémoire sans avoir la possibilité d’utiliser Memcached, pensez au cache mémoire local. Ce cache est multi-processus et supporte les thread, mais n’est pas aussi efficace que Memcached du fait de son système de verrous simpliste et de sa stratégie d’allocation de la mémoire.

Pour l’utiliser, fixez CACHE_BACKEND tà``’locmem:///’``, par exemple:

CACHE_BACKEND = 'locmem:///'

Cache simple (pour le développement)

Un cache mémoire simple, mono processus, est diponible grâce à 'simple:///', par exemple:

CACHE_BACKEND = 'simple:///'

Ce cache sauve uniquement les données cachées dans un processus, ce qui signifie qu’il doit être utilisé uniquement lors du développement ou dasn des environnements de tests.

Cache factice (pour le développement)

Finalement, Django est fourni avec un cache «factice» qui en fait ne cache rien; il implémente simplement l’interface de cache sans rien faire d’autre.

Ceci est pratique si vous avez un site en production qui utilise massivement le cache en divers endroits et un environnement de développement/test pour lequel vous ne voulez pas utiliser le cache. Dans ce cas, fixez CACHE_BACKEND à 'dummy:///' dans le fichier de paramètres de votre environnement de développement, par exemple:

CACHE_BACKEND = 'dummy:///'

En conséquence, votre environnement de développement n’utilisera pas le cache, alors que votre environnement de production continuera à le faire.

Arguments de CACHE_BACKEND

Chaque arrière-plan de mise en cache peut prendre des arguments. Ils sont précisés dans le paramètre CACHE_BACKEND sous forme de chaîne de requête. Les arguments possibles sont les suivants:

• timeout: le délai d’expiration par défaut, en seconde, à utiliser pour le cache. La valeur par défaut de cet argument est de 300 seconds (5 minutes).

• max_entries: pour la mémoire locale, simple, et pour la base de données, le nombre maximal d’entrées autorisées dans le cache avant que les anciennes valeurs soient supprimé. La valeur par defaut de cet argument est 300.

• cull_frequency: le ratio entre les entrées qui sont éliminées lorsque max_entries est atteinte. Le ration actuel est 1/cull_frequency, donc fixez cull_frequency=2 pour éliminier la moitié des entrées lorsque max_entries est atteinte.

  Une valeur à 0 pour cull_frequency signifie que l’intégralité du cache sera supprimé lorsque max_entries est atteint. Cela rends la suppression beaucoup plus rapide au détriment d’un plus grand manque de cache. La valeur de cet argement est 3 par défaut.

Dans cet exemple, timeout vaut 60:

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

Dans cet exemple, timeout vaut 30 et max_entries vaut 400:

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

Les arguments invalides sont silencieusement ignorés, tout comme les valeurs invalides des arguments connus.

Préciser un cache par vue dans l’URLconf

Les exemples de la section précédente ont codé en dur le fait que la vue soit mise en cache, puisque cache_page altère la fonction my_view en place. Cette approche couple votre vue au système de cache, ce qui n’est pas idéal pour plusieurs raisons. Par exemple, vous pourriez vouloir réutiliser la vue dans un autre site, sans cache, ou vous pourriez vouloir distribuer les vues à des gens qui voudrons les utiliser sans être mises en cache. La solutions à ces problèmes est de spécifier le cache par vue dans l’URLconf plutôt qu’à côté des fonctions vue elles-mêmes.

Réaliser ceci est très facile: emballez simplement la fonction vue avec un cache_page lorsque vous y faite référence dans l’URLconf. Voici l’ancien URLconf utilisé plus tôt:

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

Voici la même chose, avec my_view emballé dans cache_page:

from django.views.decorators.cache import cache_page

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', cache_page(my_view, 60 * 15)),
)

Si vous prenez cette approche, n’oubliez pas d’importer cache_page à l’intérieur de votre URLconf.

Utiliser les en-têtes Vary

L’en-tête Vary défini quelles en-têtes de requête le mécanisme de cache doit prendre en compte lorsqu’il construit son cache. Par exemple, si le contenu d’une page web dépends des préférences de langues de l’utilisateur, la page est dite «vary»able selon la langue.

Par défaut, le système de cache de Django crée ses clefs de cache en utilisant le chemin demandé (par exemple, "/stories/2005/jun/23/bank_robbed/"). Cela signifie que cet URL utilisera la même version cachée, selon les différences avec l’agent utilisateur tels que les cookies ou les préférences de langue. Cependant, si cette page produit des contenus différents basés sur des différences dans les en-tête de la requête - comme les cookies, ou une langue, ou un agent utilisateur - vous devrez utiliser l’en-tête Vary pou indiquer aux mécanismes de cache que la page rendue dépends de cela.

Pour faire cela sous Django, utilisez le très pratique décorateur vary_on_headers dans la vue, comme ceci:

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

Dans ce cas, un mécanisme de cache (tel que le propre middleware de cache de Django) placera en cache une version séparée de la page pour cache agent utilisateur unique.

L’avantage d’utiliser le décorateur vary_on_headers au lieu de paramétrer manuellement l’en-tête Vary (en utilisant quelque chose du genre response['Vary'] = 'user- agent') est que le décorateur ajoute à l’en-tête Vary (qui peut déjà exister), plutôt que le créer à partir de rien et potentiellement écraser tout ce qui pouvait être déjà dedans.

Vous pouvez passer de multiples en-têtes à vary_on_headers():

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

Ceci précise aux caches amonts de «vary»er pour les deux, ce qui signifie que chaque combinaison d’agent utilisateur et de cookie obtiendra sa propre valeur de cache. Par exemple, une requête avec l’agent utilisateur Mozilla avec la valeur de cookie foo=bar sera considérée comme différente d’une requête avec l’agent Mozilla et la valeur de cookie foo=ham.

Puisque «vary»er sur les cookies est chose courante, il existe un décorateur vary_on_cookie. Ces deux vues sont équivalentes:

@vary_on_cookie
def my_view(request):
    # ...

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

Les en-têtes que vous passez à vary_on_headers ne sont pas sensibles à la casse; "User-Agent" est identique à "user-agent".

Vous pouvez aussi utiliser une fonction d’assistance, django.utils.cache.patch_vary_headers, directement. Cette fonction fixe, ou ajoute à, Vary header, par exemple:

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 accepte une instance de HttpResponse pour premier argument et une liste/tuple de nom d’en-tête insensible à la casse pour second argument.

Autres en-têtes de cache

Les autres problèmes avec la mise en cache sont la confidentialité des données et la question de l’emplacement de stockage dans une cascace de caches.

Un utilisateur fait habituellement face à ces deux types de caches: celui de son navigateur (le cache privé) et celui de son fournisseur d’accès (le cache public). Un cache public est utilisé par de multiples utilisateurs et contrôlé par un tiers. Ceci pose problème lorsqu’il s’agit de données sensibles que vous ne voulez pas, comme par exemple votre numéro de compte banquaire, stocker dans un cache publique. Ainsi les applications web ont besoin de connaitre un moyen de dire aux caches quelles données sont privées et quelles données sont publique.

La solution consiste à préciser que le cache de la page doit être «privé». Pour ce faire avec Django, utilsez le décorateur de vue cache_control:

from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request):
    # ...

Ce décorateur prends soins d’envoyer l’en-tête HTTP approprié en coulisses.

Il y à d’autres façons de contrôler les paramètres du cache. Par exemple, HTTP autorise les applications à faire les choses suivantes:

• définir la durée de vie maximum de la page cachée.
• préciser si un cache doit toujours vérifier s’il éxiste de nouvelles versions, ne délivrant le contenu caché que lorsqu’il n’y a pas de changements (certains caches peuvent délivrer du contenu caché même si la page sur le serveur a changé, simplement parce que le délai de la copie cachée n’a pas encore expiré).

Sous Django, utilisez le décorateur de vue cache_control pour préciser ces paramètres de cache. Dans cet exemple, cache_control indique aux caches qu’il faut revalider le cache lors de chaque accès et qu’il faut stocker les versions cachées durant, au moins, 3 600 secondes:

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

Toute directive HTTP Cache-Control valide est permise dans cache_control(). Voici une liste complète:

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

.. admonition:: Note

Le middleware de cache fixe déjà les en-têtes de cache max-age` avec la valeur du paramètre CACHE_MIDDLEWARE_SETTINGS. Si vous utilisez un max_age personnalisé dans un décorateur cache_control, le décorateur prendra précédence, et les valeurs de l’en-tête seront correctement fusionnées).