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!
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
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
Ce que nous ne verrons pas Front end performance Back end performance Reverse proxy avec Varnish Apache mod_deflate APC Memcache Cache router Authcache Query cache
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
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)
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
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 Plus complexe, non compatible avec le cache agressif de Drupal, utile si nous n avons pas accès a la shell du serveur
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.
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
Faisons une première évaluation Con AB Con Devel
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 configuration de nos modules, de la structure de toutes nos autres tables et toutes les informations concernant le thème utilisé sur le site 2. cache_menu enregistre une copie 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 1. cache_page enregistre une copie des pages mais seulement pour les utilisateurs non identifiés 2. cache_block enregistre une copie des bloques
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
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
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.
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
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