Le test de performances. Le but des tests de performances n'est pas de trouver des bugs, mais d'éliminer les goulots d'étranglement et d'établir une référence pour les futurs tests de non régression. Réaliser une campagne de tests de performances c'est s'engager dans un prudent processus de mesures et d'analyses. Idéalement, le logiciel testé est déjà suffisamment stable pour que ce processus soit mené tranquillement. Une liste clairement définie d'attentes est essentiel pour réaliser une campagne de tests de performances adéquate. Par exemple, pour un site web, vous devez connaitre au moins deux points : - Le nombre d'utilisateurs connectés en même temps sur votre site web;
- Définir un temps de réponse acceptable.
Une fois que vous savez où vous voulez aller, il ne reste plus qu'à augmenter la charge en cherchant les goulots d'étranglement. Pour reprendre l'exemple du site web, ces goulots peuvent exister en divers points, et peuvent être identifiés par des outils adaptés :
- au niveau applicatif, les développeurs peuvent utiliser des profilers pour localiser des codes trop gourmands
- au niveau base de donnée, les DBA ou les développeurs peuvent utiliser des profilers spécifiques ainsi que des optimisateurs de requêtes
- au niveau de l'OS, les ingénieurs système peuvent utiliser des outils tels que top, vmstat, iostat (sous les systèmes de type UNIX) et PerfMon (sous Windows)pour monitorer les ressources physiques comme CPU, mémoire, swap, écritures disque; Des outils spécifiques de monitoring du noyau peuvent également être utilisés.
- au niveau du réseau, les ingénieurs réseau peuvent utiliser des sniffeurs de paquets comme tcpdump ou snoop ainsi que des analyseurs de paquets comme ethereal, et divers utilitaires comme netstat, MRTG, ntop, mii-tool
D'un point de vue du test, les monitorings ci dessus font partie d'une approche boite blanche, avec une vision détaillée de tous les aspects du système testé. Tous les paramètres pertinents sont mesurés dans le but de les personnaliser pour améliorer les performances de l'application testée.
Cependant, l'approche boite noire est également utilisée dans le test de charge, le testeur utilisant des outils qui permettent charger l'application en simulant un nombre donné d'utilisateurs concurrents. Des mesures sont faites sur les temps de réponse ainsi que sur la validité des réponses du serveur (capacité du serveur à délivrer l'information exacte). Si le résultat des tests de performances n'est pas en ligne avec les résultats attendus, des modifications s'imposent (optimisation de la configuration, upgrade de serveurs, ou de l'infrastructure).Pour être surs que votre code ou votre base de données est aussi efficace que possible, des logiciels de "développement pilotés par le test" TDD (voir méthode agile) tels que jUnitPerf améliorent sensiblement les tests unitaires en incluant des tests de charge et des fonctionnalités de tests de temps d'exécution. Ce genre de procédure à été décrite par Mike Clark comme "continuous performance testing". Si après une optimisation de l'application et de la base de donnée, le système n'atteint toujours pas les niveaux de performances désirés, une grande palette de méthodes d'optimisation à tous les niveaux décrits précédemment. Vous trouverez ici quelques exemples de mises en œuvre possibles pour améliorer les performances d'un service web : - Mettre en place un mécanisme de caching comme Squid
- Rendre les pages web les plus fréquemment demandées statiques pour moins solliciter la base de donnée
- Mettre en place une solution de partage de charge pour vos serveurs web via un load balancer
- Mettre en place une solution de partage de charge pour vos bases de données, avec des serveurs dédiés aux opérations d'écriture
- Améliorer la puissance de vos serveurs web ou base de donnée en augmentant la puissance CPU, la RAM, les disques
- Redimensionner les liens et/ou les équipements réseau
Dû à la complexité des architectures mises en place dans les SI actuels, l'optimisation des performances peut être plus lié à une question de savoir faire et d'expérience qu'à une science exacte. Il faut prendre soin de ne modifier qu'un paramètre à la fois et de refaire les mesures, car de multiples changements peuvent avoir des interactions complexes qui deviendront complexes à identifier et reproduire.
Le cycle "Lancer les tests de performances --> mesurer les résultats --> optimiser le système" est répété jusqu'à ce que le système testé atteigne le niveau de performances souhaité. A partir de là, les testeurs ont un point de référence sur le fonctionnement du système dans des conditions standard. Cette référence peut ensuite être utilisée dans des tests de non régression pour jauger les performances de l'application lors des futures montées en versions. 
Cette création est mise à disposition sous un contrat Creative Commons.
Article original publié par Grig Gheorghiu.
|
