Tests de charge : le plugin jp@gc Concurrency Thread Group

Lors de tests de charge avec JMeter, il est courant d’utiliser le plugin jp@gc Concurrency Thread Group (https://jmeter-plugins.org/wiki/ConcurrencyThreadGroup/), qui permet de faire monter la charge par marche d’escalier.

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 ?