Les marches d’escalier quand elles sont suffisamment longues par rapport à la fréquence des prises de mesures du côté de l’infrastructure, permettent de faire une corrélation directe entre la charge et le comportement de la plateforme. En effet, la plateforme va consommer des ressources en fonction de l’injection et on pourra visualiser les marches d’escalier du côté des graphiques de l’infrastructure.

A condition que la durée des marches, ou plus précisément la durée des paliers, permette d’avoir suffisamment de points de mesure côté infrastructure. Si la fréquence de la métrologie est de 5 minutes, par exemple, qui est la valeur courante des logiciels de métrologie, il faut au moins des paliers de 15 à 20 minutes pour avoir 3 à 4 mesures et visualiser ainsi le palier.

Dans l’exemple suivant, on peut voir l’utilisation du plugin “Concurrency Thread Group” avec des paliers de 20 minutes.

Du côté de l’infrastructure, sur le graphe du débit réseau on retrouve les paliers :

On peut ainsi faire la correspondance entre le nombre de threads et la charge de la plateforme.

On peut dire qu’à 60 threads, au 3^ème palier, le débit de la plateforme est de 60 Mbps et qu’au 8^ème et dernier palier, à 150 threads, le débit est de 150Mbps.

Même si les paliers de la métrologie ne sont pas plats, on retrouve bien l’évolution de l’injecteur, et dans ce cas précis, on peut même conclure sans trop se tromper que le débit augmente de 1 Mbps par thread.

Par contre, on n’en déduit pas facilement le nombre de parcours ou de sessions simultanées à chaque palier.

Un moyen assez simple d’extrapoler les résultats pour avoir des métriques marketing, est de spécifier des valeurs judicieuses dans le plugin “Concurrency Thread Group”, comme on va le voir dans le graphique ci-dessous :

Ici, on a des marches d’escalier de 20 minutes avec 20 threads supplémentaires à chaque marche. On remarque que les surfaces sous les marches augmentent d’une unité de surface (4 carreaux) par marche.

Ainsi la surface sous la dernière marche vaut 5 fois la surface sous la première marche.

Comme les threads travaillent de manière uniforme, on peut en déduire que s’ils parcourent n scénarios pendant les 20 première minutes, c’est à dire pendant la première marche, ils en parcourent 5 fois plus lorsque JMeter atteint les 100 threads, c’est à dire à la dernière marche.

Comme JMeter fournit le nombre total de scénarios qu’il a exécutés à la fin du tir, en détaillant le nombre d’exécution par URL, on peut en déduire facilement le nombre de visites.

Pour connaître le nombre de scénarios exécutés pendant les 20 premières minutes, on part de l’hypothèse que nombre de scénarios est proportionnel à la surface sous les marches.

La surface totale de l’escalier de 5 marches, qu’on appellera S_tot, est de 1+2+3+4+5 = 5×6/2 = 15. Donc S_tot = 15.

Si le nombre total de scénarios exécutés par JMeter, donc le nombre de visites, est V_tot, alors pendant les 20 premières minutes (durée de la première marche), JMeter a exécuté  V_tot / S_tot visites.

Et pendant les 20 dernières minutes, à la 5^ème marche, il aura exécuté (V_tot / S_tot * 5) visites, puisque la surface sous la 5eme marche est 5 fois plus grande que la surface de la première.

En prenant les usages du Web qui comptabilisent les sessions comme toute visite après 30 minutes d’inactivité, si on extrapole le nombre de visites du dernier palier de 20 minutes à 30 minutes, on obtient (V_tot / S_tot * 5) * 3/2 sessions simultanées lorsqu’on atteint 100 threads.

On voit que ce calcul s’applique quel que soit le nombre de threads et la durée des paliers, sur la base des éléments fournis par JMeter, et se fait de manière simple, pour peu qu’on choisisse bien les paramètres du plugin “Concurrency Thread Group”.

En faisant la corrélation avec les graphes de l’infrastructure, on peut en déduire facilement le nombre de sessions simultanées qu’elle peut supporter !

Une fois qu’on connaît le nombre de sessions simultanées, on peut extrapoler les nombre de visite à l’heure, puis par jour et enfin le nombre de visites mensuelles, en jetant un oeil sur l’article : Test de charge : Comment extrapoler le nombre de visites ?

L’article Tests de charge : le plugin jp@gc Concurrency Thread Group est apparu en premier sur Alain ARDITI's blog.

On va s’intéresser à l’audience d’un site de commerce en ligne. Avant de passer une commande sur un site de commerce en ligne, un internaute va peut-être passer 20 minutes à naviguer sur le site pour parcourir le catalogue et remplir son panier. Ensuite, il va passer la commande, créer son compte, saisir son adresse de livraison, effectuer le paiement, et éventuellement vérifier sa commande sur le site. Il aura passé 30 minutes sur le site.

Afin de simuler l’audience, nous utilisons l’outil JMeter (https://jmeter.apache.org).

Si on veut simuler une audience équivalente à 600 commandes à l’heure, il faudra lancer notre scénario 600 fois en une heure. Comme il dure 30 minutes, il faudra lancer 300 threads en parallèle qui vont chacun effectuer 2 scénarios. On aura bien nos 600 commandes en une heure, sauf qu’on imagine que les passages de commande vont se trouver plutôt à la fin des 30 minutes, on aura donc un biais par rapport à la réalité.

Si on veut supprimer ce biais, il faudrait que l’injecteur soit dans un rythme de croisière nominal, avant la prise des mesures, afin que les aléas temporels du scénario permettent de distribuer les commandes. Ca veut dire, qu’il faudra lancer les 300 threads quelques heures auparavant et au moins 30 minutes après l’heure de mesure.

Et si le site de commerce en ligne à un taux de conversion de 5%, c’est à dire le nombre de visiteurs qui vont passer une commande, il faut multiplier par 20 le nombre de scénarios exécutés par l’injecteur, sachant que 95% pourcents d’entre eux ne doivent pas passer de commande. En conservant des scénarios de 30 minutes, il faudra 6000 threads pour simuler l’audience et faire durer le test un bon paquet d’heures….

Bref, dans ces conditions, la simulation de la réalité devient très difficile en pratique, car la durée des tests est prohibitive !

Afin de permettre la réalisation des tests dans des durées acceptables, on va raccourcir la durée du parcours d’un visiteur.

On va faire la supposition que lancer 300 threads qui jouent un scénario de 30 minutes pendant 1 heure, c’est équivalent pour le site qui reçoit les visites à 30 threads qui jouent un scénario de 3 minutes pendant 1 heure.

Dans les 2 cas, on aura exécuté 600 scénarios en 1 heure. Le site aura répondu aux mêmes sollicitations sauf que dans le deuxième cas, le rythme de croisière sera atteint dix fois plus rapidement, facilitant du même coup la réalisation du test qui pourra durer 10 fois moins longtemps !

Si finalement, le scénario est accéléré pour durer 30 secondes, avec un enchaînement de 20 à 40 requêtes HTTP et des aléas temporels de quelques centaines de millisecondes entre les requêtes, on obtient l’équivalent de la charge précédente avec 5 threads pendant 30 secondes.

Si on fait durer ce dernier test 10 minutes, chaque thread aura fait 20 boucles. On n’est pas loin d’un rythme de croisière avec suffisamment d’aléa pour le considérer comme représentatif d’une audience de 600 commandes à l’heure.

Une manière simple de créer des tirs sur JMeter simulant une charge données est d’utiliser les paramètres “Number of Threads” et “Ramp-up period” dans l’objet “Thread Group”  

Dans l’exemple ci dessous :

les 30 threads seront atteint après une période de 20 minutes, pendant laquelle, JMeter va graduellement augmenter le nombre de threads pour passer de 1 à 30, puis il va continuer avec ce nombre de threads pendant 10 minutes, jusqu’à l’arrêt du test.

Le graphique du nombre de threads en fonction du temps est le suivant :

On peut remarquer que si la durée du “Ramp-up” fait les ⅔ de la durée totale, alors les surfaces A et B ci-dessous sont égales :

Si le nombre de conversion réalisées par JMeter pendant toute la durée du tir vaut N, alors, le nombre de conversions effectuées pendant la période nominale, ici, les 10 dernières minutes, vaut la moitié, soit N/2.

On peut dire que le nombre de conversions à l’heure vaut N/2×6, soit 3N conversions à l’heure.

Si les statistiques de la boutique indiquent un taux de conversion de 5%, alors, en ajoutant des scénarios sans conversion et en multipliant le nombre de threads par 20, on simulerait l’audience de la boutique.

Pour calculer l’audience équivalente au tir ci-dessus, on peut dire qu’on a 3Nx20 visiteurs à l’heure. Comme une session dans les usages du Web est comptabilisée après 30 minutes d’inactivité, on peut dire qu’on a un équivalent de 2x3Nx20 sessions simultanées.

Comment estimer le trafic quotidien et mensuel ?

La réponse dépend largement du type du site et des habitudes de fréquentation.

On peut se lancer dans un calcul à la louche, sachant qu’on obtient des ordres de grandeur et qu’il faut adapter le calcul en fonction des statistiques du site.

Si on estime que l’heure du pic d’affluence représente 20% du trafic de la journée, dans notre cas 3Nx20 visiteurs, pour la journée on en aurait 5 fois plus, soit Nx300 visites par jour.

Reste à extrapoler au mois. Si on considère que le jour le plus chargé représente 10% des visites du mois, on aurait Nx3000 visites par mois !

Si N vaut 100, notre tir produirait une charge équivalente à :

• 300 commandes à l’heure,
• 30 000 visites par jour,
• 300 000 visites par mois.

L’article Test de charge : Comment extrapoler le nombre de visites ? est apparu en premier sur Alain ARDITI's blog.

Il y a deux objectifs dans ma démarche :

1. améliorer les sites de nos clients. Les tests de charge permettent d’apprécier le comportement d’un site lors de fortes audiences et de détecter les éventuelles contentions.
2. développer la maîtrise du Web chez les développeurs. A travers la mise au point des scénarios, on apprend comment un navigateur dialogue avec un site Web. C’est une brique essentielle dans la fabrication des sites Web.

Un sujet récurrent depuis le début du Web

On connaît tous l’importance des temps de réponse et les problématiques d’audience des sites Web.

En 1996, lorsque j’ai travaillé sur le premier site Web bancaire français, j’ai mis au point mon premier outil de test car il n’y avait aucun produit pour accomplir cette tâche. J’ai utilisé l’inoxydable Telnet pour simuler des connexions, des scénarios et des tests de charge !

A cette époque, Telnet sur HP-UX permettait d’injecter des requêtes HTTP avec un pipe.

Ca donnait des commandes de ce type :

$ echo -n “GET / HTTP/1.0\n\n” | telnet tohero.fr 80
Trying 92.222.234.216...
Connected to tohero.fr.
Escape character is '^]'.
HTTP/1.1 301 Moved Permanently
Server: nginx/1.10.3 (Ubuntu)
Date: Mon, 12 Jul 2021 09:19:03 GMT
Content-Type: text/html
Content-Length: 194
Connection: close
Location: https://www.tohero.fr/actualites

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.10.3 (Ubuntu)</center>
</body>
</html>
Connection closed by foreign host.
$

Grâce à la simplicité du protocole HTTP, ça devenait (plus ou moins) facile d’injecter des requêtes POST, de stocker des cookies et de jouer un scénario avec des Shell scripts. C’est ainsi que j’ai commencé les tests de charge sur le site que j’étais en train de construire.  J’avais baptisé ce petit programme de tests “Gator”. On s’en servait également pour les tests systèmes, fonctionnels de bout en bout. On avait déjà un ancêtre de Sélénium pour les recettes.

Malheureusement, la grande majorité des “Telnet” ne supportaient pas le pipe. J’ai donc réécrit Gator en Perl, ce qui a donné naissance à gator.pl

Cette fois le script Perl était bien plus évolué et prenait en entrée des scénarios de test sous forme de fichiers.

Au début des années 2000, on n’envoyait pas beaucoup d’informations dans les headers et le JavaScript ne posait pas trop de problèmes. On était capable de créer nos tests sans sniffer le trafic Web, uniquement avec la connaissance des pages à tester.

Néanmoins, la mise au point de ce type de tests n’était  possible que par les développeurs. Et les années passant, je me suis dit que les scripts Perl étaient trop compliqués à maintenir et je me suis tourné vers un produit. Comme à l’époque je programmais en Java et j’utilisais Tomcat comme serveur applicatif, je me suis naturellement tourné vers Jakarta JMeter, qui faisait partie de la même suite logicielle que Tomcat, pour faire les tests de charge.

Les RFC

L’intérêt de travailler sur la mise au point des scénarios de tests de charge est de comprendre le dialogue entre un client (navigateur) et un serveur Web. Ce dialogue a été formalisé pour la première fois dans un « Request For Comment », la RFC 1945 écrite en partie par Tim Berners Lee qui détaille le protocole HTTP. Par la suite d’autres RFC , comme la RFC 2068 ont complété cette documentation au fur et à mesure que le protocole s’est enrichi. Depuis, il y a eu bien d’autres RFC qui illustrent la complexité du dialogue entre le client Web et le serveur.

Depuis quelques années, cette communication est au cœur de l’optimisation de l’expérience client. Tout le monde s’y intéresse et des logiciels comme Google PageSpeed qui font aujourd’hui le bonheur des agences digitales, décortiquent en détail cette communication. On parle ici des performances d’un site.

Les tests de charge supposent idéalement que le site est déjà performant. On constate en pratique qu’un site performant supporte mieux la charge qu’un site peu performant. Ça veut dire que les équipes qui ont travaillé sur le projet étaient déjà sensibles à la performance.

Pour autant les tests de charges vont permettre de trouver des optimisations liées aux pics d’audience. C’est leur objectif premier, mais on peut trouver bien d’autres contentions ou imperfections avec ce type de tests !

L’article Tests de charge : Un peu d’histoire est apparu en premier sur Alain ARDITI's blog.

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.

Pour ce faire, on va utiliser les assertions. On va chercher une chaîne de caractères pour vérifier qu’on a bien créé un article.

On va simplement chercher le titre de l’article. Comme il y a une variable dans le titre : l’identifiant de l’article, on est certain que si on retrouve ce titre c’est bien l’article qu’on vient de créer !

On écrit le titre et le texte de l’article dans la requête /wp-json/wp/v2/posts/id_article?_locale=user. Ici on a même mis l’id_article dans le texte du titre.

On peut vérifier le titre de l’article sur la page qui affiche l’article : /permalien/titre-du-nouvel-article/ et rechercher la chaîne de caractères :
<h1 class="entry-title">Titre du nouvel article ${id_article}</h1>

La mise en place d’assertions est une bonne pratique. Néanmoins, il ne faut pas en abuser, car l’évolutivité de notre scénario et sa résistance au changement de version du site va se réduire.

Voici un rapide aperçu de la création de scénario. C’est une des parties du test de charge, la suite consistant effectivement à lancer les scénarios pour étudier le comportement du site grace à la métrologie et à tous les indicateurs qui pourraient donner des indices.

Références :
Les assertions dans JMeter

L’article Les tests de charge avec JMeter : les assertions 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.