vendredi 10 avril 2020

Test de performance : Quand le meilleur outil ne suffit pas

LoadRunner, la "Rolls Royce" des outils de tests de performance n'aide pas à faire de bons rapports

LoadRunner est considéré dans la "profession" de testeurs de performance comme la Rolls Royce des outils de stress applicatif.  Multi-protocole, multiples sondes intégrées, création de script et de rapport simplifiée, fonctionnalités avancées et prix exorbitant; ne pas connaître LoadRunner est une gageure en test de performance.

La qualité des rapports de LoadRunner

Malgré toutes ses qualités, son défaut majeur qui est le prix de sa licence.
En outre, très clairement, LoadRunner n'est pas fait par des statisticiens et ça se voit...

Exemple de tableau "typique" généré automatiquement par LoadRunner (le tableau est orienté pour mettre en avant la moyenne alors que le 90è centile est beaucoup plus intéressant à suivre ainsi que le nombre de tir effectué et la valeur max)


Exemple de graphique "typique" généré par LoadRunner.  Avec un bas un tableau où les min/max et la médiane (50ème centile) sont les seules informations utiles, le focus reste sur la moyenne et son écart-type.

Mais alors que manque-t-il à ces rapports de tirs de performances ?

En bien, une vision "statisticienne" de l'histoire que le tir de performance raconte et qui NE PEUT PAS se résumer à un simple chiffre: la moyenne.

On va d'abord s'intéresser aux chiffres suivants :
  • Nombre total de chaque scénario joué sur la période. Cela permettra de déterminer combien de scénario passent en dessous ou au-dessus des centiles.
  • avec aussi le nombre ou pourcentage d'échecs
  • et bien sûr le nombre de VUsers demandés

Un peu de statistique descriptive:

En statistique, pour décrire la distribution des diverses observations d'un échantillon (où on sous-entend que les données étudiées sont le sous-ensemble appartenant à une loi statique plus globale), on va utiliser plusieurs métriques "classiques":
le minimum, la moyenne, l'écart-type (ou la variance), le mode, la médiane le maximum, l'étendue
On peut aussi utiliser les quartiles jusqu'aux centiles.

Graphiquement, on va pouvoir utiliser des histogrammes et courbes de répartition pour montrer de 2 façons différentes la répartition des temps de réponse et idéalement que sur la période du plateau après la montée en charge progressive en terme de "virtual user" (vusers).
Histogramme montrant la répartition des temps de réponse durant la durée du test de performance


Courbe représentant les temps de réponse triés sur l'axe Y des centiles (du 1er centile au 100è) et sur l'axe des X les temps de réponse correspondant.
Une courbe avec les centiles est utile, en connaissant le nombre de scénarios en succès total (dans cet exemple 800), on peut déterminer combien de tirs ont dépassé les 1000ms.
ICI, 67,25% des tirs sont en dessous des 1000ms.
Mais cela veut dire aussi que 100-67,25=32,75% des tirs dépassent 1 seconde et vont jusqu'au maximum (ici: 200secondes)
En quantité, cela fait 800*32,75% = 200 requêtes qui ont dépassées 1 seconde.
Pour mesurer des SLA (Service Level Agreement) d'un système, on va s'intéresser plus aux centiles qu'à la moyenne.  Au 90ème centile, quel est le temps de réponse le plus grand ? On assure donc que 90% du trafic sur tel scénario sera en dessous d'un certain seuil de temps de réponse.  

Quoi faire pour améliorer le système pour que 95% ou 99% des requêtes passent en dessous d'un certain seuil ? C'est avec les centiles que l'on peut travailler pour savoir gérer le 80/20 (la fameuse loi Pareto) pour se concentrer sur les 20% de problèmes qui pourront augmenter d'un seuil significatif les temps de réponse (optimisation OS, JVM, serveur d'application et applicative notamment au niveau des algorithmes et consommation de ressources).

D'autres graphes et représentations peuvent être utiles mais n'ont pas le même poids que le graphe de temps de réponse par centile:
  • Temps de réponse par nombre de VUsers (utile pour voir à quel moment le système décroche, ex: un pool de thread saturé, une taille mémoire atteinte...)
  • Nombre de transactions par nombre de VUsers

Le meilleur graphe en test de performance :

Le graphique précédent montre le tri des temps de réponse mais on perd la notion temporelle du tir de performance.
Le graphique suivant propose une vision en centile (ou en quartile) à chaque seconde de notre tir de performance, cela suppose bien sûr  pour être exploitable avoir plus de 10 sollicitations par seconde durant le test de performance.
Ce graphique montre les temps de réponse en quartile  et centile durant toute la durée du tir de performance.

Comment comprendre ce graphique et les couleurs ?
  • En terme temporel, la seconde étudiée est 1mn 30sec après le début du test. Les centiles ou quartiles présentés durant cette seconde-là représente de façon triée les meilleures au plus lentes requêtes effectuées durant cette intervalle d'une seconde.
  • 25%  des requêtes les plus rapides (=le 1er quartile) sur cette seconde en cours apparaissent en rouge, car si cette zone rouge est bien visible sur le graphique c'est que les 25% des meilleurs réponses sont déjà lentes. Ici, sur la photo d'exemple, au 25è centile, les temps de réponse vont jusqu'à 259ms.
  • 50% (le 50è centile) correspond à la médiane. On est sur une couleur rouge orangée, notre seuil max correspond à la moitié des sollicitations sur cette seconde en cours. Ici, on est à 284ms.
  • 75% (ou 3ème quartile) apparaît en orange où dans l'exemple sur la photo, les temps de réponse peuvent aller sur cette période analysée jusqu'à 3 005ms.
  • Ainsi de suite sur les suivants mais de moins en moins rouge. 
  • Les derniers centiles 99% et 100% apparaissent en vert (ici à ~146secondes) car le focus est bien de se concentrer sur l'amélioration des zones les plus rouges (que les meilleurs temps de réponse soient eux-mêmes bien performants avant de voir pour traiter les valeurs "aux limites").

D'où proviennent ces graphiques ?

D'un site BlazeMeter proposant d'uploader ces tirs de performances (à anonymiser avant) pour exploiter de façon statistique les tests effectués avec l'outil Open Source Apache JMeter 
Voici une url avec des exemples de rendu : https://sense.blazemeter.com/examples


Conclusion

Comme pour la conduite automobile avoir une Rolls-Royce fait-il de son possesseur un bon conducteur ? Pour paraphraser les inconnus ou plus vieux avec 3 compères : Blondin, Tuco et Sentenza, il y a 2 catégories de testeurs de performances. je vous laisse compléter selon la version des inconnus ou de Sergio Leone.

Avoir un outil hors de prix considéré comme le Nec Plus Ultra ne suffit pas à faire un bon test de performance.  Des outils gratuits comme JMeter et le site BlazeMeter donne un niveau bien meilleur en terme de rapports et graphiques sur l'histoire que raconte le tir de performance.

De plus, des notions de statistique et de pédagogie sont nécessaires pour expliquer et résumer sans parler de moyenne un test de performance.

Attention, j'ai vu qu'il existe une toute nouvelle version 2020 de LoadRunner que je n'ai pas pu tester mais qui j'espère tente de gommer les principaux défauts que je lui ai adressé ici.

A noter que les tests de performances ne peuvent pas être représentatif à 100% de tous les scénarios et usages d'une application, il convient donc, une fois l'application lancée en production, de mesurer également les temps de réponse réels et de calculer les centiles de ces temps de réponse.



Aucun commentaire:

Enregistrer un commentaire