xtremCache, le cache HTTP Varnish
L'outil XtremCache est un outil qui permet d'améliorer la vitesse de chargement de votre site internet grâce à l'activation d'un mécanisme de cache HTTP avancé, configuré directement au niveau du serveur web : Varnish.
Varnish est un mécanisme de cache, qui se gère au niveau serveur et qui permet d'améliorer les performances de votre site internet en gardant les pages et ressources générées en mémoire. Cela permet d'améliorer la vitesse de chargement d'un site hébergé sur l'hébergement web o2swich.
Cela permet d'éviter toute la partie de traitement dynamique (PHP par exemple) qui sert à générer la page et qui est consommateur en ressources. Les pages sont générées une première fois puis sont gardées en mémoire pour les futures visites.
Varnish est très utilisé sur les sites ayant un trafic important, comme les sites de presse par exemple.

Outils xtremCache
Améliore la vitesse de chargement des sites en permettant l'activation d'un puissant cache serveur Varnish
Principe de fonctionnement
Pour comprendre le fonctionnement du système de cache Varnish, il faut d'abord voir comment cela fonctionne sans cache.
Fonctionnement sans cache HTTP

Lorsqu'il n'y a pas de cache serveur, voici les différentes étapes qui sont suivies pour l'affichage d'une page
- Le navigateur web du visiteur demande au serveur une page particulière, dans cet exemple, index.php
- Le serveur, voyant qu'il s'agit d'une page PHP, va lancer l'exécution de la page PHP pour obtenir une réponse (par exemple, une page HTML)
- Le moteur PHP va renvoyer la réponse au serveur
- Le serveur va renvoyer la réponse, la page générée, au visiteur
Fonctionnement avec cache
Lorsque le cache Varnish est activé, Varnish se place devant le serveur web pour intercepter les appels des navigateurs web ainsi que les réponses du serveur web. Pour chaque appel, il va regarder si la ressource demandée est en cache ou s'il faut transmettre la demande au serveur web. Pour chaque réponse du serveur web, il va regarder s'il est possible de la placer en cache.
Avec Varnish, l'idée est d'éviter toute la partie de génération de la page au niveau du serveur, par exemple, dans le cas d'un site conçu en PHP, on cherche à éviter tous les traitements PHP car c'est ce qui consomme des ressources et c'est également ce qui est le plus lent (comparativement aux autres traitements effectués).

Lorsque le cache Varnish est activé, voici ce qu'il se passe (de manière simplifiée) :
- Le navigateur web du visiteur demande une page particulière. Cette demande arrive sur le cache Varnish dans un premier temps, plutôt que d'arriver sur le serveur web.
- Varnish regarde si la ressource est en cache
- Si oui, alors Varnish renvoie la réponse qu'il a en cache au navigateur web (sur l'image étape 3 en vert et 4)
- Si non, alors Varnish transmet la demande au serveur web pour avoir la page à renvoyer (sur l'image, étape 3 en
rouge)
- Le serveur web constate qu'il s'agit d'une page PHP donc lance le traitement PHP (étape 4)
- Le moteur PHP retourne la page générée au serveur web (étape 5)
- Le serveur web retourne la page générée à Varnish, Varnish regarde si cette page peut être mise en cache ou non
(étape 6)
- Si oui, Varnish place la page en cache puis retourne la réponse au visiteur (étape 7)
- Si non, Varnish retourne la réponse sans la mettre en cache (étape 7)
On constate donc que lorsqu'une page est en cache, plusieurs étapes sont évitées :
- L'appel vers le serveur web
- Toute la partie de traitement PHP utilisée pour générer la page. Dans cet exemple, le langage de programmation pour la création du site est PHP mais le principe est identique pour d'autres langages (Python, Ruby, etc...)
Le cache Varnish étant directement en mémoire RAM, ce qu'il y a de plus rapide, la page est servie très rapidement.
Cachable ou pas ?
Afin d'avoir un bon ratio de HIT/MISS, c'est-à-dire le ratio des pages servies depuis le cache (HIT) par rapport aux pages qui ne sont pas servies depuis le cache (MISS), il est important de comprendre comment Varnish s'y prend pour déterminer si une page peut être gardée en mémoire (cache) ou non.
Toutes les pages ne peuvent pas être conservées en mémoire cache. Certaines pages sont générées de manière totalement dynamique et il n'est pas pertinent de garder cela en cache. Par exemple, des pages qui sont générées en fonction d'un utilisateur connecté sur le site internet. Le contenu dépendant de l'utilisateur connecté, il n'est pas possible de garder cette page en mémoire pour la transmettre à d'autres visiteurs.
Voici les cas où Varnish ne peut pas garder en mémoire une page donnée :
- Toutes les requêtes différentes des requêtes HEAD/GET ne sont pas mises en cache. Dans le cas d'une requête POST, la page générée peut très probablement varier en fonction du contenu du POST.
- Si un cookie, qui n'est pas dans la liste des cookies à exclure, est présent. La page générée peut varier en fonction de la valeur de certains cookies, un cookie peut contenir la langue de préférence du site par exemple.
- Certaines parties ou fichiers des sites spécifiques, par exemple, dans le cas de WordPress, le dossier wp-admin va être exclu du cache
- Toutes les requêtes AJAX, que cela soit GET ou POST
- Les pages ayant des headers "Authorization" ou "Authenticate", ce sont des pages privées et protégées par des authentifications (authentification basique avec .htacess par exemple)
- Le serveur va également respecter la politique de cache renvoyée par le site internet, notamment via les header cache-control par exemple
C'est en partie dû à l'algorithme qui sert à déterminer si une page peut être en cache ou non, que la configuration de Varnish dépend fortement du type de CMS utilisé. C'est pour cette raison qu'il y a différents templates de cache proposés, ce sont des configurations adaptées au CMS utilisé par votre site internet.
Par exemple, dans le cas de WordPress, il y aura des règles pour exclure le dossier wp-admin, dans le cas de Joomla, ça sera administrator, etc.
Présentation de XtremCache
L'outil XtremCache est découpé en plusieurs parties / sous outils. Il y a également un vocabulaire, spécifique à l'outil et au mécanisme de cache Varnish qu'il faut connaître pour comprendre l'outil.
Page d'accueil
La page d'accueil va lister tous les domaines configurés sur l'hébergement. Pour le moment, seul les domaines supplémentaires
et le domaine principal
sont listés. Les sous-domaines ne sont pas supportés.

Différentes actions sont possibles pour chaque nom de domaine listé :
- Le cache n'est pas actif sur le domaine
- Le bouton
Activer XtremCache - Varnish
lance l'outil permettant de configurer un cache sur le nom de domaine concerné
- Le bouton
- Le cache est actif sur le domaine
- Le bouton
Vérifier
affiche un outil qui permet de vérifier si le cache est bien actif sur le site ou une page en particulier. C'est un outil de debug - Le bouton
Vider le cache
permet de vider l'intégralité du cache associé au domaine - Le bouton
Désactiver
permet de désactiver temporairement le cache, le temps de faire un test par exemple. Le cache peut être réactivé très rapidement, sans coupure. - Le bouton
Remettre à zéro
enlève toutes les personnalisations effectuées sur le domaine, comme le cache mais également ipxtender (les deux outils étant compatibles l'un avec l'autre)
- Le bouton
L'outil xtremCache
est compatible avec l'outil ipXtender.
Activer le cache
La page d'activation de cache permet d'activer un cache sur un nom de domaine particulier et de choisir puis personnaliser la configuration en fonction du site internet.

Dans la page d'activation du cache Varnish, à cet instant, il est possible de configurer trois éléments :
- Template de cache 2 : sert à définir quelle est la configuration Varnish à activer pour le nom de domaine. Plusieurs templates sont proposés, la plupart correspondent à un CMS ou Framwork particulier. Le bouton de détection automatique permet de choisir le template automatiquement, l'outil va essayer de détecter le CMS utilisé puis remplir le champs en fonction du résultat trouvé.
- Forcer le cache 3 : permet de forcer le cache en ignorant les entêtes de cache
comme
Cache-control: max-age=0
. Ceci n'est pas recommandé - Ignorer les cookies 4 : (déprécié) sert à définir une liste de cookie à ignorer, pour améliorer la mise en cache et le ratio HIT/MISS
L'activation du cache sur le domaine implique un changement d'adresse IP pour ce domaine. Cela implique plusieurs choses :
- Le domaine doit utiliser nos serveurs DNS. Si ce n'est pas le cas, pensez à changer l'adresse IP du site manuellement dans vos DNS sinon cela générera une erreur 502
- Il y aura un délai avant que le changement d'IP soit pris en compte, cela peut prendre quelques heures. Pendant ce temps, le site devrait continuer de fonctionner normalement.
- Nous vous conseillons de réaliser cette action dans une période creuse
L'outil est compatible avec ipXtender, en fonction de la configuration détectée, l'adresse IP d'ipXtender est conservée :
- Le domaine n'est pas sur ipXtender : une adresse IP interne sera sélectionnée aléatoirement
- Le domaine est sur ipXtender : l'adresse IP sélectionnée dans ipXtender est conservée
Outil de vérification
L'outil Vérification permet de faire des requêtes sur la page d'accueil du site internet ou une page spécifique afin de vérifier si la page en question est dans le cache.
Pour cela, l'outil va faire deux requêtes :
- une première requête
GET
pour s'assurer que la page a été visitée au moins une fois (afin de lui laisser une chance d'être dans le cache) - une deuxième requête, de type
GET
pour vérifier si la page servie vient du cache ou non
L'outil liste aussi les cookies détectés, cela peut être utile pour ajuster les règles de cache.
Le premier formulaire de l'outil vous permet de sélectionner ce que vous souhaitez tester. Il faut choisir :
- 1 Le protocole : HTTP ou HTTPS
- 2 Le sous-domaine : avec ou sans les WWW
- 3 L'URL de la page à tester : laissez vide pour tester la page d'accueil

L'outil va afficher un rapport similaire au rapport suivant :

Le rapport contient plusieurs éléments :
- Le rapport indique si la page a été servie depuis le cache ou non
- Ensuite, s'affichent les entêtes HTTP (headers) renvoyés par la réponse du serveur, certains headers sont plus
intéressants que d'autres
- X-Storage : affiche la stratégie de cache utilisée pour la ressource. Les pages et certains fichiers statiques sont stockés en mémoire RAM (memory), d'autres types de ressources peuvent être stockés sur un cache SSD NVMe local (les images)
- X-Cache : peut contenir les valeurs
HIT
, qui signifie que la page a été servie depuis le cache, ouMISS
qui signifie que la page n'a pas été servie depuis le cache - X-Cache-Hits : affiche le nombre de fois que la ressource a été chargée depuis le cache
Si le rapport affiche une redirection 301 alors cela signifie que vous n'avez pas correctement remplis le premier formulaire.
Par exemple, si vous forcez les WWW et/ou le HTTPS sur votre site internet, et que vous testez la version HTTP sans WWW, le site retournera une redirection 301. Dans ce cas, il suffit de refaire le test en ajustant le premier formulaire.
Vider le cache
Cet outil permet de vider le cache associé au domaine. Cette option vide l'intégralité du cache associé au domaine.
Désactiver le cache
Le bouton Désactiver permet de désactiver temporairement le cache associé au site internet. La désactivation temporaire du cache est assez rapide à être prise en compte et n'engendre pas de coupure du site internet.
Contrairement à la remize à zéro, la désactivation temporaire ne change pas l'adresse IP liée au domaine donc il n'y a pas de coupure/délai de propagation DNS à prévoir.
Cette option est adaptée pour faire des tests, par exemple, si vous soupçonnez que le cache peut être à l'origine d'un comportement anormal sur votre site.
La désactivation temporaire du cache est la méthode de désactivation recommandée car elle est rapidement prise en compte et n'engendre pas de coupure.
La désactivation totale (remise à zéro) du cache peut engendrer une coupure des services car l'adresse IP associée au site est changée pour remettre l'adresse IP d'origine.
Remize à zéro
La remize à zéro efface l'ensemble des configurations effectuées sur le nom de domaine, c'est-à-dire les configurations de cache mais également les configurations ipXtender.
En résumé, cela permet de remettre le domaine à son état d'origine.
La remize à zéro change l'adresse IP du domaine pour remettre l'adresse IP d'origine. Cela peut causer des perturbations sur le site internet (erreur 502) le temps que la modification DNS soit prise en compte (délai de propagation DNS).
Cet outil est à utiliser en dernier recours, si vous souhaitez juste désactiver le cache, utilisez l'outil de désactivation temporaire.
Templates de cache
Les Templates correspondent aux configurations de cache disponibles, ces configurations là sont gérées au niveau du serveur.
Les Templates définissent les règles de caches. Le rôle d'un template est d'optimiser le ratio HIT/MISS (autrement dit, avoir le plus d'éléments possible en cache) pour une technologie de création de site donnée, tout en évitant les erreurs.
Par exemple, un template va :
- définir des listes d'URL exclues comme les pages d'administrations, pour éviter les erreurs
- définir une liste de cookies à ignorer, pour améliorer la mise en cache
- faire des exceptions sur des extensions et thèmes qui peuvent être utilisés et à l'origine de problèmes
Plusieurs templates sont proposés, Vous en trouverez certains adaptés aux CMS les plus utilisés et d'autres plus génériques qui peuvent être utilisés pour des sites "fait main".
Les templates suivants sont proposés :
- WordPress
- Fichiers statiques uniquement : pour ne mettre en cache que les images, css etc...
- Joomla
- PrestaShop
- Symfony
Purge du cache
Il existe différentes manières de purger le cache :
- depuis l'outil pour vider le cache dans cPanel
- manuellement ou avec un script PHP en effectuant des requêtes de purges
Purger le cache depuis cPanel
Pour purger le cache depuis cPanel, il suffit de cliquer sur le bouton Vider le cache dans visible dans la page d'accueil de l'outil.

Purger manuellement ou depuis un script
Pour vider le cache, il faut envoyer une requête de typePURGE
sur la page à purger (c'est-à-dire la page pour
laquelle nous souhaitons vider le cache).
Donc par exemple, en utilisant curl
cela donne la requête suivante :
curl -X 'PURGE' http://mon-dev.xyz
La requête ci-dessus ne purge que la page d'accueil du site internet, c'est la forme la plus simple de purge proposée. Il est également possible de purger une page spécifique, par exemple :
curl -X 'PURGE' http://mon-dev.xyz/ma-page
Si le domaine se trouve derrière une solution comme Cloudflare (il n'est pas recommandé de mixer les deux) ou si le
domaine ne pointe pas directement vers l'adresse IP du cache (pour une raison ou pour une autre) alors il faut générer
l'entête host
manuellement et indiquer l'adresse IP du serveur de cache. Ce cas est très rare et c'est un usage
avancé, par exemple :
# pour connaitre l'adresse IP du serveur de cache
dig +short @ns1.o2switch.net mon-dev.xyz
# requête de purge en précisant l'host manuellement
curl -X 'PURGE' -H 'Host:mon-dev.xyz' http://109.234.164.18/ma-page
Le mécanisme de cache supporte un autre type de purge, les purges en utilisant une regex
. Cette méthode de purge est
très pratique car elle permet de vider le cache de manière rapide et précise :
- il est possible de vider tout le cache lié au domaine en une seule requête
- ou de vider le cache de certains types de fichiers spécifiques ou d'adresses, par exemple, tous les fichiers png
Pour utiliser cette méthode, il faut faire une requête de purge comme vu dans les exemples précédents puis ajouter une
entête X-Purge-Regex
qui contient l'expression régulière (regex) à utiliser pour vider le cache.
Par exemple, pour vider tout le cache associé au domaine :
curl -X 'PURGE' -H 'X-Purge-Regex:.*' http://mon-dev.xyz
Pour ne vider que le cache du répertoire wp-content/uploads (donc les images pour WordPress) :
curl -X 'PURGE' -H 'X-Purge-Regex:wp-content/uploads/.*' http://mon-dev.xyz
Pour ne vider que les images se terminant par .jpg:
curl -X 'PURGE' -H 'X-Purge-Regex:.*\.jpg$' http://mon-dev.xyz
L'outil retourne un code HTTP 200
si la purge s'est bien passée.
L'outil affiche également un retour HTML simple, le message varie légèrement si la méthode par regex
est utilisée :
<!-- Retour lorsque c'est une purge simple -->
<!DOCTYPE html>
<html>
<head>
<title>200 Purged.</title>
</head>
<body>
<h1>Error 200 Purged.</h1>
<p>Purged.</p>
<h3>Guru Meditation:</h3>
<p>XID: 62717987</p>
<hr>
<p>Varnish cache server</p>
</body>
</html>
<!-- Retour lorsque la méthode REGEX est utilisée -->
<!DOCTYPE html>
<html>
<head>
<title>200 Purged using the Purge Regex Method</title>
</head>
<body>
<h1>Error 200 Purged using the Purge Regex Method</h1>
<p>Purged using the Purge Regex Method</p>
<h3>Guru Meditation:</h3>
<p>XID: 62849276</p>
<hr>
<p>Varnish cache server</p>
</body>
</html>
Erreurs courantes
Ci-dessous la liste des erreurs courantes et solutions en rapport avec l'outil xtremCache.
Erreurs 502
L'erreur 502 peut venir de plusieurs raisons mais si l'erreur s'affiche suite à l'activation du cache, la désactivation totale du cache ou l'activation d'ipXtender, cela signifie l'une des trois choses suivantes :
- L'erreur est liée au délai de propagation DNS. Toutes les opérations listées ci-dessus change l'adresse IP associée
au domaine. Ce changement d'IP peut prendre du temps, tant que la bonne adresse IP n'est pas prise en compte,
vous risquez d'avoir une erreur de type
HTTP 502
, cela est normal (temporairement du moins) - Le nom de domaine ne pointe pas vers la bonne adresse IP. Cela peut arriver si vous utilisez des serveurs DNS tiers, la mise à jour de l'IP associée au domaine n'est pas automatique. Dans ce cas, il faut configurer la bonne adresse IP (listée dans la page d'accueil de l'outil) dans votre zone DNS
- Peu probable, même erreur que précédemment, l'adresse IP ne pointe pas au bon endroit mais la cause est différente. Cela peut être lié à votre environnement local, par exemple, si vous avez fait des tests en modifiant votre ficher hosts
Pour le délai de propagation DNS, vous ne pouvez pas faire grand chose, sauf vider votre cache DNS local. Cela peut vous faire gagner quelques heures mais ce n'est pas forcément suffisant !
Pour vider votre cache DNS local, vous pouvez suivre la procédure expliquée sur la page de l'outil ipXtender.
Pour vérifier si le domaine pointe vers la bonne adresse IP, si vous disposez de la ligne de commande et de la commande dig
, vous pouvez lancer les deux commandes suivantes :
# l'ip côté o2switch, celle du cache donc
dig +short @ns1.o2switch.net mon-domaine.fr
# l'ip depuis un DNS tiers, celui de Google dans ce cas
dig +short @8.8.8.8 mon-domaine.fr
# les deux IPs doivent être identiques, si elles sont différentes, il y a un problème
Ou vous pouvez utiliser un outil en ligne comme Dig sur Kloth.net :

Sur l'outil en ligne de Kloth.net, il faut faire deux requêtes :
- la première avec locahost ou 8.8.8.8 comme adresse de serveur, pour trouver l'adresse IP associée au domaine
- la deuxième avec ns1.o2switch.net comme adresse de serveur DNS pour comparer cela avec l'adresse IP que devrait avoir le site internet
Les deux IPs devraient être identiques, sinon cela signifie qu'il y a probablement un problème.
HTTPS, boucle de redirections
Certaines configurations de .htaccess
peuvent générer des boucles de redirections à l'infini et empêcher le chargement
du site internet.
Généralement, cela arrive lorsque les règles du .htaccess
vérifient si la requête est en HTTPS ou non en se basant sur
le port d'écoute du serveur web. Voici un exemple de règle :
# Exemple de règles de redirections permettant de forcer le HTTPS qui ne fonctionnerait pas correctement
RewriteEngine On
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
Le code ci-dessus ne fonctionne pas à tous les coups car cela suppose que le serveur web utilise le port 80 pour le traitement d'une requête HTTP.
Cette méthode de détection du https ne fonctionnera pas car le port 80 n'est jamais utilisé par le serveur web apache de nos hébergements, ceci est lié à la manière dont sont configurés les serveurs.
Ce code peut être remplacé par l'équivalent suivant qui fonctionne correctement :
# Exemple de redirection qui fonctionne pour forcer le HTTPS
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
SSL non détecté
Dans certains cas, l'outil xtremCache
ou même ipXtender
ne détecte pas correctement le certificat SSL lié au nom
de domaine à personnaliser.
Cela arrive lorsque le certificat SSL n'est pas installé correctement sur l'hébergement.
Vous pouvez corriger cela en forçant la réinstallation du certificat SSL puis en relançant l'outil d'activation du cache ou de changement d'ip.
Cela peut être fait de deux manières différentes :
- Depuis l'outil Let's Encrypt qui se trouve dans la catégorie
sécurité
de cPanel : il suffit de cliquer surréinstaller
- Depuis l'outil SSL/TLS de cPanel, toujours dans la catégorie
sécurité
: il faut cliquer surGérer les sites SSL
puis sélectionner le domaine, cliquer surremplir automatiquement
puis valider.
CloudFlare ou autres CDN
N'activez pas Cloudflare en complément d'xtremCache, cela est inutile et contre productif. En faisant cela, vous cumulez plusieurs niveaux de caches et cela va bloquer le mécanisme interne de purge d'xtremcache.
Au niveau d'xtremCache il n'y a pas de réglage de compatibilité avec CloudFlare. Il faut activer l'une ou l'autre de ces technologies mais pas les deux à la fois. Testez les deux, choisissez ce qui vous convient le mieux.
Sous-domaines
XtremCache n'est pas compatible avec les sous-domaines, vous ne pourrez pas l'activer dessus.