Votre Magento est déjà optimisé, vous utilisez le Full Page Cache, mais avec Varnish, vous allez passer à la vitesse supérieure et aussi alléger votre Magento !

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 : 

$ sudo apt install varnish
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libjemalloc2 libvarnishapi2 Suggested packages:
varnish-doc
The following NEW packages will be installed:
libjemalloc2 libvarnishapi2 varnish
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,207 kB of archives.
After this operation, 3,397 kB of additional disk space will be used. Do you want to continue? [Y/n] y
....
$

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 

backend default {
    .host = "localhost";  # Magento sur trouve sur le même serveur que Varnish
    .port = "8080";
    .....

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 

$ less /etc/nginx/sites-enabled/reverse-proxy.conf
....
        location / {
                    proxy_pass http://localhost:6081;
                    proxy_set_header Host $http_host;
                    proxy_set_header X-Real-IP $remote_addr;
                    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

....

Le redémarrage de Nginx permet la prise en compte du changement de port :

$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ sudo systemctl restart nginx && sleep 2 && systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 10:01:27 CET; 2s ago
     Docs: man:nginx(8)
  Process: 2078 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
  Process: 2080 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
 Main PID: 2081 (nginx)
    Tasks: 3 (limit: 4696)
   Memory: 4.7M
   CGroup: /system.slice/nginx.service
           ├─2081 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
           ├─2082 nginx: worker process
           └─2083 nginx: worker process

Jan 25 10:01:27 aa2 systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 25 10:01:27 aa2 systemd[1]: Started A high performance web server and a reverse proxy server.
$ 

 

Etape 2 : purger le cache Varnish

Une fois Varnish installé, on peut vérifier l'amélioration des performances.

La première étape consiste à purge le cache de Varnish. Sur le serveur Varnish, il suffit de lancer la commande suivante pour vider toutes les URLs mises en cache :

$ sudo varnishadm "ban req.url ~ ."
$

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 :

$ cat curl-format.txt
    time_namelookup:  %{time_namelookup}\n
       time_connect:  %{time_connect}\n
    time_appconnect:  %{time_appconnect}\n
   time_pretransfer:  %{time_pretransfer}\n
      time_redirect:  %{time_redirect}\n
 time_starttransfer:  %{time_starttransfer}\n
                    ----------\n
         time_total:  %{time_total}\n
$ 

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 :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null "http://localhost/"
HTTP/1.1 200 OK
Date: Mon, 25 Jan 2021 16:00:28 GMT
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Content-Type: text/html; charset=UTF-8
X-Magento-Cache-Control: max-age=86400, public, s-maxage=86400
Age: 0
X-Magento-Cache-Debug: MISS
Accept-Ranges: bytes
Transfer-Encoding: chunked
Connection: keep-alive

    time_namelookup:  0.001294
       time_connect:  0.001480
    time_appconnect:  0.000000
   time_pretransfer:  0.001551
      time_redirect:  0.000000
 time_starttransfer:  0.030051
                    ----------
         time_total:  0.030324
$

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.

$ curl -D - -w "@curl-format.txt" -o /dev/null -s "http://localhost/"
HTTP/1.1 200 OK
Date: Mon, 25 Jan 2021 16:01:38 GMT
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Content-Type: text/html; charset=UTF-8
X-Magento-Cache-Control: max-age=86400, public, s-maxage=86400
Age: 70
X-Magento-Cache-Debug: HIT
Accept-Ranges: bytes
Content-Length: 30108
Connection: keep-alive

    time_namelookup:  0.001344
       time_connect:  0.001529
    time_appconnect:  0.000000
   time_pretransfer:  0.001600
      time_redirect:  0.000000
 time_starttransfer:  0.002299
                    ----------
         time_total:  0.002713
$

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 :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null "http://localhost:8080/"
HTTP/1.1 200 OK
Date: Mon, 25 Jan 2021 16:07:39 GMT
Server: Apache
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

    time_namelookup:  0.001505
       time_connect:  0.001666
    time_appconnect:  0.000000
   time_pretransfer:  0.001771
      time_redirect:  0.000000
 time_starttransfer:  0.026801
                    ----------
         time_total:  0.027680
$

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 !