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.