Les tests de performance ont pour but d’observer un comportement (temps de réponse, erreurs) sur une application sous charge. Cette charge est générée par des outils d’injection (donc forcément automatisée) qui reproduisent de l’activité sur l’application.
Les tests de performance permettent d’anticiper des situations de production afin d’apporter un maximum de correction avant que l’application soit disponible aux utilisateurs.
Dès qu’il est possible de générer une activité sur une application, un vaste éventail de possibilité s’ouvre à vous (par exemple):
- En utilisation « classique » (proche de celle de la production), je peux prendre un étalon sur ma version de production et vérifier que le comportement sur ma version n+1 reste identique ou meilleur à sollicitation identique
- Reproduction d’un problème de production
- Le fonctionnement de mon système distribué est-il correct (répartition homogène de la charge sur toutes les instances) ?
- Et si j’ai 4 fois plus de client, le comportement est-il le même ?
- Le comportement applicatif est-il stable dans le temps ?
- Si j’ajoute la fonctionnalité « X » quel va être l’impact sur l’application et pour les clients ?
- Et si je lance une super promo, mon application peut-elle faire face à une activité exceptionnelle, et exceptionnelle jusqu’à quel point ?
- Quel est le principal élément limitant la capacité de monté en charge, et comment puis-je le surveiller efficacement ?
- Afin d’améliorer la gestion de mon activité, je voudrais que mon batch qui passe la nuit et est exécuté à 2h du matin soit maintenant exécuter toutes les heures. Les clients seront-ils impactés par cette évolution ?
- Et si je mets un APM sur mes instances de production, va t’il y avoir un impact sur les utilisateurs ?
- Un SI sans panne, sans intervention et sans crash, ça n’existe pas, mon système est-il tolérant à une panne, deux pannes ?
J’ai des partenaires externes dont je ne maîtrise pas la disponibilité, comment se comporte mon application si celui-ci n’est plus disponible ? Quand le service revient, la reconnexion se fait-elle correctement, sans intervention humaine ? - Je veux valider mon mode opératoire de mise à jour de mon application à chaud, et donc sous charge
- Comment vérifier que le monitoring mis en place en production est bien utile et me donne une vue réaliste de l’état de l’application ?
- …
Quels sont vos objectifs ?
Avant de se lancer dans les tests, il est important d’identifier les objectifs de la campagne de tests de performance.
Qu’attendez-vous de ces tests, quel périmètre et surtout quels risques souhaitez-vous couvrir ?
- Par rapport à votre plateforme de test (environnement), quelle est l’activité à reproduire (cas de test + volumétrie) ? est-ce une estimation ou issue de l’activité de production ?
- Vos données (quantité, variété, population des bases) sont-elles représentatives ?
- Définir les comportements acceptables : temps de réponse, taux d’erreur, stabilité
- Définir la priorité des objectifs : les requis, les optionnels …
Il faut aussi être conscient des limites de la démarche et rester humble :
- Quels sont les limites de ce que vous avez prévu ?
il faut être honnête et transparent : la couverture 100% n’existe pas, le temps (planning) et les compromis (cas de test choisis, données, plateforme …) ne le permettent pas.
Les objectifs se traitent la plupart du temps séquentiellement: il faut corriger un problème pour aller plus loin, et il n’y a aucune garantie qu’il n’y aura pas d’autre soucis.
La stratégie
Une fois les objectifs de performance clarifiés, il est possible d’établir une stratégie :
- Quels sont les tests identifiés pour répondre à chacune des problématiques ?
- Quels sont les dépendances :
- Tant qu’une application n’est pas au niveau de performance voulue, faire des tests de vieillissement, aux limites ou de robustesse n’a pas forcement de sens.
- Les priorités sont-elles cohérentes avec les prérequis et l’aspect progressif de la campagne ?
- Le planning :
- Il est impossible d’anticiper les problèmes qui vont être découvert et le temps de résolution, il est cependant possible de voir si l’ambition affichée au niveau des objectifs est raisonnable ou pas.
La stratégie est alors déclinée dans un plan de tests de performance.
Les outils
- L’injection
Pas de tests de performance sans outils d’injection.
Le rôle de ces outils est de reproduire les flux entre les clients et l’architecture cible en historisant le comportement utilisateur (temps de réponse, taux d’erreur). Ils disposent tous d’une API permettant de gérer à minima des requêtes HTTP/HTTPS, et suivant les produits, d’autres protocoles (SQL, Websocket, citrix, JMS …).
Les classiques « payants » : neoload et loadrunner (et la suite performance center)
Les classiques « gratuits » : Jmeter et Gatling
Ces outils permettent de générer des rapports plus ou moins complet.
Le besoin en exploitation des résultats sur un test de robustesse (focus sur les périodes de pannes et de remise en route) n’est pas le même que sur un test de non-reg (moyenne des temps de réponse et d’erreur, stabilité dans le temps).
Chacun de ces produits comporte des avantages et des défauts, tout dépend de vos besoins.
Les besoins de test orientent vers le logiciel le plus adapté et non pas le logiciel qui permet de déterminer ce qui va être fait dans une campagne de performance.
- Le monitoring
Le monitoring est la pour vous aider à comprendre comment va votre application et votre système, quels sont les ressources le plus utilisés et celles qui le sont peu.
Il s’agit d’éléments indispensables à l’analyse.
Monitoring d’infrastructure et de composant technique
-Système (physique, hyperviseur ou VM): CPU, Mémoire, disque, réseau
-JVM : threads, connexion, pool jdbc, gc
-Monitoring base de données
-Serveur http : worker, nombre de connexion
Monitoring applicatif
-Nombre de requête par service
-Temps de réponse interne
-Temps de réponse des partenaires
- Les logs
La 1ere matière générée par les applications sont les logs, dans un environnement modulaire ou distribué, une centralisation est vivement conseillée pour les exploiter pleinement.
- Les APM
Nécessaire pour comprendre le comportement applicatif si les logs et/ou le monitoring applicatif ne sont pas suffisamment pertinent.
Ces sondes permettent de comprendre comment se passe l’exécution des requêtes en interne, et donc sont une aide précieuse pour comprendre ou sont les points sensibles.
Leur fonctionnement est intrusif, et n’est pas adapté à toutes les situations.
Le rôle du testeur de performance
Un PerfMan a pour rôle d’accompagner le projet pour établir des objectifs, proposer une stratégie et exécuter la campagne.
Un bon PerfMan est curieux et technique, il ne se limite pas à exposer de tableau de temps de réponse:
De bons temps de réponse mais une mauvaise utilisation du SI (utilisation d’une seule instance dans un environnement distribué) sont autant d’anomalie possible, il faut toujours analyser.
Le perfman doit proposer et mettre en place des tunings (paramétrage, index …) permettant d’améliorer le comportement applicatif, analyser les causes possible de ralentissement avec les développeurs et valider le monitoring avec la production.
Conclusion
Les tests de performances sont un vaste domaine trop souvent négligés ou ramenés à la production d’un tableau de temps de réponse. C’est pourtant un outil extrêmement puissant, avec de multiples possibilités.
Le plus dur étant de déterminer ce que nous en attendons vraiment et de s’en accorder les moyens.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
