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.