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.
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.
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.
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.
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.
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.
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.