IV. Des outils supplémentaires 178
17. Les messages 192
17.2. Dans les détails
Nous avons dit qu’il était possible de créer des niveaux de messages personnalisés. Il faut savoir qu’en réalité les niveaux de messages ne sont en fait que des entiers constants :
Voici la relation entre niveau et entier par défaut :
— DEBUG : 10
— INFO : 20
— SUCCESS : 25
— WARNING : 30
— ERROR : 40
Au final, ajouter un niveau suffit juste à créer une nouvelle constante. Par exemple :
Il est dès lors tout aussi possible d’ajouter des tags à un message :
Sachez que vous pouvez également limiter l’affichage des messages à un certain niveau (égal ou supérieur). Cela peut se faire de deux manières différentes. Soit depuis lesettings.py en mettant MESSAGE_LEVEL au niveau minimum des messages à afficher (par exemple 25 pour ne pas montrer les messages DEBUG etINFO), soit en faisant cette requête dans la vue :
En utilisant cela et pour cette vue uniquement, tous les messages dont le niveau est égal ou supérieur à 10 (la valeur de messages.DEBUG) seront affichés. On préfèrera la méthode globale avec le settings.py, permettant d’afficher des informations supplémentaires lors du développement, sans avoir à changer le code. En effet, il suffit de mettre le minimum àSUCCESS
sur votre environnement de production pour cacher les messages de debug et d’info.
Enfin, si vous souhaitez faire une application réutilisable, il se peut que les gens qui souhaitent l’intégrer n’utilisent pas le système de messages sur leur projet. Pour éviter de provoquer des erreurs, si vous pensez que le message est facultatif, vous pouvez spécifier à Django d’échoue silenciement :
Dans ce cas, le message sera bien envoyé si les messages sont activés pour le projet en cours.
Sinon la ligne sera ignorée, tout simplement.
17.3. En résumé
— Les messages permettent d’afficher des notifications à l’utilisateur, en cas de succès ou d’échec lors d’une action, ou si un événement particulier se produit.
— Il existe différents types de messages : ceux d’information, de succès, d’erreur, d’avertis-sement, et enfin de débogage.
— Il est possible de créer son propre type de message et de configurer son comportement.
— L’affichage de messages peut être limité : chaque type de message est caractérisé par une constante entière, et nous pouvons afficher les messages ayant un niveau supérieur ou égal à un certain seuil, via messages.set_level.
Lorsqu’un site devient populaire, que son trafic augmente et que toutes les ressources du serveur sont utilisées, nous constatons généralement des ralentissements ou des plantages du site. Ces deux cas de figure sont généralement à éviter, et pour ce faire il faut procéder à des optimisations.
Une optimisation courante est la mise en cache, que nous aborderons dans ce chapitre.
i
Un tutoriel complet à propos de la mise en cache existe ici . Il vous donnera des informations plus poussées pour améliorer les performances de votre application django.18.1. Cachez-vous!
Avant d’aborder l’aspect technique, il faut comprendre l’utilité de la mise en cache. Si vous présentez dans une vue des données issues de calculs très longs et complexes (par exemple, une dizaine de requêtes SQL), l’idée est d’effectuer les calculs une fois, de sauvegarder le résultat et de présenter le résultat sauvegardé pour les prochaines visites, plutôt que de recalculer la même donnée à chaque fois.
En effet, sortir une donnée du cache étant bien plus rapide et plus simple que de la recalculer, la durée d’exécution de la page est largement réduite, ce qui laisse donc davantage de ressources pour d’autres requêtes. Finalement, le site sera moins enclin à planter ou être ralenti.
Une question subsiste : où faut-il sauvegarder les données ? Django enregistre les données dans un système de cache, or il dispose de plusieurs systèmes de cache différents de base. Nous tâcherons de les introduire brièvement dans ce qui suit.
Chacun de ces systèmes a ses avantages et désavantages, et tous fonctionnent un peu différemment.
Il s’agit donc de trouver le système de cache le plus adapté à vos besoins.
La configuration du système de cache se fait grâce à la variableCACHESde votresettings.py.
18.1.1. Dans des fichiers
Un système de cache simple est celui enregistrant les données dans des fichiers sur le disque dur du serveur. Pour chaque valeur enregistrée dans le cache, le système va créer un fichier et y enregistrer le contenu de la donnée sauvegardée. Voici comment le configurer :
La clé'LOCATION'doit pointer vers un dossier, et non pas vers un fichier spécifique. Si vous êtes sous Windows, voici ce à quoi doit ressembler la valeur de 'LOCATION' : 'c:/mon/dossier' (ne pas oublier le c:/ ou autre identifiant de votre disque dur). La clé 'BACKEND' indique simplement le système de cache utilisé (et sera à chaque fois différente pour chaque système présenté par la suite).
Une fois ce système de cache configuré, Django va créer des fichiers dans le dossier concerné.
Ces fichiers seront « sérialisés » en utilisant le module pickle pour y encoder les données à
sauvegarder. Vous devez également vous assurer que votre serveur web a bien accès en écriture et en lecture sur le dossier que vous avez indiqué.
18.1.2. Dans la mémoire
Un autre système de cache simple est la mise en mémoire. Toutes vos données seront enregistrées dans la mémoire vive du serveur. Voici la configuration de ce système :
Si vous utilisez cette technique, faites attention à la valeur de'LOCATION'. En effet, si plusieurs sites avec Django utilisant cette technique de cache tournent sur le même serveur, il est impératif que chacun d’entre eux dispose d’un nom de code différent pour'LOCATION'. Il s’agit en réalité juste d’un identifiant de l’instance du cache. Si plusieurs sites partagent le même identifiant, ils risquent d’entrer en conflit.
18.1.3. Dans la base de données
Pour utiliser la base de données comme système de cache, il faut avant tout créer une table dans celle-ci pour y accueillir les données. Cela se fait grâce à une commande spéciale de manage.py :
où nom_table_cacheest le nom de la table que vous allez créer (faites bien attention à utiliser un nom valide et pas déjà utilisé). Une fois cela fait, tout ce qu’il reste à faire est de l’indiquer dans le settings.py:
Ce système peut se révéler pratique et rapide si vous avez dédié tout un serveur physique à votre base de données ; néanmoins, il faut disposer de telles ressources pour arriver à quelque chose de convenable.
18.1.4. En utilisant Memcached
Memcached est un système de cache un peu à part. Celui-ci est en réalité indépendant de Django, et le framework ne s’en charge pas lui-même. Pour l’utiliser, il faut avant tout lancer un programme responsable lui-même du cache. Django ne fera qu’envoyer les données à mettre en cache et les récupérer par la suite, c’est au programme de sauvegarder et de gérer ces données.
Si cela peut sembler assez pénible à déployer, le système est en revanche très rapide et proba-blement le plus efficace de tous. Memcached va enregistrer les données dans la mémoire vive, comme le système vu précédemment qui utilisait la même technique, sauf qu’en comparaison de ce dernier Memcached est bien plus efficace et utilise moins de mémoire.
Memcached n’existe officiellement que sous Linux. Si vous êtes sous Debian ou dérivés, vous pouvez l’installer grâce à apt-get install memcached. Pour les autres distributions, référez-vous à la liste des paquets fournis par votre gestionnaire de paquets. Une fois que Memcached est installé, vous pouvez lancer le démon en utilisant la commande memcached -d -m 512 -l 127.0.0.1 -p 11211, où le paramètre -d permet le lancement du démon, -m indique
la taille maximale de mémoire vive allouée au cache (en mégaoctets), et -l et -p donnent respectivement l’adresse IP et le port d’écoute du démon.
La configuration côté Django est encore une fois relativement simple :
La clé 'LOCATION' indique la combinaison adresse IP/port depuis laquelle Memcached est accessible. Nous avons adapté la valeur de la variable à la commande indiquée ci-dessus.
18.1.5. Pour le développement
Pour terminer, il existe un dernier système de cache. Celui-ci ne fait rien (il n’enregistre aucune donnée et n’en renvoie aucune). Il permet juste d’activer le système de cache, ce qui peut se révéler pratique si vous utilisez le cache en production, mais que vous n’en avez pas besoin en développement. Voici sa configuration :
?
Au final, quel système choisir ?Cela dépend de votre site et de vos attentes. En développement, vous pouvez utiliser le cache de développement ou le cache mémoire (le simple, pas celui-ci utilisant Memcached) si vous en avez besoin. En production, si vous avez peu de données à mettre en cache, la solution la plus simple est probablement le système utilisant les fichiers.
En revanche, lorsque le cache devient fortement utilisé, Memcached est probablement la meilleure solution si vous pouvez l’installer. Sinon utilisez le système utilisant la base de données, même s’il n’est pas aussi efficace que Memcached, il devrait tout de même apaiser votre serveur.
18.2. Quand les données jouent à cache-cache
Maintenant que notre cache est configuré, il ne reste plus qu’à l’utiliser. Il existe différentes techniques de mise en cache que nous expliquerons dans ce sous-chapitre.
18.2.1. Cache par vue
Une méthode de cache pratique est la mise en cache d’une vue. Avec cette technique, dès que le rendu d’une vue est calculé, il sera directement enregistré dans le cache. Tant que celui-ci sera dans le cache, la vue ne sera plus appelée et la page sera directement cherchée dans le cache.
Cette mise en cache se fait grâce à un décorateur : django.views.decora tors.cache.cache_page. Voici son utilisation :
Listing 104 – Une vue mise en cache pour 15 minutes
Le paramètre du décorateur correspond à la durée après laquelle le rendu dans le cache aura expiré. Cette durée est exprimée en secondes. Autrement dit, ici, après 15 fois 60 secondes — donc 15 minutes — la donnée sera supprimée du cache et Django devra régénérer la page, puis
remettre la nouvelle version dans le cache. Grâce à cet argument, vous êtes assurés que le cache restera à jour automatiquement.
Bien évidemment, chaque URL aura sa propre mise en cache. En effet, pour lire_article, il est normal que /article/42 et /article/1337ne partagent pas le même résultat en cache (étant donné qu’ils n’affichent pas le même article).
Il est également possible de spécifier une mise en cache directement depuis les URLconf. Ainsi, la mise en cache de vues génériques est également possible :
Ici, le décorateur @cache_page est tout de même appliqué à la vue. Faites bien attention à inclure la vue sous forme de référence, et non pas sous forme de chaîne de caractères.
18.2.2. Dans les templates
Il est également possible de mettre en cache certaines parties d’un template. Cela se fait grâce au tag{% cache %}. Ce tag doit au préalable être inclus grâce à la directive{% load cache %}. De plus, cacheprend deux arguments au minimum : la durée d’expiration de la valeur (toujours en secondes), et le nom de cette valeur en cache (une sorte de clé que Django utilisera pour retrouver la bonne valeur dans le cache) :
Ici, nous enregistrons dans le cache notre carrousel. Celui-ci expirera dans 500 secondes et nous utilisons la clé carrousel.
Sachez que vous pouvez également enregistrer plusieurs copies en cache d’une même partie de template dépendant de plusieurs variables. Par exemple, si notre carrousel est différent pour chaque utilisateur, vous pouvez réutiliser une clé dynamique et différente pour chaque utilisateur.
Ainsi, chaque utilisateur connecté aura dans le cache la copie du carrousel adaptée à son profil.
Exemple :
18.2.3. La mise en cache de bas niveau
Il arrive parfois qu’enregistrer toute une vue ou une partie de template soit une solution exagérée, et non adaptée. C’est là qu’interviennent plusieurs fonctions permettant de réaliser une mise en cache de variables bien précises. Presque tous les types de variables peuvent être mis en cache. Ces opérations sont réalisées grâce à plusieurs fonctions de l’objet cache du module django.core.cache. Cet objet cache se comporte un peu comme un dictionnaire. Nous pouvons lui assigner des valeurs à travers des clés :
Ici, la clé 'ma_cle'contenant la chaîne de caractères'Coucou !' a été enregistrée pendant 30 secondes dans le cache (l’argument de la durée est optionnel ; s’il n’est pas spécifié, la valeur par défaut de la configuration sera utilisée). Vous pouvez essayer, après ces 30 secondes,get renvoie None si la clé n’existe pas ou plus :