Si vous hébergez un site WordPress à fort trafic ou qui doit évoluer pour gérer des pics de trafic, vous êtes probablement déjà familier avec le concept de caching de pages.
Le caching de pages est essentiel pour réduire le temps de chargement des pages et améliorer l’expérience utilisateur.
Chez WP Smart, nous avons toujours recommandé d’utiliser un cache de pages au niveau du serveur, comme Nginx FastCGI Cache ou Varnish. Mais lequel de ces deux est le meilleur pour WordPress ?
Dans cet article, nous allons comparer la mise en cache Varnish et Nginx FastCGI pour voir laquelle sortira en tête. Pendant que nous y sommes, nous évaluerons également WordPress sans la mise en cache activée et ajouterons un plugin de mise en cache WordPress pour faire bonne mesure. J’ai opté pour Simple Cache car, comme son nom l’indique, il est simple à configurer.
Le serveur tournera sur Debian 12. Version moins récente mais plus fiable
Varnish et Nginx
Avant de nous mettre au travail et de nous lancer dans l’analyse comparative, passons en revue chaque technologie que nous allons comparer et pourquoi nous les utiliserions pour la mise en cache.
Varnish Cache est un accélérateur frontal open source pour le Web ou la mise en cache du proxy inverse. Il est installé devant votre serveur Web qui gère les requêtes HTTP et configuré pour mettre en cache le contenu des réponses. Il est également conçu pour être très rapide et, selon la documentation officielle, peut accélérer les délais de livraison du contenu de 300 à 1 000 fois, selon l’architecture.
La fonction principale de Nginx est d’agir comme un serveur Web. Il peut gérer le proxy inverse, la mise en cache, le streaming multimédia et même agir comme répartiteur de charge, entre autres.
Nginx s’est développé au fil des années, commençant comme un simple serveur Web conçu pour une stabilité et des performances maximales. Aujourd’hui, nous allons configurer le nôtre comme un serveur Web qui transmet les requêtes à PHP-FPM. La mise en cache FastCGI (le protocole utilisé pour communiquer entre Nginx et PHP-FPM) sera configurée pour mettre en cache les réponses de PHP-FPM sous forme de fichiers HTML statiques, que Nginx pourra directement servir sur les requêtes ultérieures.
Comme vous pouvez le constater, leurs fonctionnalités ne sont pas exactement les mêmes. Varnish est conçu spécifiquement autour de la mise en cache tandis que Nginx est un serveur Web avec la possibilité d’utiliser la mise en cache cachée sous le capot. Bien que Nginx ne s’appuie directement sur rien d’autre, Varnish nécessite un serveur Web comme Apache ou Nginx pour fonctionner.
Comment évaluer la mise en cache ?
ApacheBench est un outil CLI conçu par Apache Software Foundation et a été créé à l’origine pour tester les performances d’Apache.
Tous les tests de cet article seront effectués en utilisant les mêmes options, à l’exception du test de WordPress sans cache configuré. La raison en est que l’envoi d’autant de requêtes simultanées directement à PHP et MySQL ne fera qu’augmenter le temps de réponse moyen, ce qui n’est pas une représentation juste des performances de PHP.
Cela simule 10 000 requêtes, avec une simultanéité de 100 requêtes. Cela signifie qu’ApacheBench enverra un total de 10 000 requêtes par lots de 100 à la fois. Pour la version non mise en cache, j’utiliserai une simultanéité de 20 requêtes.
L’exécution d’ApacheBench produira des résultats similaires à ceux ci-dessous :
Dans cet article, nous nous intéressons principalement aux requêtes par seconde et aux temps de connexion . Nous effectuerons chaque test 10 fois au total et utiliserons la moyenne à des fins de comparaison.
Nous allons également évaluer uniquement HTTPS, car chaque site devrait l’utiliser à ce stade pour les performances , sans parler de la sécurité. De nos jours, le HTTPS est partout grâce notamment à Let’s Encrypt , et c’est une bonne chose !
root@hermes:~# ab -n 1000 -c 10 -g test.dat "https://demo.wp-smart.com/cs/ab"
This is ApacheBench, Version 2.3 <$Revision: 1903618 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/
Benchmarking demo.wp-smart.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software: Nginx
Server Hostname: demo.wp-smart.com
Server Port: 80
Document Path: /cs/ab
Document Length: 1734 bytes
Concurrency Level: 10
Time taken for tests: 3.613 seconds
Complete requests: 1000
Failed requests: 0
Non-2xx responses: 1000
Total transferred: 1871000 bytes
HTML transferred: 1734000 bytes
Requests per second: 576.77 [#/sec] (mean)
Time per request: 36.131 [ms] (mean)
Time per request: 3.613 [ms] (mean, across all concurrent requests)
Transfer rate: 505.70 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 13 14 0.2 14 15
Processing: 14 22 89.4 14 1020
Waiting: 14 22 89.4 14 1019
Total: 27 36 89.4 28 1033
Percentage of the requests served within a certain time (ms)
50% 28
66% 28
75% 28
80% 28
90% 28
95% 28
98% 28
99% 29
100% 1033 (longest request)
Le serveur
- OVH Rise 1
- Debian 12
- PHP 8.2.13
- Nginx 1.24.0
- MariaDB 10.4.17
- Varnish 7.1.1-1.1
- WordPress 6.4.2 avec Hello Elementor
Nous utilisons OVH depuis un certain temps mais si vous êtes intéressé, nous avons également effectué quelques tests pour trouver le meilleur fournisseur de serveur pour WordPress .
Varnish sera complètement désactivé lorsqu’il n’est pas nécessaire pour l’ensemble actuel de tests. Nginx sera utilisé pour mettre fin aux requêtes HTTPS, car Varnish n’est pas en mesure de le faire. Cela donnera la configuration suivante :
Nginx:443 > Varnish :80 > Nginx :8080
Notez que Nginx agit comme serveur proxy pour mettre fin à HTTPS. Il existe d’autres proxys disponibles pour exécuter cette fonction, mais j’ai opté pour Nginx pour minimiser le nombre de pièces mobiles.
Nous allons tester quatre scénarios différents :
- WordPress – Pas de mise en cache
- Simple Cache – Mise en cache via un plugin WordPress
- Cache FastCGI – Nginx
- Varnish – Varnish utilisant Nginx pour la terminaison HTTPS
Temps de réponse moyen
Comme prévu, WordPress sans mise en cache ne fonctionne pas bien, en raison du goulot d’étranglement créé par le serveur de base de données. Le simple fait de retirer le serveur de base de données de l’équation en activant un cache de pages donne lieu à une multiplication par 10 des requêtes.
Varnish améliore encore les choses en garantissant que les requêtes ne doivent pas être traitées par PHP. Cependant, Varnish est loin derrière Nginx en ce qui concerne le débit brut (requêtes par seconde), probablement en raison de l’étape supplémentaire de terminaison HTTPS de Nginx.
L’utilisation de Nginx seul permet d’obtenir un débit optimal.
Requêtes par seconde
Un nombre élevé de requêtes par seconde ne signifie pas grand-chose si ces requêtes sont lentes à se terminer, c’est pourquoi il est important de mesurer également le temps de réponse. Le temps de réponse moyen est le temps total nécessaire pour qu’une demande soit exécutée.
Lorsqu’un serveur est soumis à une forte charge, le temps de réponse moyen augmente généralement. Cela se produit parce que le serveur n’est capable de gérer qu’un certain nombre de connexions simultanées, généralement en raison de goulots d’étranglement du processeur ou de la mémoire. Lorsque ce nombre est dépassé, toutes les connexions supplémentaires seront mises en file d’attente et traitées au fur et à mesure que les ressources seront disponibles. Si ces demandes restent trop longtemps en file d’attente, elles expireront.
En règle générale, moins vous avez de pièces mobiles dans le cycle de vie d’une requête, plus le temps de réponse moyen sera faible. C’est pourquoi la mise en cache Nginx FastCGI fonctionne si bien, car elle doit uniquement servir un fichier statique à partir du disque (qui sera probablement mis en cache en mémoire grâce au Linux Page Cache ). Une requête vers un site WordPress sans mise en cache touchera Nginx, PHP et le serveur de base de données sur le backend. Avec un plugin de mise en cache, vous n’utilisez que Nginx et PHP. Avec la mise en cache des pages via Nginx FastCGI Cache ou Varnish, vous appuyez uniquement sur Nginx ou Varnish.
Chez WP Smart, nous optons pour une durée de cache plus longue et purgeons l’intégralité du cache lors de la mise à jour du contenu. Nous avons trouvé cette solution plus fiable que d’essayer de déterminer exactement quelle ou quelles pages Web doivent être purgées du cache, ce qui peut devenir compliqué assez rapidement en raison des archives de publication et de la pagination.
Avec tout cela pris en compte, la mise en cache Nginx FastCGI reste notre solution préférée, c’est pourquoi nous avons supprimé Varnish de notre serveur il y a des années et nous appuyons désormais uniquement sur Nginx. C’est également ainsi que nous configurons chaque serveur.
Et vous quelles performances avez vous sur vos serveurs ? quelles résultats sur Google PageSpeed ?