L’apport de Varnish est important, par contre, on ne voit pas ce qu’apporte le plugin de cache WordPress. Effectivement, sur les pages statiques lorsque Varnish est installé, WordPress ne travaille plus. On verra néanmoins l’intérêt du plugin en conclusion.

J’ai utilisé le plugin WordPress de cache WP Fastest Cache pour faire les tests, mais globalement tous les plugins de cache WordPress travaillent de la même manière. Ils créent la page sur le disque et WordPress, ou plutôt le serveur Web, Apache ou Nginx, renvoie directement la page depuis le disque. Il ne devrait pas y avoir beaucoup de différence entre les différents plugins de cache pour WordPress. Donc celui-ci ou un autre, ce n’est pas la question dans cet article.

l’infrastructure cible est une petite VM avec 1 vcpu et 500Mo de RAM sur VirtualBox de mon MacBook Air 2017. L’injecteur JMeter est sur une autre VM de ma machine, les latences sont donc très faibles par rapports aux latences sur Internet.

On va tester un scénario de 7 pages statiques :

Sur 3 configurations différentes

1. WordPress avec Varnish
2. WordPress sans Varnish et sans plugin
3. WordPress sans Varnish et avec le plugin WP Fastest Cache

JMeter est configuré pour lancer 30 threads. Il passe de 1 à 30 en 5 minutes et reste 2 minutes à 30 threads, sans aucun délai entre les threads. Ce n’est pas très réaliste, c’est juste un test technique. On verra d’ailleurs dans l’analyse que le serveur est saturé bien avant d’arriver au plateau des 30 threads dans les 3 cas.

WordPress avec Varnish

On retrouve les performances qu’on avait déjà vues dans l’article Booster son WordPress avec Varnish 5/4. Dans cette configuration, on arrive à produire plus de 30Mbps de flux depuis le serveur.

La connexion initiale lors de l’accès à la « Home page » prend du temps. C’est le temps de la création de la communication TCP/IP et la mise en place du SSL avec le serveur Nginx. Et au début de chaque threads, il y a une reconnection afin de simuler la réalité.

La latence ci-dessus est l’équivalent du Time To First Byte (TTFB). On voit que les latences sont exceptionnelles basses sauf pour la « Home page » en violet. Quelque soit la page, Varnish la sort de la mémoire sans aucun traitement. Il n’y a donc aucune différence entre les pages.

On va plutôt étudier les temps de réponse qui sont plus démonstratifs, sur les autres configurations.

Ici, on voit que les temps de réponse sont très similaires au TTFB, puisqu’ensuite, s’ajoute le temps de transfert de la page à l’intérieur du MacBook !

WordPress sans Varnish sans plugin de cache

Par contre, avec la deuxième configuration, sans Varnish et sans plugin, les temps de réponse sont nettement plus élevés

L’échelle du graphe est 4 fois plus grande, on atteint la seconde. Et on note une différence entre les pages, cette fois-ci. La « Home » est en violet, mais dépassée par les catégories. En troisième c’est la page « 5 – /2021/02/01/nouvel-article/ » qui est plus lourde que les autres, car elle a plus de contenu. Le temps de réponse est quasiment le même pour les autres pages.

WordPress sans Varnish avec plugin de cache

Avec la troisième configuration, sans Varnish mais avec le plugin WP Fastest Cache, les temps de réponse sont meilleurs que ceux de la configuration précédente :

L’échelle du graphique est divisé par 3 par rapport au précédent, on atteint les 350 ms.

Maintenant qu’on a vu le détail des pages et les temps de réponse, on va pouvoir comparer les graphes de consommation de ressources du serveur.
Dans les graphes qui suivent, les 3 périodes correspondent aux 3 configurations dans l’ordre suivant :

1. WordPress avec Varnish
2. WordPress sans Varnish et sans plugin
3. WordPress sans Varnish et avec le plugin WP Fastest Cache

La première période, celle « Avec Varnish » montre que la CPU est tout de même tout utilisée.
C’est l’effet HTTPS ! Toute la CPU est utilisée par Nginx pour la terminaison SSL. C’est à se demander si on ne ferait pas mieux d’abandonner le SSL pour les sites statiques afin diminuer la consommation énergétique du numérique !

Pour les deuxièmes et troisièmes périodes, on atteint les 100% d’utilisation de la CPU. Dans ces 2 cas, on constate une contention de la CPU. Dans le premier cas, sans Varnish sans plugin, les 100% de CPU sont atteints de suite. Dans le cas sans Varnish mais avec plugin, les 100% sont atteints dans les 3 minutes. On note plus d’activité système dans ce dernier cas. En effet, on va le confirmer sur les débits, avec le plugin de cache, le débit est beaucoup plus élevé, donc les entrées/sorties sont plus sollicitées.

On voit clairement avec ce graphe de débit, la capacité à fournir des pages lorsque Varnish fonctionne. La contention se situe au niveau du réseau avec Varnish. A 36Mbps, on est au maximum de ce que la VM peut produire. Pour les 2 autres configurations les débits sont beaucoup plus faibles, la contention se situe bien au niveau de la CPU.

Le graphe du Load average est l’inverse de celui du débit ! On confirme la contention au niveau de la CPU.

Regardons les 2 graphes MySQL

Là aussi, on confirme les données précédentes. Avec Varnish, il n’y a pas de requêtes. Toutes les pages sont en RAM. Sans Varnish, WordPress récupère une partie de ses données depuis MySQL. Sans plugin, le site fait deux fois plus de requêtes.

Avec le plugin de cache WordPress, le site fournit presque trois fois plus de pages, c’est pour cette raison qu’il y a plus de données extraites du MySQL et avec moins de requêtes. On suppose que les traitements sont optimisés pour extraire le maximum de données en un minimum de requêtes.

Le bilan en nombre de pages pour les 3 configurations avec le même scénario qui dure 7 minutes est le suivant :

1. WordPress avec Varnish :
   190 000 pages
   débit max de 500 pages/s
2. WordPress sans Varnish et sans plugin :
   18 000 pages
   débit max de 46 pages/s
3. WordPress sans Varnish et avec le plugin WP Fastest Cache :
   56 000 pages
   débit max de 150 pages/s

Même si les graphes ne sont pas toujours parlants, ce bilan permet de remettre les résultats en perpective :

Avec Varnish le site WordPress produit 3 fois plus de pages (indépendamment du plugin de cache), que lorsque WordPress est configuré avec un plugin de cache.
Avec le plugin de cache le site produit 3 fois plus de pages que lorsque WordPress n’a pas de plugin.
Il faut quand même noter qu’il y a une saturation réseau avec Varnish et que sans SSL on pourrait améliorer les performances d’un facteur au moins 2 !

Le bilan est clair. Les plugins de cache apportent une performance significative à WordPress. Il ne faut donc pas s’en priver puisqu’ils s’installent de manière quasiment automatique. C’est une optimisation facile à mettre en place chez les hébergeurs qui fournissent du WordPress clé en main. Pour passer à la vitesse supérieur, il faut ajouter Varnish.

Alors pourquoi ne pas installer Varnish et c’est tout !

Parce que les plugins de cache optimisent l’expérience utilisateur ! Nous n’avons pas regardé ce qui se passe lorsqu’on charge une page du point de vue utilisateur. Mais les optimisations comme la minification des CSS, du JavaScript ou l’allègement des images sont essentielles pour le ressenti utilisateur ! Et c’est un critère de poids pour les outils d’analyse de sites.

Lors des tests de charges, nous n’étudions pas ces aspects. Le bilan est clair, il faut Varnish ET un plugin de cache si on veut améliorer les performances de WordPress sous tous les aspects.

Donc à la question : WordPress : Plugin de cache ou Varnish ?
Je réponds : les 2 mon capitaine !

La dernière optimisation pour les performances c’est l’addition d’un CDN. Le problème c’est qu’ils sont, soit payants, soit nécessitent de laisser la gestion du domaine, comme CloudFlare. Mais c’est un « must have » pour les sites à forte audience internationale.

Petite réflexion sur les tests menés ci-dessus.

Dans les 3 configurations, on atteint les limites de la VM bien avant le plateau des 30 threads. On pourrait dire, il valait mieux aller à 20 threads ou moins selon la configuration, pour voir les graphes monter en fonction de la charge sans aller jusqu’à la saturation. Alors effectivement, dans ce cas les graphes auraient été plus lisibles.

Mais en fait, tant que les scénarios ne font pas d’erreur, et là, pour nos 3 scénarios, on a 0% d’erreur, on peut ajouter de la charge et saturer le système, ce n’est pas très grave. On atteint les limites plus vite. Et comme on cherche à comparer les limites des 3 configurations autant y aller !

Alors que se passe-t-il lorsqu’on atteint une contention et que WordPress continue à répondre sans erreur ?

Et bien, il répond plus lentement ! C’est comme un bouchon d’automobilistes sur la route. On passe toujours le même nombre de voiture par tronçon, mais plus lentement. C’est la raison de l’augmentation des temps de réponse. Plus on ajoute de threads, plus les temps de réponses augmentent, le débit restant à peu près inchangé pendant tout le restant du test.
Le critère à retenir, c’est vraiment le débit du site, ou le nombre de pages par seconde. On voit très bien pendant les tests de charge que cette valeur va se figer dès qu’on atteint un certain nombre de threads, qu’on mette des timers, qu’on simule les utilisateurs ou pas, ce nombre ne varie pas. Ce nombre est la limite de l’infrastructure.

Si on ajoute des threads, les pages arrivent plus lentement, car il y une contention, c’est le phénomène « bouchon ». Si on continue à ajouter des threads, passé une autre limite on commence à voir des erreurs. A partir de ce point là, le test n’est plus pertinent.

Les erreurs sont donc un point à surveiller lors des tests avec JMeter, et les assertions sont la réponse à cette exigence !

Références :
WordPress
JMeter
Varnish
WP Fastest Cache

L’article WordPress : Plugin de cache ou Varnish ? est apparu en premier sur Alain ARDITI's blog.

Mais pour le test d’une boutique en ligne, c’est également un moyen de ne pas toujours mettre les mêmes produits dans le panier.

Dans l’article présent, je vais détailler comment définir plusieurs utilisateurs pour le scénario pour WordPress.

Il faut créer les utilisateurs dans WordPress en premier.

Dans l’écran de création des utilisateurs, l’email est obligatoire et il faut qu’il soit différent pour chaque utilisateur. Il est possible d’utiliser des alias d’email avec +. Ici alain+1@arditi.fr est un email différent de alain@arditi.fr pour WordPress, mais ils renvoient tous les deux sur la même boite. On pourrait mettre n’importe quoi derrière le + : alain+testwordpress@arditi.fr . Cette fonctionnalité est fournie par les serveurs de mail et non pas par WordPress. Là, il ne faut pas oublier de copier les mots de passe qu’on va utiliser par la suite.

Par ailleurs, on crée un fichier des utilisateurs : users.csv dans lequel on va déclarer les utilisateurs avec les mots de passe. Notre format utilise la virgule comme séparateur entre le login et le mot de passe. Attention, si le mot de passe contient une virgule, ça pose problème. Dans ce cas, on peut changer le séparateur pour mettre une tabulation si besoin :

aa2@apollo:~$ cat users.csv
aa2-1,j5Bm4mLKmv$!Y!kX8h0lAxcS
aa2-2,o&xoYmoG&ElHdG8RJQ6tjNeM
aa2-3,GvCcybyebOWz#BF3St$yda7D
aa2-4,sncEXfUd5q1vEbr@ZqCGaKsI
aa2-5,S#JLq3kqgC2UE5o4tR#a7iIo
aa2@apollo:~$

On déclare ce fichier et sa syntaxe. On déclare les 2 variables LOGIN et PASSWORD qui vont contenir les valeurs du fichier users.csv.

Maintenant on peut utiliser les 2 variables ${LOGIN} et ${PASSWORD} dans la page d’authentification

L’article Les tests de charge avec JMeter : les fichiers de données est apparu en premier sur Alain ARDITI's blog.

Lors d’un test de charge, quand on crée le scénario le matin et qu’on le lance l’après-midi, tout va bien, car le permalien d’un article créé dans la journée n’a pas varié pour la partie date.

Lorsqu’on rejoue le scénario le jour suivant, on a des erreurs car le permalien n’est plus à jour. L’URL de l’article génère un « 404 Not found » !

Il faut donc utiliser la date du jour dans les scénarios pour avoir le bon lien.

On va utiliser la variable/fonction : ${__time(yyyy/MM/dd,)} pour obtenir des permaliens variables sur la date.

Je cherche la chaîne « 2021/02/26 » dans le scénario avec les jumelles

Je trouve 2 URLs qui utilisent cette date :

L’affichage de l’article et l’affichage de wp-admin qui contient cette date dans le Referer de la requête. Si le Referer n’est pas correct, ça ne produit pas d’erreur dans WordPress.

Avec cette variable on peut rejouer le scénario à volonté indépendamment de la date.

Pour avoir le détail sur les fonctions et les variables prédéfinies dans JMeter voir la documentation sur les fonctions.

L’article Les tests de charge avec JMeter : permaliens variables avec date est apparu en premier sur Alain ARDITI's blog.

https://alain.arditi.fr/wp-admin/post.php?post=809&action=trash&_wpnonce=feaf2f87fd

Ce lien contient l’identifiant de l’article, ici 809 et un nonce qui vient de la page qui affiche les articles https://alain.arditi.fr/wp-admin/edit.php

Nous allons extraire le nonce depuis la page 482 – /wp-admin/edit.php de notre scénario en passant par un BeanShell PostProcessor qui permet de rajouter l’id_article dans l’expression régulière.

On construit une variable s qui contient l’expression régulière qu’on va passer dans RegPhrase qui sera utilisée dans le « Regular Expression Extractor » :

String s = "post=${id_article}&action=trash&_wpnonce=([^\"]+)\"";
vars.put("RegPhrase",s);

Notez qu’il faut protéger les " qui font partie de l’expression régulière avec un \ : ([^\"]+)\"

Dans le « Regular Expression Extractor » on retrouve cette fois la variable RegPhrase qui contient notre expression régulière variable

Maintenant qu’on a le « nonce » pour supprimer l’article, on peut l’utiliser dans la page de suppression

Afin de finaliser un scénario complet avec le vidage de la corbeille et le logout, voici les différents « nonces » à extraire et leur utilisation

Nonce pour la santé du site

Ce « nonce » est utilisé dans les requêtes Ajax qui permettent d’avoir l’état de santé du site : le health check site status.
Il est posé sur la page de login /wp-login.php, une fois qu’on est authentifié et il est utilisé dans les requêtes de la forme /wp_admin/admin-ajax.php pour avoir l’état de santé du site.

L’expression régulière pour l’extraire est :
"site_status_result":"([^"]+)"

Nonce pour le battement de coeur

C’est le « nonce » qui permet de vérifier la légitimité de nos actions sur les articles de WordPress. Il est posé dans la page qui affiche tous les articles /wp-admin/edit.php et il est utilisé dans les requêtes de la forme /wp_admin/admin-ajax.php. Si le « nonce » n’est pas correct, WordPress considère qu’on n’est plus authentifié et renvoie des codes « 403 Forbidden » sur les requêtes Ajax. Sur les autres pages on reçoit un code 200, mais c’est la page de login qui s’affiche. D’où l’intérêt d’ajouter des assertions qui vérifient que les réponses à nos requêtes sont bien celles qu’on attend.

L’expression régulière pour l’extraire est :
{"nonce":"([^"]+)"}

Nonce de création d’un article

Ce « nonce » est généré lorsqu’on crée un article, sur l’URL /wp-admin/post-new.php, et il est utilisé dans toutes les requêtes qui suivent la création jusqu’à la publication de l’article.

L’expression régulière pour l’extraire est : wp.apiFetch.createNonceMiddleware\( "([^"]+)" \)

Nonce de déverrouillage de l’article

Ce « nonce » est généré lorsqu’on crée un article, sur l’URL /wp-admin/post-new.php, et il est utilisé lorsqu’on publie l’article sur une URL /wp_admin/admin-ajax.php

L’expression régulière pour l’extraire est :
"unlockNonce":"([^"]+)"

Dans la requête précédente, on voit qu’on passe un paramètre active_post_lock qui vaut 1614277890:1. Cette valeur est le timestamp de création de l’article au format Epoch suivi de l’identifiant de l’utilisateur. Pour afficher le timestamp au format date, il faut lancer la commande suivante dans un Shell :

aa2@apollo:~$ date -r 1614277890
Thu Feb 25 19:31:30 CET 2021
aa2@apollo:~$

La variable prédéfinie ${__time(/1000,)} fournit le timestamp à la seconde.

Nonce de vidage de la corbeille

On récupère ce « nonce » dans la page /wp-admin/edit.php et on l’utilise dans la même page /wp_admin/edit.php mais avec l’action « Vider la corbeille ».

L’expression régulière pour l’extraire est :
<input type="hidden" id="_wpnonce" name="_wpnonce" value="([^"]+)" />

Nonce de déconnexion

C’est le nonce qu’il faut fournir pour terminer sa session proprement. On le récupère sur la page /wp-admin/edit.php et on l’utilise sur /wp-admin/login.php

L’expression régulière pour l’extraire est :
action=logout&_wpnonce=([^']+)'>Se

En plus des « nonces » ci dessus, on avait déjà extrait l’identifiant de l’article dans l’article précédent : Les tests de charge avec JMeter 4/4. Ce qui fait au total 8 « nonces » ou variables pour un scénario qui est très simple. Ce scénario n’a pas d’intérêt en soi, il permet d’illustrer la création de scénarios sur des pages dynamiques. WordPress est un bon exemple car on voit ici que le scénario nécessite pas mal de travail pour fonctionner parfaitement.

Un point à noter, c’est la dépendance du scénario avec le site à tester. Dans le cas de ce WordPress, on a des URLs qui dépendent de certains plugins. L’URL /wp-json/contact-form-7/v1/contact-forms se retrouve dans le scénario car il y a le plugin Contact Form 7, même si on ne l’utilise pas.

Dans les expressions régulières on est parfois contraint par la locale du site. Si on a plusieurs locales, il faut trouver des expressions régulières indépendantes de la locale.

Tout ceci montre la relative fragilité des scénarios. Il est possible qu’avec une nouvelle version de WordPress le scénario actuel ne fonctionne plus. Pareil si j’ajoute des plugins, ou que je change de langue.

Le bilan est que maintenir un scénario dans la durée est compliqué et nécessite un investissement constant sans quoi si on s’y remet une fois par an on repart de zéro à chaque fois !

L’article Les tests de charge avec JMeter 5/5 est apparu en premier sur Alain ARDITI's blog.

Ensuite on saisit un titre et un texte dans le contenu, puis, on clique sur le bouton « Publier ».

Ensuite, on retourne sur la page qui affiche tous les articles et on le supprime en cliquant sur le lien Corbeille qui apparaît sous l’article lorsqu’on passe la souris sur l’article.

On arrête l’enregistrement du scénario à cette étape, on reprendra ensuite pour vider la corbeille et se déconnecter.

Par contre, il faut absolument conserver les éléments du « View Result Tree » lors de l’enregistrement, car c’est par les données de l’enregistrement qu’on va pouvoir retrouver les « nonces » à passer dans les requêtes. En effet, on va vite s’apercevoir qu’une page comme celle qui affiche tous les article wp-admin/edit.php va produire plusieurs « nonces » par article affiché, ne serait que celui pour le modifier et celui pour le supprimer. Mais si vous avez des plugins, comme un gestionnaire de cache, il va également ajouter un « nonce » par page, pour purger le cache.

La technique qui va nous permettre de savoir quel « nonce » est utilisé à quel moment, est la suivante :

1 – Sauvegarder le résultat de l’enregistrement dans un fichier

Là on parle d’enregistrer le « View Result Tree » du « Test Script Recorder ». il faut fournir un fichier pour que le Script Recorder stocke les résultats. Par défaut, tout ce qui est nécessaire est coché dans la configuration

2 – Enregistrer une partie du scénario

J’écris « une partie », car enregistrer un scénario complet, même simple, comme par exemple pour WordPress, se connecter, afficher les articles, créer un article, saisir du texte, publier l’article, supprimer l’article, vider la corbeille et enfin se déconnecter, va produire plus d’une cinquantaine de requêtes, car il y a de l’Ajax qui entre en jeu.

On se retrouve assez vite noyé avec le décalage entre les actions et les requêtes. Donc procéder par étape allège un peu le travail. C’est la raison pour laquelle on a commencé par l’étape où on se connecte à WordPress. Maintenant on va regarder la suite : afficher les articles, créer un article, le publier et le mettre à la corbeille.

On va enrichir notre scénario du login. On définit le « Counter start value » à 120 afin d’avoir une suite de numéros croissants pour identifier les URLs du Thread Plan.

On démarre le scénario en se connectant, mais sans lancer l’enregistrement, qu’on va démarrer à l’affichage de la page « Tous les articles ». C’est à dire qu’on démarre l’enregistrement, on définit le proxy dans le navigateur et on affiche l’URL /wp-admin/edit.php

On crée l’article, on le publie et on le met à la corbeille.

A la fin de l’enregistrement, on voit une vingtaine d’URLs supplémentaires dans le Thread Plan

On peut noter que dans deux des URLs, la 146 et la 151, l’identifiant 788 de l’article apparaît. Il va falloir rendre cette valeur variable pour suivre la valeur de cet incrément.

3 – Lancer le scénario et faire l’état des lieux

Si on rejoue le scénario sans faire de retouche, on va constater les erreurs dans l’item « View Result Tree » du Thread Plan. Toutes les pages en rouges ont reçu des 403 Forbidden, et la page 153 wp-admin/edit.php affiche l’article créé.

Les erreurs de permission sont liées aux « nonces ». On a renvoyé les valeurs enregistrées précédemment au lieu des aléas fournis par WordPress.

A partir de cette étape, il suffit d’éliminer les erreurs une par une !!

4 – Mettre l’identifiant de l’article en variable

On a vu que notre enregistrement a créé l’article n°788. Il faut chercher cette valeur dans la réponse (Response Body) de la création d’article : post-new.php. On trouve de nombreuses références à l’article 788, mais la plus simple à extraire, donc celle qui est la plus discriminante se trouve dans le bloc :

<script id='wp-editor-js-before'> var _wpMetaBoxUrl = "https:\/\/alain.arditi.fr\/wp-admin\/post.php?post=788&action=edit&meta-box-loader=1&meta-box-loader-nonce=fc2b874bfc"; </script>

qu’on voit sur le panneau de droite lorsqu’on fait la recherche de 788

L’expression régulière pour extraire l’id_article, va être :
post.php\?post=([^&]+)&
A noter le \ devant le ? car sinon, le ? génère une expression régulière et produit une erreur. On peut désormais utiliser la variable ${id_article} partout où apparaît 788 dans le scénario.

On lance la recherche de 788 avec les jumelles on voit sur le panneau de gauche les URLs qui contiennent ce numéro. On peut même faire un Search/Replace de 788 par ${id_article} en faisant attention aux valeurs qu’on remplace.

Dans le cas de l’URL 151 – /wp-json/wp/v2/posts/788?_locale=user on remplace le 788 dans l’URLs par ${id_article}, mais aussi dans le texte de l’article, comme ça chaque article créé par le scénario aura un titre différent.

Voila un exemple de correction des problèmes liés à l’id_article.

Pour que le scénario fonctionne, il reste encore une dizaine de valeurs en dur, surtout des « nonces » à extraire et à mettre en variable. Afin d’alléger l’article, on va uniquement voir comment trouver le « nonce » pour mettre l’article à la corbeille. C’est le cas le plus complexe, car la mise à la corbeille est une URL qui contient l’id_article, donc une expression régulière variable ! Elle est de la forme : post=${id_article}&action=trash&_wpnonce=([^"]+)"

On va explorer comment faire une expression régulière pour extraire le nonce avec la variable id_article dans l’expression.

L’article Les tests de charge avec JMeter 4/5 est apparu en premier sur Alain ARDITI's blog.

WordPress est un bon exemple de serveur qui utilise des « nonces » pour contrôler la légitimité des requêtes.

Lorsque vous affichez un formulaire, comme la page des Articles, WordPress place des champs cachés contenant des nombre aléatoires, les « nonces », qu’il faut obligatoirement fournir lorsqu’on envoie, on poste, les champs du formulaire sans quoi, on reçoit un message « Forbidden 403 » qui indique de WordPress refuse notre requête.

Il faut donc passer obligatoirement par l’affichage des formulaires avant de lancer une requête avec les données du formulaire afin de récupérer le bon « nonce ». Et des fois, on s’aperçoit que le « nonce » a été fourni quelques pages auparavant et pas juste dans la requête précédente !

Il faut démarrer le scénario en se connectant sur le backoffice WordPress avec des identifiants. Ce sera la première partie du scénario.

Pour démarrer, on va enregistrer le login sur le backoffice avec le Recorder, comme on l’a fait pour les pages statiques dans l’article Les tests de charge avec JMeter

On arrête l’enregistrement dès qu’on est loggé. On peut rejouer le scénario et voici de qu’on obtient :

On constate qu’on a plus d’une dizaine d’URL rien que pour le login !
On a également deux erreurs sur les URL Ajax lorsqu’on rejoue le scénario. Mais pour le login, ça fonctionne. Si on regarde de plus près ce qu’on envoie sur le formulaire de login :

On voit que le login et le mot de passe sont effectivement transmis sur le formulaire. On note que l’URL contient deux variables ${scheme}://${host}/wp-admin

Ces variables sont déclarées dans l’item « User Defined Variables » et sont utilisé par la suite par JMeter. Ces variables permettent par exemple de lancer le même scénario sur un serveur en HTTP et en HTTPS ou sur un port comme le 6081 pour avoir directement Varnish ou 8080 pour avoir directement Apache. On pourra ainsi comparer les performances selon l’architecture

Maintenant si on s’intéresse aux erreurs sur les requêtes Ajax, on voit le code de retour « 403 Forbidden »

Si on regarde les données de la requête POST, on voit un « _wpnonce »

On retrouve ce « nonce » dans notre scénario

Comme ce « nonce » a une valeur fixe dans notre scénario et que WordPress génère des valeurs aléatoires à chaque login, cette requête Ajax ne va pas fonctionner si on ne lui transmet pas le bon « nonce ».

Pour trouver le bon « nonce », il faut chercher dans le « View Result Tree » du « Test Script Recorder » qui a été généré lorsqu’on a enregistré le scénario ! En effet, le « nonce » a été fourni par une page précédente et a été utilisé ensuite dans l’Ajax. Une fois qu’on rejoue le scénario, le « nonce » présenté n’est plus le même. Et comme WordPress en place une bonne dizaine, il n’est pas simple de retrouver le bon. Il faut donc faire une recherche de la chaîne "fc5858da59" dans le « View Result Tree » du « Test Script Recorder »

Le « nonce » est généré sur la page 053 - /wp/admin/
On va essayer de récupérer sa valeur par une extraction sur le corps de la page HTML, qu’on voit si on affiche l’onglet « Response Body » et qu’on fait une recherche de la chaine "fc5858da59" on trouve la ligne

<script>
var SiteHealth = {"screen":"dashboard","nonce":{"site_status":"33e44d2192","site_status_result":"fc5858da59"},"site_status":{"direct":[],"async":[],"issues":{"good":"15","recommended":"4","critical":"1"}}};
</script>

que nous allons utiliser pour récupérer un « nonce » qui changera à chaque login.

On va ajouter un post processeur sur la page 052 - /wp-login/ pour faire une extraction de cette valeur et la stocker dans une variable, qu’on appellera site_status_nonce. On n’utilise pas 053- /wp/admin/, car la page est grisée, c’est le résultat de la redirection du login. C’est la requête 052 - /wp-login/ qui fournira le « nonce » !

On va remplir les champs avec l’expression régulière : "site_status_result":"([^"]+)" qui signifie tout ce qui se trouve entre ″ et ″ et qui ne contient pas de ″.

On pourrait utiliser l’expression régulière "site_status_result":"(.+?)" qui signifie n’importe quoi jusqu’à la première ″ rencontrée. Le ? permet d’avoir une expression « non greedy », sinon le moteur d’expression prend tout ce qu’il trouve jusqu’à la dernière ″ du fichier !
Pour plus d’informations, il faut regarder la documentation : https://jmeter.apache.org/usermanual/regular_expressions.html

On peut également tester les expressions régulières dans JMeter. Dans le « View Result Tree », on affiche la page 052 - /wp-login/ et dans la combo box au dessus, on choisit « Regexp Tester ». On peut alors saisir une expression régulière dans le panneau de droite, qui va s’appliquer au « Request Body » de la page 052 - /wp-login/. On peut vérifier ici, qu’on récupère le « nonce » f9d0db48be

Maintenant qu’on sait récupérer le « nonce », il faut l’utiliser. Il faut modifier les 2 pages Ajax
109 - /wp-admin/admin-ajax.php et
110 - /wp-admin/admin-ajax.php pour mettre la variable ${site_status_nonce} dans les paramètres de la requête

Désormais, les requêtes Ajax fonctionnent et renvoient un code 200 !

A ce stade, on a un login qui fonctionne. On pourrait faire un scénario sans lancer ces requêtes Ajax qui ont pour principal objectif de montrer comment récupérer un « nonce » dans une page Web.

Dernière étape du login, on peut nettoyer les requêtes qui sont grisées. En effet, ce sont des requêtes implicites, qui proviennent de redirection des requêtes précédentes.

Par exemple, l’appel de « 024 – wp-admin » déclenche les redirections suivantes, qu’on peut voir du coté du navigateur :

L’enchaînement est le suivant

1. https://alain.arditi.fr/wp-admin
2. http://alain.arditi.fr/wp-admin/
3. https://alain.arditi.fr/wp-admin/
4. https://alain.arditi.fr/wp-login.php?redirect_to=https%3A%2F%2Falain.arditi.fr%2Fwp-admin%2F&reauth=1

Les lecteurs perspicaces verront une optimisation qui consiste à ne pas repasser en HTTP à l’étape 2 puis repasser en HTTPS à l’étape 3. C’est une optimisation qui supprime un aller/retour entre le client et le serveur. 31 ms d’après la trace du « Waterfall ». Cette redirection est faite au niveau d’Apache par les rewrites ajoutés par le plugin WP Fastest Cache. Dans le cas présent, je laisse, l’enjeu étant faible, et surtout à la prochaine mise à jour du plugin je perdrais mes modifications.

Comme JMeter suit les redirections par défaut, il va lancer les 4 requêtes à partir de la première. C’est la raison qui fait que dans notre scénario, on retrouve 3 requêtes grisées. Elle ne sont pas jouées par défaut. On peut donc supprimer toutes les requêtes grisées pour alléger. On retrouve notre scénario de login final :

Dans l’article suivant on va continuer notre scénario. On va créer un article, renseigner du contenu et le mettre à la corbeille. En effet, sans la mise à la corbeille, un scénario qui générerait 1000 créations d’articles, nous obligerait à les supprimer par la suite, sans quoi on se retrouverait avec un site rempli d’article de test ! Dans ces requêtes on va être obligés de trouver les « nonces », sans quoi, impossible de créer, publier ou supprimer un article.

A noter que la bonne manière de procéder pour les tests de charge voudrait qu’on réinitialise les données après chaque test. On remet le site comme d’origine. On pourrait très bien ne pas supprimer les articles si on restaure les données. Avec WordPress, il suffit de restaurer la base de données.

Site officiel de JMeter : https://jmeter.apache.org/

L’article Les tests de charge avec JMeter 3/5 est apparu en premier sur Alain ARDITI's blog.

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 

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

backend default {
    .host = "localhost";  # WordPress 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 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 :

$ less /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
....

de manière à obtenir :

$ less /etc/apache2/sites-enabled/000-default.conf
<VirtualHost *:8080>
# The ServerName directive sets the request scheme, hostname and port that
....

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

$ sudo apachectl -t
Syntax OK
$ 
$ sudo systemctl restart apache2
$ sudo systemctl status apache2
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 10:01:27 CET; 9h ago
     Docs: https://httpd.apache.org/docs/2.4/
 Main PID: 26634 (apache2)
    Tasks: 13 (limit: 4696)
   Memory: 244.9M
   CGroup: /system.slice/apache2.service
           ├─ 3666 /usr/sbin/apache2 -k start
           ├─ 5662 /usr/sbin/apache2 -k start
           ├─ 5663 /usr/sbin/apache2 -k start
           ├─ 6443 /usr/sbin/apache2 -k start
           ├─26634 /usr/sbin/apache2 -k start
           ├─26637 /usr/sbin/apache2 -k start
           ├─26639 /usr/sbin/apache2 -k start
           ├─26899 /usr/sbin/apache2 -k start
           ├─26900 /usr/sbin/apache2 -k start
           ├─26901 /usr/sbin/apache2 -k start
           └─26920 /usr/sbin/apache2 -k start
Jan 25 10:01:27 aa2 systemd[1]: Starting The Apache HTTP Server...
Jan 25 10:01:27 aa2 systemd[1]: Started The Apache HTTP Server.
$

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 :

$ sudo cp /lib/systemd/system/varnish.service /etc/systemd/system/varnish.service
$
## et modifié comme suit :
$ cat /etc/systemd/system/varnish.service
[Unit]
Description=Varnish HTTP accelerator Documentation=https://www.varnish-cache.org/docs/6.1/ man:varnishd
[Service]
Type=simple
LimitNOFILE=131072
LimitMEMLOCK=82000
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m ExecReload=/usr/share/varnish/varnishreload
ProtectSystem=full 
ProtectHome=true 
PrivateTmp=true 
PrivateDevices=true
[Install] 
WantedBy=multi-user.target 
$

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

$ sudo systemctl daemon-reload
$ sudo systemctl restart varnish
$ sudo systemctl status varnish
● varnish.service - Varnish HTTP accelerator
   Loaded: loaded (/lib/systemd/system/varnish.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2021-01-25 19:46:50 CET; 7s ago
     Docs: https://www.varnish-cache.org/docs/6.1/
           man:varnishd
 Main PID: 11354 (varnishd)
    Tasks: 217 (limit: 4696)
   Memory: 116.4M
   CGroup: /system.slice/varnish.service
           ├─11354 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
           └─11366 /usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
Jan 25 19:46:50 aa2 systemd[1]: Started Varnish HTTP accelerator.
Jan 25 19:46:52 aa2 varnishd[11354]: Debug: Version: varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460
Jan 25 19:46:52 aa2 varnishd[11354]: Debug: Platform: Linux,4.19.0-9-amd64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
Jan 25 19:46:52 aa2 varnishd[11354]: Version: varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460
Jan 25 19:46:52 aa2 varnishd[11354]: Platform: Linux,4.19.0-9-amd64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
Jan 25 19:46:52 aa2 varnishd[11354]: Debug: Child (11366) Started
Jan 25 19:46:52 aa2 varnishd[11354]: Child (11366) Started
Jan 25 19:46:52 aa2 varnishd[11354]: Info: Child (11366) said Child starts
Jan 25 19:46:52 aa2 varnishd[11354]: Child (11366) said Child starts
$ 

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 :

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

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 :

$ curl -D - -X PURGE "http://localhost/2021/02/09/booster-son-wordpress-avec-varnish/"
HTTP/1.1 200 Purged.
Date: Tue, 09 Feb 2021 13:45:18 GMT
Server: Varnish
X-Varnish: 229742
Content-Length: 0
Accept-Ranges: bytes
Connection: keep-alive
$ sudo varnishadm 
200        
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,4.19.0-9-amd64,x86_64,-junix,-smalloc,-sdefault,-hcritbit
varnish-6.1.1 revision efc2f6c1536cf2272e471f5cff5f145239b19460
Type 'help' for command list.
Type 'quit' to close CLI session.
varnish> ban.list
200        
Present bans:
1612878318.148724     0 -  obj.http.X-Req-URL == /2021/02/09/booster-son-wordpress-avec-varnish/
1612878297.553181     0 C  
1612878289.407936     0 C  
1612878281.014556     0 C  
1612878237.731221     0 C  
1612864182.318939    44 C  
varnish> quit
500        
Closing CLI connection
$

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 :

$ curl -s -D - "https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/" -o /dev/null
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 09 Feb 2021 13:59:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Age: 0
X-Cache: MISS
Accept-Ranges: bytes
$ curl -s -D - "https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/" -o /dev/null
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 09 Feb 2021 14:03:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 32894
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: sameorigin
Age: 245
X-Cache: HIT
Accept-Ranges: bytes
$

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 :

$ curl -D - -X PURGE "https://alain.arditi.fr/2021/02/09/booster-son-wordpress-avec-varnish/"   
HTTP/1.1 405 This IP is not allowed.
Server: nginx
Date: Tue, 09 Feb 2021 14:11:14 GMT
Content-Length: 0
Connection: keep-alive
X-Varnish: 360523
$

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 :

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

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 :

    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 lance une requête après le vidage du cache :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null -s "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
Age: 0
X-Cache: MISS
Accept-Ranges: bytes
Transfer-Encoding: chunked
Connection: keep-alive
       time_connect:  0.001480
 time_starttransfer:  0.030051
                    ----------
         time_total:  0.030324
$

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 :

$ curl -s -D - -w "@curl-format.txt" -o /dev/null -s "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
Age: 3
X-Cache: HIT
Accept-Ranges: bytes
Content-Length: 30108
Connection: keep-alive
        time_connect:  0.001529
  time_starttransfer:  0.002299
                    ----------
         time_total:  0.002713
$

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

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

L’article Booster son WordPress avec Varnish 1/4 est apparu en premier sur Alain ARDITI's blog.

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.

L’article Booster son WordPress avec Varnish 2/4 est apparu en premier sur Alain ARDITI's blog.

On lance 40 threads JMeter sur le site en SSL avec Nginx, mais cette fois avec le cache Varnish et avec le plugin de cache WordPress WP Fastest Cache.
Les résultats bruts de JMeter : nombre de requêtes 482 789, 0% d’erreur.

La légende des abscisses indique le jour 09 (Février) suivi de l’heure.
Les 40 threads sont atteints à 23h35. 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.

Il faut noter l’amélioration du maximum. Dans le scénario sans Varnish on arrive à 170 requêtes/s, ici on monte à 220 requêtes/s.

Apache traite cent fois moins de requête avec Varnish. En fait dans le scénario, il y a une requête dynamique dans le scénario et qui ne peut pas être cachée par Varnish. Elle est toujours passée à Apache. On note également sur les deux graphes précédents, mais on retrouvera ce comportement sur tous les graphes suivants, qu’on bien un plateau identique au plateau de nombre de threads. Contrairement au scénario 1, sans Varnish où la VM ne suit plus les thread de l’injecteur JMeter une fois au maximum. Ce qui confirme la saturation de la VM dans le scénario 1.

La charge de la VM n’est pas significative, il ne faut pas tenir compte des petites variations qui sont sous la valeur 0,2.

Les valeurs sont tellement faibles que ce graphe n’est pas significatif. Ici on a des millièmes de requêtes par seconde.

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.

La latence ne varie quasiment pas avec la charge. Il n’y a pas de saturation. On note également une diminution de la latence par un facteur 10 au moins. On voit la capacité de Varnish à cracher du HTTP !

Même constat, les temps de réponse sont exceptionnels et ne varient pas. Sauf pour la courbe violette correspond à une page qui pèse 10 fois plus que les autres.

Trois conclusions à tirer de ce deuxième test :

1. Les latences et les temps de réponse sont exceptionnels
2. Le nombre de requêtes fournies par seconde augmente de 30%, parce que les pages sont servies plus vite.
3. A 40 threads, la VM n’est pas saturée, contrairement au test précédent qui avait atteint les limites. Les graphes JMeter et Munin suivent le graphe des threads !

On va doit pouvoir pousser le test à 80 threads

L’article Booster son WordPress avec Varnish 3/4 est apparu en premier sur Alain ARDITI's blog.

On lance 80 threads JMeter sur le site en SSL avec Nginx, avec le cache Varnish et avec le plugin de cache WordPress WP Fastest Cache afin d’essayer de trouver la limite de la VM WordPress.
Les résultats bruts de JMeter : nombre de requêtes 935 664 avec 7% d’erreur.

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

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.

Il faut noter l’amélioration du maximum. On est à 360 requêtes/s ce qui prouve que la VM avec encore des ressources. On a augmenté de plus de 60% pour une augmentation de 100% du nombre de threads. Ce qui indique qu’il y a probablement une contention, sinon on aurait aussi fait 100% de requêtes/s en plus !

Apache ne fait rien ou presque.

La charge de la VM n’est pas significative, il ne faut pas tenir compte des petites variations.

L’utilisation de la CPU a doublé et passe à 20%, ce qui reste faible. Ce n’est pas en calcul que la VM est limitée.

Là aussi, on a un « joli » graphe mais pas significatif. MySQL ne fait rien.

On voit la contention !!! Le maximum de débit réseau est atteint à 8h20, alors que les 80 threads sont atteints à 8h27. Ce plateau montre que la VM n’arrive pas à produire plus de pages que lorsqu’elle est soumise à 65 threads.

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.

La latence ne varie pas jusqu’à 8h20 puis elle se disperse. En fait lorsque la machine est saturée, comme on atteint une limite de débit, les latences s’allongent.

Même constat, les temps de réponse s’allongent à partir de 8h20.

Et le débit ne suit pas les threads…..

Conclusions à tirer de ce troisième test :

1. On a réussi à saturer la VM vers 65 threads.
2. La contention apparaît au niveau du réseau. La VM n’arrive pas à fournir plus de 15 Mbps.
3. Au delà de 65 threads, la VM répond, mais les temps de réponse s’allongent et elle produit des erreurs.

L’article Booster son WordPress avec Varnish 4/4 est apparu en premier sur Alain ARDITI's blog.