Drupal et la gestion des requetes - cache drupal

Le cache drupal (intro)

Source: framabook ed2

Lorsque le cache est activé, Drupal enregistre dans la base de données du code HTML généré par PHP. Si une requête identique est rencontrée par la suite, Drupal retourne alors directement le code HTML sans exécuter à nouveau le code PHP.

Même si aucune option n’est activée pour le cache des pages, Drupal utilise quand même le cache pour les menus, les thèmes, le système de fichiers, etc.

• cache pour les utilisateurs anonymes : Les pages mises en caches dans leur intégralité sont servies uniquement pour les visiteurs anonymes. Lorsque l’utilisateur est identifié, il y a au moins le bloc affichant le nom de l’utilisateur qui diffère.
  Si vous avez un site vitrine visité uniquement par des anonymes, cette option est fortement recommandée pour améliorer les performances.
• Cache des blocs : Le code HTML des blocs peut ne pas varier d’un utilisateur identifié à l’autre. Ce cache permet donc d’améliorer les performances pour un site communautaire.
• Durée de vie minimale de la mémoire cache : Temps minimum avant que les pages ne soient pas recréées. Choisir <aucun> est une bonne solution ici.
• Expiration des pages en cache : Durée de vie maximale d’une page dans le cache.

Lors du dev, n’activer aucune option de admin/config/development/performance

Source : https://www.drupal.org/node/326504

2 types de traffic (avec des attributs différents) : traffic anonyme et authentifié.
Pour le traffic anonyme, la conf de base et les modifs concernant la performance concerne la majeur partie des cas. Pour le traffic authentifié, voir le paragraphe "user authentifiés"

conf de base

 falseadmin/config/development/performance
On recommande de cacher les pages et les blocs

Vider cache: avec devel ou drush cc all

Le cache de bloc est désactivé par certains modules (ex: Taxonomy Access Control Lite og ...)

Pour les user authentifiés

Essayer l'un de ces 2 modules :

• si srv partagé : boost (cache de p statiques pour les surfeurs non logués) accomagné de authcache ou advcache (pour user logué)
• Si sur serveur dédié ou VPS, on a plusieurs options:
  boost,  authcache,  cacherouter,  Varnish , memcache...

Performances

Pour php : avoir droits root pour install, pour réduire usage cpu. Citons APC et eAccelerator

Cache de db : https://www.drupal.org/project/memcache permet d'allouer de la mémoire (là où on a besoin de moins) pour l'attribuer là on on en manque - cache les objets mémoire.
Il peux stocker le résultat de requetes dans la mémoire pour un temps spécifié, ce qui réduit l'utilisation de la db.

Cache reverse proxy (du serveur web)

Varnish est très utilisé.

Un reverse proxy  récupère les ressources (pages, images, fichiers...) avant qu'un surfeur les demande. Ces ressources sont stockées dans la mémoire virtuelle, et sont récupérées rapidement quand demandées.

Voir aussi http://lapetitepausetechnique.net/2012/10/les-caches-de-drupal7-base-de-donnees-et-memcached/

gestion des requetes

Le serveur web recoit une requete, alors index.php est chargé et lancé. Puis:

1. drupal recherche le bon settings.php, le charge et le lance.
2. si la requete vient d'un anonyme (user non logué) -> on vérifie cache (si elle y existe, page envoyée au srv)
   le cache des pages drupal n'est pas utilisé pour les users logués.
3. initialisation de la connexion à bd, conf systeme des var et var de sessions PHP
4. initialisation de la langue du systeme. Plein de fichiers sont chargés et executés (modules du core et des modules actifs)
5. drupal regarde si le site est en ligne ou en maintenance
   • Si en maintenance: drupal génère la page "site en maintenance" + appels de fonctions qui génère des sections de la page
   • Si on-line ou qu'un user logué y accède (et site en maintenance): drupal recherche quelles fonctions utiliser pour générer les données, et les appelle. Idéalement, on récupère du contenu non rendu (raw), mais parfois en rendu ou partiellement rendu.
6. drupal recherche la méthode de delivery à utiliser pour la page, et appelle la fonction correspondante
7. pour les requetes de page HTML, la fonction par défaut de delivery de page crée le header HTTP, utilise le thème pour rendre le contenu raw en HTML, affiche le résultat HTML (envoyé au srv web), enregistre les informations de session du user en db, et sors.
   delivery Ajax request: idem mais au lieu d'utiliser le theme -> HTML on rend vers JSON (JavaScript Object Notation)

fonctions liées au cache drupal: cache_set() et cache_get() ; cache_clear_all() ; voir aussi hook_flush_caches()

Vers mes notes "Views 3 et le cache" - cron, module system et le cache

 Caching: Modules that make Drupal scale (Comparison of a selection of performance and scalability modules) à https://groups.drupal.org/node/21897

Voir le module Cache Debug (cf http://www.pixelite.co.nz/article/debugging-drupal-performance-with-cach...)
http://drupal.org/project/cache_actions  qui fonctionne avec rules
http://drupal.org/project/blockcache_alter conf par role, user... (comme page_manager et panels) pour chaque bloc du site.

https://www.drupal.org/node/326504 Caching to improve performance