Principe de communication
Les communications entre notre application (ici il s’agira surtout de SPIP, mais le principe vaut pour d’autres applications) et notre proxy inverse Varnish se font par l’entremise des entêtes HTTP émises par l’application.
Nous introduisons les header()
suivants :
X-Varnish-TTL: 120
Cet entête indique que la page doit avoir un TTL, dans Varnish, de 120 secondes ; dans SPIP il sera émis dans les conditions suivantes :
- implicitement, en prenant la durée de cache de la page :
TTL = min(durée du cache, 600)
- ou bien explicitement via la balise
#HTTP_HEADER{X-Varnish-TTL: 120}
L’appel #HTTP_HEADER{X-Varnish-TTL: 0}
permet de dire à Varnish de ne pas conserver la page produite (par exemple parce qu’elle contient du code en PHP qu’on veut faire tourner à chaque hit).
X-Varnish-Purge: *
Cet entête indique à Varnish tout purger ; il est émis par la fonction suivre_invalideur()
, à chaque modification des données. Il est également émis lorsqu’un changement de date provoque la publication d’un « article post-daté ».
De plus Varnish pourra aussi, indépendamment des entêtes envoyés par l’application, se baser sur l’URL pour invalider certaines pages.
Ainsi :
- l’URL
…?var_mode=calcul
est détectée par Varnish (indépendamment des entêtes de SPIP décrites ci-dessus), et invalide la page concernée (et celle-ci seulement). - l’URL
…?var_mode=(recalcul|images)
est détectée par Varnish et invalide tout le cache de Varnish (notamment, parce qu’un recalcul d’une page peut provoquer la modification d’un fichier de CSS ou javascript associé). - l’URL de suppression du cache SPIP depuis l’espace privé (un clic sur le bouton dans
?exec=vider_cache
) invalide aussi tout le cache Varnish.
Implémentation
Cette approche me semble au final plus simple que celle donnée par la doc de Varnish, qui passe par la définition d’une méthode HTTP non standard PURGE
. Pour l’implémenter, j’ai construit un fichier de configuration pour Varnish, ainsi qu’un plugin pour SPIP.
Remarque : les deux éléments (configuration et plugin) sont conçus pour fonctionner de concert, mais il est tout à fait possible d’utiliser la configuration pour Varnish sans installer le plugin SPIP. Les pages « dynamiques » produites par SPIP ne seront alors pas enregistrées dans le cache de Varnish, qui y stockera néanmoins tous les fichiers statiques (images, javascript, CSS etc.) selon des règles « assez bonnes ».
Autrement dit, sur un serveur hébergeant plusieurs sites, on peut installer Varnish sans installer le plugin sur tous les sites : seuls les sites SPIP ayant installé le plugin en tireront le maximum, mais les autres ne seront pas pénalisés.
Télécharger le plugin
La configuration de Varnish et le plugin SPIP sont téléchargeables depuis SPIP-Zone : http://zone.spip.org/trac/spip-zone/browser/_plugins_/varnish
Le plugin nécessite l’usage du plugin StatsJS, car, dès lors qu’on demande à Varnish de servir directement les pages SPIP, celui-ci ne peut plus comptabiliser les visites des pages de la façon habituelle.
Configuration de Varnish
Voici le fichier de configuration, commentaires inclus :
Comme on le voit c’est un gros fichier… on pourra en suivre le développement dans le répertoire du plugin.
Dans le prochain article j’indiquerai comment procéder pour terminer l’installation.
14 Messages de forum