Booster son WordPress avec Varnish 1/4

WordPress Varnish logos

Votre WordPress est déjà optimisé, vous avez installé un plugin de cache, mais avec Varnish, vous allez passer à la vitesse supérieure !

Vous avez un WordPress 5.6, votre site est installé sur une distribution Debian Buster avec Apache/PHP/MySQL. Comme Varnish ne fait pas de SSL, il vous faudra un accélérateur SSL comme Nginx ou HAProxy. Varnish va s’intercaler entre le WordPress et le composant qui gère la terminaison SSL.

On peut installer Varnish 6.1 avec la commande 

Jusque là, comme Varnish s’installe par défaut sur le port 6081, il n’y a aucun impact sur le Wordpress !

On prépare la configuration de Varnish qui se trouve dans /etc/varnish/default.vcl

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 les ports d’écoute d’Apache et de Varnish

Afin que Apache écoute sur le port 8080, il faut modifier 2 fichiers de configuration d’Apache :

On passe Listen 80 à Listen 8080 dans le fichier /etc/apache2/ports.conf et dans la configuration du site WordPress, il faut passer le 80 à 8080 également :

de manière à obtenir :

Le redémarrage d’Apache permet la prise en compte du changement de port :

On modifie le port d’écoute de Varnish pour passer du port par défaut 6081 au port 80, c’est l’option -a de la ligne de commande ExecStart dans le fichier /etc/systemd/system/varnish.service qu’on aura copié depuis la version distribuée :

On lance la prise en compte de cette modification et on redémarre Varnish :

Etape 2 : purger le cache Varnish

Une fois installé, on peut vérifier l’amélioration des performances de la mise en place de Varnish.

Pour vérifier la bon fonctionnement de Varnish, il faut gérer la purge. Sur le serveur Varnish, il suffit de lancer la commande suivante pour vider toutes les URLs mises en cache :

Le . de l’expression régulière veut dire : 0 ou 1 caractère et n’importe lequel. Toutes les URLs vont satisfaire la condition « ~ . » , donc cette expression va bannir toutes les URLs du cache.

La première requête suivant cette purge doit montrer un entête X-Cache: MISS

La deuxième requête identique doit montrer un entête X-Cache: HIT

On pourrait aussi purger des URLs avec une requête du type PURGE, puisqu’on a a géré ce cas dans le fichier default.vcl. Cette configuration permet de faire des purges à distance, sans être loggé sur le serveur et pourra aussi être utilisée par des plugins WordPress pour vider le cache lorsqu’on publie un article.

Par exemple pour purger la page de cet article, dont l’URL est : https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/ il suffit de lancer la requête suivante sur la machine qui héberge le Varnish :

On peut vérifier que la purge a bien fonctionné, en enchainant 2 fois la même requête et en regardant l’entête X-Cache :

Dernier point concernant la purge, on peut vérifier que la purge est interdite depuis une IP externe et génère un code d’erreur 405 qui se trouve dans le fichier /etc/varnish/default.vcl :

A ce stade, nn est prêt à faire des mesures sur l’efficacité des temps de réponse.

Etape 3 : mesurer les temps de réponse unitaires

On peut regarder le temps de chargement d’une page avec cUrl !
On prépare un fichier pour le formatage des temps de réponse comme suit :

Ce format pour cUrl est un format réduit, qui contient uniquement les 3 indicateurs qui nous intéressent. Ce qui produit un time_total qui n’est pas toujours la somme de time_connect + time_starttransfer.

Pour information, le format qui permet d’avoir tous les timers est le suivant :

On lance une requête après le vidage du cache :

On remarque que l’en-tête X-Cache vaut MISS.
La page est servie depuis Apache car elle n’est pas stockée au niveau de Varnish.
Mais si on exécute la même requête encore une fois on obtient :

On divise le temps de réponse par un facteur 10 !!
Si on demande la même page directement depuis Apache, on obtient :

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, beaucoup plus rapidement qu’un serveur Apache !

Sur ce test, on voit l’efficacité de l’addition de Varnish sur les contenus statiques en terme de temps de réponse unitaire. C’est donc un gain pour l’expérience utilisateur !

L’autre bénéfice est celui de la tenue en charge, qu’on peut mesurer avec des outils comme JMeter.

C’est ce que nous allons étudier dans les pages suivantes.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.