2. La Communauté Drupal
1000 cerveaux sont bien plus puissants qu‟un seul
Les fonctionnalités que nous cherchons existent déjà!
Ne réinventons pas la roue!
Il ya des développeurs Drupal qui sont des génies!
Profitons de leur expérience!
3. Le problème
Drupal est gourmand. L‟affichage d‟une simple page
peut parfois engendrer l‟exécution de 50 voir 150
requêtes à la DB
Imaginez vous cette même page appelée par plusieurs
internautes en même temps. On obtient alors des
centaines de requêtes et informations recalculées
inutilement qui vont solliciter les serveurs et vont ainsi
consommer du CPU et de la RAM
4. Performance, rendement Vs Evolutivité
Evolutivité (Scalability)
Capacité à faire face à une augmentation des utilisateurs et des
données
Rendement (Performance)
Temps de réponse du serveur + temps de chargement de la page
Notre approche aujourd‟hui
Améliorer le temps de réponse de notre application Drupal pour des
utilisateurs non identifiés
5. Ce que nous ne verrons pas
Front end performance
Back end performance
Reverseproxy avec Varnish
Apache mod_deflate
APC
Memcache
Cache router
Authcache
Query cache
6. Alors? Qu’allons nous voir?
Principes de caching
Evaluer le rendement avec AB et Devel
Le cache du cœur de Drupal
Gestion du cache: Cache browser
Gestion du cache: Content Refresh
7. Principes du Caching
Eviter de répéter une même opération en gardant le
résultat
Ex.: Calculer 2+3,
Écrire
le résultat sur un papier (cacher dans la BD)
Mémoriser le résultat (cacher en mémoire)
8. Qu’allons nous mettre dans le cache
pour des utilisateurs non identifiés?
Des pages, des pages et rien que des pages…
Nous oublions les views, les bloques…
9. Comment évaluer la preformance?
Nous ne pouvons pas mettre en place des politiques
de performances sans une évaluation des ces dernières
Evaluer avec Apache Bench (AB)
Facil, simple et nous l‟avons tous installé par défaut
Evaluer avec Devel
Pluscomplexe, non compatible avec le cache agressif de
Drupal, utile si nous n‟avons pas accès a la shell du serveur
10. Apache Bench (AB)
AB test pour un utilisateur non identifié
ab -c 1 -n 100 http://example.dev/
Où
-c = concurrence des requêtes
-n = total des requêtes vers la page
Dans notre cas nous allons faire 100 requêtes vers la home page
http://example.dev/
Un seul indicateur: „Requests per second‟
Le nombre de requêtes (vers notre home page) que notre serveur
peut “servir” en une seconde.
C‟est avec cet indicateur que nous allons évaluer nos différentes
politiques de performance. Plus il sera élevé, plus notre
application sera performante.
11. Evaluer avec Devel
Télécharger le module devel:
http://drupal.org/project/devel
Habiliter la composante: Performance Logging
Configurer dans admin/settings/performance_logging
Detailed logging: Enabled
13. El caché del Core de Drupal
Le système de cache de Drupal enregistre les données
dans las tables suivantes:
Par défaut Configurable
1. cache – enregistre une copie de la 1. cache_page – enregistre une
configuration de nos modules, de la copie des pages mais
structure de toutes nos autres tables seulement pour les utilisateurs
et toutes les informations concernant non identifiés
le thème utilisé sur le site 2. cache_block – enregistre une
2. cache_menu – enregistre une copie copie des bloques
du menu de navigation et des URLs
qui lui sont associées
3. cache_filter – une copie de tous les
contenus une fois qu‟ils ont été filtrés
par le système de filtre
4. cache_form – enregistre tous les
formulaires soumis à la FormApi
14. Activer le cache du coeur de Drupal
Nous allons sur admin/settings/performance
Cache des pages
Mode de cache: Normal ou agressif
Durée de vie minimale de la mémoire cache: 3 heures
Compression des pages: Activé
Pour savoir si notre serveur réalize déjà la compression:
http://www.whatsmyip.org/http_compression/
Cache des bloques
Pas besion pour le moment car nous travaillons qu‟avec les
utilisateurs non identifiés
15. Activer le cache du coeur de Drupal
Optimisation de la bande-passante
Optimise les fichiers CSS: Activé(en production)
Optimise les fichiers Javascript: Activé(en production)
Sauver la configuration
Maintenant nous pouvons voir comment la table
cache_page commence à se remplir
Tester à nouveau avec AB ou Devel
16. Gestion du cache: Cache Browser
Cache Browser
http://drupal.org/project/cache_browser
Nous avons aussi besion du module
http://drupal.org/project/format_number
Nous permet de vider le cache de chaque table ou plus
finement d‟un registre d‟une table. De cette manière nous
ne devons pas vider le cache dans son entier.
Nous permet de voir le contenu de chaque registre et ainsi
voir comment une page est cachée.
17. Gestion du cache: Content Refresh
Content Refresh
http://drupal.org/project/content_refresh
Hypothèse: Les utilisateurs non identifiés peuvent laisser des
commentaires et le cache du coeur est activé.
Sans Content Refresh, ils ne voient pas leur nouveau
commentaire !
Avec Content Refresh oui!
Quand il y a un nouveau commentaire, le cache de cette page est
éliminé y donc l‟utilisateur anonyme voir son nouveau commentaire.
Quand on enregistre un nouveau node, le cache de la home page est
éliminé
Voir la configuration sur admin/content/content-refresh
18. En résumé
La statégie de performance pour les utilisateurs non
identifíes se base sur:
Activé le cache u cœur de Drupal seulement pour les
pages
Administrer le cache avec
Cache Browser (administration)
Content refresh (expiration)
Reste à voir dans ce cadre
Les modules Cache Actions et Boost
