Vous êtes prêts à vous lancer !
Votre site est installé sur une distribution Debian Buster avec Nginx/Apache/PHP/MySQL.
Votre site utilise Nginx pour la terminaison SSL, l’objectif consiste à intercaler Varnish entre Apache et Nginx !
L’opération d’installation de Varnish est assez simple. Il faut néanmoins maîtriser la ligne de commande sous Linux et prendre soin de vérifier le bon fonctionnement du cache après installation.
L’objectif, si Nginx redirige les requêtes des ports 80 et 443 vers le port d’écoute Apache (8080 souvent dans ce cas), sera de rediriger les ports 80 et 443 vers le port d’écoute de Varnish, qui par défaut est le 6081. Varnish redirigera à son tour les requêtes sur le port 8080 d’Apache. Le «backend» de Varnish sera le serveur Apache, en localhost sur le port 8080.
Pour installer Varnish sur Debian, il suffit de lancer la commande :
Jusque là, comme Varnish s’installe par défaut sur le port 6081, il n’y a aucun impact sur le Magento !
On prépare la configuration de Varnish qui se trouve dans /etc/varnish/default.vcl.
A noter que cette configuration est fournie par Magento 2 lui même.
Sauvegardez la version d’origine avant de la modifier avec la version à télécharger ici !
Dans ce fichier, il faut vérifier le paragraphe qui définit l’endroit où seront redirigées les requêtes qui arrivent depuis Varnish.
Etape 1 : Modifier la redirection de Nginx
Afin que Nginx redirige les requêtes sur Varnish, il suffit de les envoyer sur le port 6081 au lieu du port 8080.
Dans le fichier de configuration de Nginx, par exemple : /etc/nginx/sites-enabled/reverse-proxy.conf on passe proxy-pass http://localhost:8080 à proxy-pass http://localhost:6081
Le redémarrage de Nginx permet la prise en compte du changement de port :
Etape 2 : purger le cache Varnish
Une fois Varnish installé, on peut vérifier l‘amélioration des performances.
La première étape consiste à purger le cache de Varnish. Sur le serveur Varnish, il suffit de lancer la commande suivante pour vider toutes les URLs mises en cache :
Le «.» indique 0 et 1 caractère n’importe lequel. Donc toutes les URLs vont matcher cette expression régulière. Toutes les URLs seront donc bannies.
Etape 3 : mesurer les temps de réponse
On peut vérifier les temps de réponse avec cUrl. On prépare un fichier pour le formatage des temps de réponse comme suit :
On met Magento en mode debug pour voir les entêtes Varnish. On lance une première requête après le vidage du cache :
On remarque que l’en-tête X-Magento-Cache-Debug vaut MISS.
La page est servie depuis Apache car elle n’était pas disponible au niveau de Varnish. Mais comme cette page a un Max Age d’une journée, elle a vocation a être cachée. Une deuxième requête identique doit montrer que la page est servie du cache de Varnish.
On remarque que l’en-tête X-Magento-Cache-Debug vaut HIT et Varnish a mis la page en cache depuis 70 secondes (entête Age). Ce qui correspond bien à notre première requête !
On vient de diviser le temps de réponse par un facteur 10 !
Si on demande la même page directement depuis Apache, on obtiendrait :
Soit un temps de réponse voisin de celui de Varnish quand la page n’est pas cachée. Ce facteur 10 prouve l’intérêt de Varnish, qui va pouvoir servir tous les contenus statiques, images, JS et CSS et pages également, lorsqu’elles n’ont pas de cookies de session, c’est à dire qu’elle ne dépendent pas de l’utilisateur.
C’est donc un gain pour l’expérience utilisateur autant que pour supporter la charge lors des fortes audiences comme les soldes !
Alain Arditi
Collaborateur toHero