• Arnaud Mauduit

KPI : les clés du test de performance pour un passage en prod réussi - La conception


Quelle est la formule magique pour réussir sa mise en production ?


Chacun peut avoir son approche et donner ses clés ; un responsable d’infra dira que c’est d’avoir bien respecté le DAT et d’avoir préparé ses fiches d’exploitation, un expert fonctionnel dira que c’est d’avoir bien couvert tous les périmètres fonctionnels, et un développeur dira que c’est de lui avoir laissé suffisamment de temps pour faire un beau code.


Mais que dit le Bencheur ? Cet animal étrange qui réalise des tests de performance toute l’année, quels sont ses critères, ses jalons et ses éléments de go-nogo au passage en production ?


Est-ce que ces éléments sont pris en compte par les responsables du projet pour leur ouverture de service ?


Car il est facile de ne pas se préoccuper des benchs et d’attendre que sa prod s’écroule à l’ouverture de service.


Alors comment un expert en performance garantit-il que tout cela n’arrivera pas et que l’application tiendra la charge ?


Tout d’abord il faut connaitre l’objectif à atteindre : en nombre d’utilisateur tout d’abord, mais aussi et surtout en rythme transactionnel, ou pour faire le lien entre les deux il y a un énorme travail à faire. Beaucoup de questions à poser et de réponses à mettre en perspectives pour lier le futur utilisateur à la capacité des machines.


Voici une liste de question en vrac, si vous pouvez y répondre vous avez à moitié réussi :

  • Qu’est-ce que vont faire les utilisateurs ? Quelles transactions ? Quel temps de pause entre deux pages ?

  • Comment transformer ses statistiques en scenarii de test ? Et mettre des chiffres d’activité globaux en face ?

  • Quelles fonctions devons-nous vraiment utiliser pour solliciter le serveur en bench ? Quelles sont les transactions métiers et critiques, et quelles sont les transactions moins importantes ?

Il existe bien évidemment d’autres questions mais celles-ci nous permettent de modéliser le modèle de charge, le modèle le plus proche de ce qui va réellement se passer dans une machine durant une période de forte charge. Alors voici quelques indices pour aller plus vite :

  • 20% des fonctionnalités réalisent 80% des transactions qui vont être traitées par le serveur

  • Il est inutile de tester tous les cas fonctionnels pour une même fonction

  • Le but d’un bench est de trouver les transactions longues et consommatrices, par conséquent : une fonction qui a déjà des temps de réponse catastrophiques unitairement doit être optimisée avant d’être benchée

Nous avons maintenant un modèle de charge, ne reste plus qu’à réaliser des tests et garantir que l’application tient le choc.


Avant cela, il faut définir les temps de réponses acceptables, exemple :

  • Page simple : 1s

  • Recherche : 5s

  • Démarrage d’un service ou d’un batch : 10s

Ensuite il nous faut réaliser les scripts qui vont jouer cette charge, ceux-ci ont été définis suivant les scenarii de tests pré-cités. Là, nous sommes en face d’une autre problématique : avoir des jeux d’essai suffisamment réalistes et variés (variés pour taper partout dans les bases et surtout ne pas trop vivre sur les caches).


Alors avons-nous toutes les clés d’une campagne de tests de performance réussie :

  • Les transactions les plus utilisées

  • Leur rythme

  • Les temps de réponses attendus

  • Des jeux d’essai représentatifs

Tous ces éléments sont préparés lors de la phase de conception et toutes les clés de la validation sont aussi dans cette phase.


La suite est évidente, il faut lancer les tirs, dérouler toute la campagne et faire chauffer les serveurs.

Mais ceci fait l’objet de l’article suivant.


Scène post générique : dans notre prochain épisode, vous verrez comment les bencheurs réalisent une campagne, jonglent entre les configs usines, les scripts à renforcer, les rapports à expliquer et surtout comment ils trouvent la vérité dans ce spaghetti technologique.

47 vues

Posts récents

Voir tout