Booster son WordPress avec Varnish 2/4

WordPress Varnish logos

Mesurer les temps de réponse et la tenue en charge avec JMeter

JMeter est un « injecteur » qui permet de simuler le parcours de plusieurs internautes et donc de produire de l’audience, de la charge, sur un serveur afin de vérifier son comportement, sa tenue en charge !

Le sujet de la tenue en charge est assez vaste. Ici, on réduira le périmètre aux pages statiques puisque pour les pages dynamiques, le Varnish ne va pas pouvoir utiliser son cache.

Les tests ci dessous ont été effectués sur une VM WordPress de test avec très peu de ressources afin de mieux visualiser les limites de la VM.
La VM WordPress dispose d’un seul vcpu et de 500Mo de RAM et elle se trouve sur mon hyperviseur VirtualBox sur un Macbook Air de 2017 ! Le WordPress utilise le plugin de cache WP Fastest Cache qui génère les pages prêtes à l’emploi sur le disque. A noter, que comme JMeter n’interprète pas le JavaScript ni les feuilles de style CSS, les optimisations de minification de JS, de CSS, l’allègement du poids des images n’apparaissent pas dans les résultats de ces tests.

Dans les paragraphes ci dessous, notre objectif consiste uniquement à « visualiser » l’apport du composant Varnish. On lance un premier test sans Varnish, puis on relance le même test en activant Varnish.

Comme lors du deuxième test, on constate que la VM a encore de la ressource, on lancera un troisième test en doublant le nombre de threads, qui passent de 40 à 80.

Test n°1 : 40 threads sans Varnish

On lance 40 threads JMeter sur le site en SSL avec Nginx, sans cache Varnish.
Les résultats bruts de JMeter : nombre de requêtes 406 128, 0% d’erreur.

L’attribut alt de cette image est vide, son nom de fichier est flotActiveThreadsOverTime-13-1.png.
Nombre de threads actifs en fonction du temps

La légende des abscisses indique le jour 09 (Février) suivi de l’heure.
Les 40 threads sont atteints à 22h27. C’est à partir de ce moment qu’on atteint le maximum de la charge.


Les métriques de la VM sont les suivantes. La granularité de l’outil de graphes Munin, utilisé pour ces tests est de 5 minutes.

L’attribut alt de cette image est vide, son nom de fichier est nginx_request.png.
Nombre de requêtes traitées par Nginx par seconde
L’attribut alt de cette image est vide, son nom de fichier est apache_accesses.png.
Nombre de requêtes traitées par Apache par seconde

On a exactement le même nombre de requêtes traitées par Nginx et par Apache puisqu’il n’y pas de cache. Toutes les requêtes sont transmises à Apache.

L’attribut alt de cette image est vide, son nom de fichier est load.png.
Load average : charge de la VM
L’attribut alt de cette image est vide, son nom de fichier est cpu.png.
graphe d’utilisation de la CPU
L’attribut alt de cette image est vide, son nom de fichier est mysql_queries.png.
Nombre de requêtes MySQL par seconde
L’attribut alt de cette image est vide, son nom de fichier est if_enp0s3.png.
Trafic réseau de la VM en Mbps
L’attribut alt de cette image est vide, son nom de fichier est memory.png.
Utilisation de la mémoire. Il reste de la mémoire libre pendant tout le test.

Les métriques coté JMeter sont les suivantes. La granularité des JMeter est de 1 minutes, c’est donc beaucoup plus précis dans notre cas que les graphes Munin.

L’attribut alt de cette image est vide, son nom de fichier est flotLatenciesOverTime-13.png.
La latence des pages (TTFB) en fonction du temps.

Les temps de réponse sont en millisecondes car JMeter se trouve sur le même hyperviseur que la VM WordPress. On voit que la latence augmente graduellement en fonction de la charge. est perturbée à 22h32 et à 22h35.

L’attribut alt de cette image est vide, son nom de fichier est flotResponseTimesOverTime-13.png.
Les temps de réponse des pages en fonction du temps

On fait le même constat sur les temps de réponse. La courbe violette correspond à une page qui pèse 10 fois plus que les autres, son temps de réponse est plus élevé à cause du temps de transfert.

L’attribut alt de cette image est vide, son nom de fichier est flotBytesThroughputOverTime-13-1.png.
Graphes de débit réseau en MBps (octets) par seconde.

On voit que qu’à partir de 22h27 le débit se dégrade, avec une perturbation à 22h32. On suppose que cette pointe est un artefact lié à la charge. Néanmoins, à partir de 40 thread, il y a un comportement erratique qu’on ne voit pas bien sur les graphes Munin. En y regardant de plus près, on voit que sur les graphes Munin les mesures de 22h30 sont plus faibles que les mesures de 22h25, mais surtout que les mesures de 22h35 sont beaucoup plus faibles, alors qu’il y a toujours 40 threads jusqu’à 22h37. C’est le signe que la VM ne répond plus correctement, on a une dégradation de son comportement à 40 threads.

On va pouvoir constater les différences avec le même test, mais avec Varnish activé qui va cacher toutes les page.

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.