vendredi 17 avril 2020

Test de performance et série chaotique, des points communs ?

Quels points communs entre les séries chaotiques et les tests de performance ?



Petite définition des séries dites "chaotiques" :

Les séries dites chaotiques font partie en physique de l'ensemble des systèmes dynamiques eux-mêmes pouvant être classés parmi les séries temporelles.

Ce qui différencie les séries chaotiques des autres systèmes dynamiques, ce sont :
  • une sensibilité aux conditions initiales (pouvant en entraîner des différences très marquées lorsque la série évolue dans le temps ensuite)
  • un certain déterminisme (contrairement à ce que le nom "chaotique" semble suggérer, si on connait les conditions initiales, son évolution dans le temps est prévisible ensuite) 
  • une forte récurrence

Quel est le lien avec les tests de performance ?

Il y a un tout un pan primordial des tests de performance auquel peu de gens font attention et qui pourtant fait toute la différence entre un bon test et un test impossible à reproduire.

Il s'agit bien sûr des conditions initiales du test de performances:
  • Quelle est l'architecture utilisée ? Est-t-elle iso-prod ?
  • Quels matériels physiques sont utilisés (version du CPU, taille mémoire, type de disque dur, type de carte réseau utilisée..) ?
  • Quels logiciels sont utilisés ? (L'OS est-il virtualisé ou "dockerisé" ?), Quel est l'OS et sa version précise (n° de patch), quel est l'antivirus et sa politique de scan temps réel ?
  • Quels middleware sont installés (leur version précise) ? 
Ensuite viennent d'autres questions concernant l'application et son backend :
  • Quelle est la version exacte de l'application ? de ces paramétrages techniques (pool vers la base de données, ou pool de thread http...) Est-on bien en mode ERROR dans les logs ?
  • La base de données a-t-elle bien une volumétrie représentative de celle prévue en production ? En effet, combien de tests de performance sont fait avec une base quasiment vide ? La base (si relationnelle) a-t-elle eu un re-calcul de ses statistiques pour améliorer la performance de l'optimiseur des requêtes? 
Autres éléments qui concourent aux conditions initiales:
  • Des sondes OS et/ou JVM sont-elles en place avec le risque de léger overhead que cela présente ? Des APM de type DynaTrace sont-ils démarrés sur le Front et le backend ?
  • Quel est l'outil de test de performance ?  Pareil quelle version , quel paramétrage et plugins éventuels ?
  • Quel est la version du script d'injection ? A-t-on versionné toutes les variantes du script d'injection avec notamment : la durée de montée en charge, la durée du plateau, le nombre de VUser, le comportement en cas d'erreur, le temps d'attente (thinkTime) min/max, etc...

Autre élément: le déterminisme.

En effet, connaissant le nombre de VUsers lors de la montée en charge, la même application va réagir de la même façon (les conditions initiales), les temps de réponse seront normalement identiques pour le même tir avec exactement les mêmes paramètres.

Et justement, comme toute expérimentation scientifique, chaque tir de performance devrait suffisamment bien documenter ses conditions initiales pour qu'une éventuelle seconde équipe de contre-expertise de test de performance puissent reproduire le même comportement dans les mêmes conditions.  J'ai déjà eu à jouer ce rôle où sur un projet sensible, c'est même 3 équipes différentes qui ont fait ce travail de contre-expertise pour valider le résultat obtenu par une première équipe.

Un exemple dans le domaine de tests hardware

Lorsqu'un composant hardware est testé, les magazines de tests vont en général décrire rapidement les autres composants de l'ordinateur et les logiciels utilisés.

Mais certains font l'impasse dessus, exemple ici pour un test de carte 3D avec un modèle RTX 2070 de NVIDIA (je n'ai pas de sponsor) :
  • Chez les numériques : très peu de détails quand au protocole de test (on sait juste que le boîtier est fermé lorsqu'ils testent la chaleur dégagée pour la carte)
  • Chez Tom's Hardware, moins de détail, mais il existe un dossier dédié décrivant comment le site teste des cartes 3D
  • Chez Comptoir-Hardware, il y a une page dédiée au protocole de test très complète.
Juste à travers ces 3 exemples et pour rejoindre le fait que faire des tests depuis des années ne garantit pas de faire de bons tests, cela illustre bien que décrire comment on fait le test (et avec quelles conditions initiales) est aussi important que le résultat du stress applicatif effectué par l'outil de test de performance.

Conclusion

J'espère que ce long article vous a convaincu de mieux documenter ce qui se passe au début de vos tirs de performance et ne pas se contenter juste du résultat qui (je ne le répéterais jamais assez) ne peut se résumer à la moyenne.
Il faut rédiger 2 documents :
  1. un résumé compréhensible par tout le monde 
  2. et un document plus détaillé (pour nos pairs) en cas où une contre-expertise de performance serait demandée.

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.