dimanche 8 mars 2020

Comment rater professionnellement ses tests de performance ?

Comment rater ses tests de performance malgré un professionnalisme avéré ?

Les tests de performances applicatifs sont une activité très complexe où chaque détail peut compter. La moindre négligence dans certaines étapes peut mettre à mal la meilleure volonté de bien réaliser les tests et aussi de produire un rapport factuel.

Résumé grossièrement, que fait-on lors d'un test de performance ?


On stresse une application pour voir comment elle réagit lorsque celle-ci est fortement ou longuement sollicitée sur des scénarios établis par la maîtrise d'oeuvre (MOE). En général, on vérifie aussi les ressources consommées (CPU, RAM, I/O) par l'application lors de ces stress.

Il y a 5 problèmes insolvables (et à accepter) lors des campagnes:

  1. On ne peut tester 100% des usages, on doit cibler certains scénarios fonctionnels (ou ceux qui sont techniquement complexes)
  2. Parmi les scénarios choisis, ceux-ci sont rejoués automatiquement. La qualité de cette pseudo automatisation peut varier selon l'équipe et l'outil dédié aux tests de performances (variabilisation, temps d'attente, détection de mots clés dans les réponses serveur, ...)
  3. Les tests sont réalisés sur une plate-forme qui ne sera jamais équivalente à celle de production
  4. Le temps total perçu côté du client (depuis son navigateur) est rarement pris en compte intégralement (les applications Front de type SPA ont une latence lié à Javascript, au accès DOM, au garbage collector du navigateur)
  5. Loi de Murphy oblige, même avec une campagne de tests de performances "parfaite",  des aléas peuvent survenir le jour de la mise en prod et/ou de l'exploitation avec le nombre d'utilisateur nominal de l'application.


Exemple des tests de performance sur les cartes 3D et jeux vidéos :

Pour se convaincre qu'on peut professionnellement faire très sérieusement des tests qui ne servent pas à grand chose, voici un domaine que certains d'entre vous doivent connaître depuis des années, les tests de carte 3D sur les jeux vidéo pour choisir entre tel ou tel autre modèle de NVIDIA ou AMD/ATI.

L'idée ici n'est pas de tester une application mais une carte 3D mais les principes restent les mêmes :

  1. Stresser le composant (ici avec des jeux 3D)
  2. Mesurer ses performances (on parle malheureusement trop de moyenne qui n'est pas un bon indicateur)
  3. Mesurer la consommation de ressources (pour les cartes 3D, on s’intéressera en autre aux Watts et au bruit) 
  4. Faire un rapport pour résumer tout ça pour un public pas forcément technique en donnant une conclusion voire des axes d'améliorations

Le test de carte graphique 3D est établi depuis leur toute première apparition en 1996.  Les sites Web  et magazines de guide d'achat et de comparatif de matériel informatique font ça depuis de nombreuses années.

Cependant, le seul est unique indicateur souvent utilisé est (et reste pour la plupart d'entre eux) la MOYENNE.   Cet indicateur pour un statisticien n'est pas un indicateur fiable et ne devrait pas être utilisé lors de comparaison (pas sans tests statistiques de type ANOVA [pour vérifier si la moyenne de chaque échantillon peut potentiellement issues de la même loi] et sans évoquer les intervalles de confiance).

Voici les sites web qui n'utilisent QUE la moyenne pour tester les cartes 3D et quelques exemples :

Finalement, le seul site à faire différemment des autres et depuis 2012, c'est Tom's Hardware.
Que nous raconte ce test de 2012 ? https://www.tomshardware.fr/les-performances-de-far-cry-3/6/
Test Tom's Hardware datant de 2012

Que voit-on ?  Dans chaque jeu, si celui-ci ne dispose pas d'un benchmark intégré permettant de rejouer automatiquement la même séquence, un déplacement "à la main" est effectué par le testeur dans le jeu pendant que des sondes enregistrent le comportement de la carte 3D durant cette séquence temporelle.

Il y a donc des hauts et des bas dans le nombre d'image par seconde durant chaque scénario enregistré. Le taux d'image par seconde est rarement constant. C'est aussi le cas lors d'un tir de performance sur une application.

Toujours sur cette image, on voit en pointillé orange que le CrossFire d'ATI Radeon HD 7870 a une variation très importante de son nombre d'image par seconde.  Parler de moyenne ici ne reflétera pas la réalité.  Ça va résumer grossièrement.

Dès 2012, Tom's Hardware propose une autre valeur que la moyenne (en plus de montrer la courbe temporelle liée au scénario enregistré) : La valeur minimum, en effet, malgré ses variations, qu'elle est la valeur minimum que je pourrais avoir sur tel jeu avec quelle carte 3D ? 
Tests Tom's Hardware indiquant dès 2012 moyenne et minimum

Tom's hardware a continué à explorer ces autres aspects non liés à la "pure" moyenne:
Dès 2016, ils parlent de temps de création de chaque image (Frame Time):
Test Tom's Hardware indiquant le temps de fabrication de chaque image selon la carte 3D

Ils introduisent aussi la notion de variance entre chaque frame :


Dès 2018, ils introduisent la notion de centile :
Ici, pour rappel, la variation du nombre d'image par seconde selon le temps (et du scénario joué) et de la carte 3D
Ici en plus de la moyenne, on a le 99ème centile indiquant que, durant le scénario joué,  99% du nombre d'images générées par seconde n'ont pas chuté plus bas que cette valeur.  

Ci-contre, les centiles avec un zoom sur la zone 50% (la médiane) jusqu'à 99,9 centile (ou ici le minimum est considéré comme un souci et devient le 100ème centile).  En test de perf applicatif, le maximum sera le 100ème centile.

Ici, un autre indicateur utile en test de perf applicatif, la répartition des temps de réponses sous forme d'histogramme.


Quelle conclusion à travers le prisme des tests de carte 3D ?

Peut-on dire que les autres magazines et sites Web de tests matériels sont moins bons ou moins professionnels que Tom's Hardware dans leurs tests ?  Evidemment NON !
Cependant, les tests effectués de la manière la plus professionnelle peuvent parfois être partiellement utiles.

Stresser une carte 3D comme une application ne peut pas se résumer au seul chiffre d'une moyenne.
Chaque scénario de test raconte une histoire qui peut être perçue plus fidèlement avec d'autres éléments que la moyenne: 
  • le nombre de scénario exécutés réussis et en échec
  • le graphique temporel des temps de réponse
  • la répartition des temps de réponse sous forme d'histogramme
  • les bornes minimum et maximum ainsi que la médiane (50% des effectifs triés)
  • les centiles
 Ceci est le premier article sur la performance applicative, l'idée est de montrer que l'expérience de plusieurs années dans un domaine ne suffit pas 

Aucun commentaire:

Enregistrer un commentaire