XtremCache - Cache 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 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'é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.
Habituellement cet outil n'est pas proposé sur des offres de type mutualisé car la configuration de l'outil dépend fortement du site internet hébergé et du CMS utilisé. Dans une offre mutualisée, les sites hébergés sont très différents et utilisent des technologies hétérogènes. C'est à cela que sert cet outil : il permet d'activer un cache Varnish, avec une configuration optimisée pour le site internet que vous avez. Les hébergements web varnish sont donc plutôt rares.
Icône | Nom | Catégorie | Description |
---|---|---|---|
XtremCache | Performance | Améliore la vitesse de chargement des sites internet grâce au mécanisme de cache avancé 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
Traitement d'une requête sans cache serveur
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).
Traitement d'une requête lorsque le cache Varnish est activé
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 l'outil
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
Lorsqu'on se rend sur l'outil, 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.
Page d’accueil de l'outil XtremCache permettant d'ajouter un cache Varnish
Différentes actions sont possibles pour chaque nom de domaine listé :
- Le cache n'est pas actif sur le domaine
- Le bouton
Activer le cache
lance l'outil permettant de configurer un cache sur le nom de domaine concerné
- 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 temporairement
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
Désactiver totalement
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 cache est désactivé temporairement sur le domaine
- Les boutons,
Vérifier
etDésactiver totalement
font la même chose que lorsque le cache est actif (cf. ci-dessus) - Le bouton
Réactiver le cache
permet de réactiver le cache pour le domaine concerné. La réactivation est assez rapide.
L'outil xtremCache
est compatible avec l'outil ipXtender
(cf. documentation de l'outil ipXtender).
La colonne Informations
permet de voir cela, cette colonne affiche les personnalisations effectuées sur le nom de domaine, il y a plusieurs cas possibles :
- Cache (actif) : indique que le cache
xtremCache
est actif pour le domaine mais pasipXtender
- Cache (inactif) : le cache
xtremCache
a été désactivé temporairement pour le nom de domaine. L'outilipXtender
n'est pas actif pour le domaine - Cache (actif) + ipXtender : le domaine pointe sur l'adresse IP sélectionnée dans
ipXtender
et le cachextremCache
est actif - Cache (inactif) + ipXtender : le domaine pointe vers l'adresse IP sélectionnée dans
ipXtender
mais le cachextremCache
est désactivé (temporairement) - ipXtender : ipXtender est actif donc le domaine pointe vers une adresse ip personnalisée, il n'y a pas de cache
xtremCache
actif - non personnalisé : c'est la configuration par défaut d'un domaine configuré sur l'hébergement, il n'y a pas de personnalisation
ipXtender
ouxtremCache
Activer un 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.
Page d'activation du cache Varnish o2switch
Dans la page d'activation du cache Varnish, à cet instant, il est possible de configurer deux éléments :
- Le Template : 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é.
- Nom du cookie : sert à définir une liste de cookie à ignorer, pour améliorer la mise en cache et le ratio HIT/MISS comme vu dans la partie cachable ou pas ?
Changement d'adresse IP
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 de propagation DNS, durant cette période, le site risque d'être inaccessible (erreur 502). Nous vous conseillons de réaliser cette action dans une période creuse ou dés le début, lors de la création/configuration du domaine
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
: l'adresse IP associée au domaine sera109.234.164.18
- Le domaine est sur
ipXtender
: l'adresse IP sélectionnée dansipXtender
est conservée
Lorsque la configuration est terminée, un résumé des opérations effectuées s'affiche. Il est conseillé de le vérifier pour contrôler l'absence d'erreurs. La configuration modifiant l'adresse IP associée au domaine, nous vous recommandons de tester le bon fonctionnement de vos comptes emails également (l'outil effectuera une vérification, mais c'est toujours mieux de le vérifier vous-même également).
Un exemple de résumé des actions effectuées pour l'activation du cache Varnish
Détection du SSL
Soyez vigilant sur la détection du SSL sur le nom de domaine. Lisez bien le rapport des actions effectuées, s'il est indiqué que le SSL n'est pas détecté alors que que votre site utilise un certificat SSL et est accessible en HTTPS, suivez les étapes de la partie SSL non détecté puis relancez l'activation.Vérifier
L'outil Vérifier
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
HEAD
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.
Outil de vérification du cache sur le site internet
L'outil va afficher un rapport similaire au rapport suivant :
Rapport généré par l'outil de vérification du cache
Le rapport contient plusieurs éléments :
- La première phrase du rapport indique si la page a été servie depuis le cache ou non
- La deuxième phrase du rapport indique si la page a défini des cookies, si c'est le cas, ces derniers sont affichés (nom : valeur)
- Ensuite, s'affichent les entêtes (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
Vider le cache
Cet outil permet de vider le cache associé au domaine. Cette option vide l'intégralité du cache associé au domaine.
Un message s'affiche lorsque le cache est vidé :
Message indiquant que le cache a été vidé correctement
Désactiver temporairement
Cet outil 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 désactivation totale, 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.
Un rapport s'affiche lorsque le cache est désactivé temporairement sur le site internet :
Rapport qui s'affiche suite à la désactivation temporaire du cache
Désactivation temporaire du cache
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 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.Désactiver totalement
La désactivation totale remet à zéro 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.
Désactivation totale
La désactivation totale 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.La désactivation totale est similaire à une remise à zéro (reset) de la configuration du domaine.
Un message s'affiche suite à la désactivation totale :
Rapport de la remise à zéro de la configuration du domaine
Réactiver le cache
Cette option permet de réactiver un cache, qui a été précédemment désactivé temporairement. La réactivation du cache est assez rapide à être prise en compte. Il n'y a pas de perturbation à prévoir, l'adresse IP liée au domaine n'est pas changée.
Un message s'affiche suite à la réactivation du cache :
Message informant de la réactivation du cache sur le nom de domaine
Templates
Les Templates correspondent aux configurations de cache disponibles, ces configurations là sont gérées au niveau du serveur et sont maintenues par o2switch.
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 pages suivants donnent plus d'indications sur ce que font ces templates :
A venir dans un futur proche : Magento, WordPress + WooCommerce, Joomla + Hikashop
Votre application n'est pas proposée ?
Si votre application n'est pas proposée dans la liste des templates supportés ou si vous avez des suggestions d'amélioration, rapport de bug, vous pouvez nous contacter sur support@o2switch.fr. Nous regarderons s'il est possible de proposer un template spécifique à l'application/Framework/CMS que vous utilisez.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
- (à venir) depuis une extension WordPress
Dans cette partie, nous allons voir toutes les méthodes de purge de cache proposées à l'exception de l'outil proposé dans cPanel qui est expliqué dans la partie ci-dessus.
Purge manuelle ou via un script
Pour vider le cache, il faut envoyer une requête de type PURGE
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' 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' 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:.*' 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/.*' mon-dev.xyz
Pour ne vider que les images se terminant par .jpg:
curl -X 'PURGE' -H 'X-Purge-Regex:.*\.jpg$' mon-dev.xyz
Retours
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
Erreur 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 :
Vérification de la configuration DNS sur l'outil DIG en ligne de 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 / 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 :
RewriteEngine On RewriteCond %{SERVER_PORT} ^80$ RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
Exemple de règles de redirections permettant de forcer le HTTPS qui ne fonctionnerait pas correctement
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, c'est souvent vrai mais il y a certains cas où ce n'est pas le cas.
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 :
RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteCond %{HTTPS} !on RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Exemple de redirection qui fonctionne pour forcer le HTTPS
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.
Cela s'affiche dans le rapport des actions effectuées pour faire la configuration, il y a une ligne indiquant qu'aucun SSL n'est détecté. Si vous savez que c'est une erreur et qu'un certificat SSL est bien actif, 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.
Changelog
26/08/2021
- Mise à jour interne de l'outil
- Quelques changements dans l'affichage + mise en place de d'ajax
- Simplification de l'outil : clé de purge enlevée, compatibilité avec des plugins de caches courant à venir
- Compatibilité avec les règles de sécurités personnalisées de TigerProtect
07/05/2020
- Mise à jour pour rendre l'activation du cache beaucoup plus rapide depuis cPanel
- Changement interne à la gestion du cache
08/03/2019
- Mise à jour de l'outil pour l'intégrer avec lscache (lscache & xtremcache étant incompatibles l'un avec l'autre)
- Correction d'un bug sur le vérification du cache sur la version sans les “www” du domaine
- Amélioration de la détection du SSL lors de l'activation et le renouvellement des certificats
- Amélioration de l'ajax de l'outil
13/11/2018
- Grosse mise à jour de l'outil qui corrige plusieurs bug et apporte des nouvelles fonctionnalités
- Amélioration de la détection du SSL lors de l'activation de l'outil
- Ajout d'une option pour choisir les www ou non dans l'outil de test de cache
- Simplification de l'ensemble des messages renvoyés par l'outil
- L'outil permettant de vider le cache vide le cache pour les 4 versions du domaine, c'est-à-dire : http, http + www, https, https + www
- Rectification d'un bug concernant l'exclusion des cookies, c'est bien pris en compte également. Les cookies avec un _ sont autorisés à présent.
- Un bug affichait les sous-domaines comme configurables avec l'outil de cache alors que cela n'est pas encore possible à cause d'une limitation de cPanel
- Ajout d'une option permettant d'ignorer certains headers renvoyés (à tort) par des sites internet, comme cache-control:max-age=0. Permet de forcer le cache.
- Modification de l'infrastructure pour éviter le problème des redirections infinies et des règles de redirections dans les .htaccess invalides.
- Code permettant de gérer les hooks cPanel pour la mise à jour de certificat SSL plus robuste
- Changement de méthode de gestion au niveau de Varnish : permet une prise en compte beaucoup plus rapide. Le temps de chargement est fortement diminué, pour passer de plusieurs minutes à 20-30 secondes à présent. L'activation / désactivation / réactivation est beaucoup plus rapide et flexible à présent.
- Mise à jour de l'UX (breadcrumb)
- Correction de bug en rapport avec ipxtender dans des cas très spécifiques de désactivation/réactivation du cache
05/09/2018
- Mise à jour qui corrige quelques bugs en rapport avec les erreurs E010, E012
- Amélioration de l'ux du loader de chargement
- Mise à jour des templates de cache
- Correction d'un bug concernant l'adresse IP du visiteur qui est remontée dans les logs de connexion
06/06/2018
- Mise en place de la version 1 de l'outil de cache