Le test de charge

Le test de charge peut s'intégrer dans une démarche de test de performances. Dans ce contexte, cela signifie un accroissement linéaire de la charge via des outils de test appropriés. Pour un serveur web, la charge est définie en termes d'utilisateurs concurrents ou de connections HTTP simultanées.

Dans la littérature du test, le terme de "test de charge" est couramment défini comme le processus de solliciter le système testé en lui faisant réaliser la tache la plus importante qu'il puisse accomplir. Le test de charge est parfois appelé test volumétrique, test d'endurance ou test de longévité.

Exemples de tests de volumétrie :

• tester un processeur de texte en éditant un document de grande taille
• tester une imprimante en lui envoyant un fichier de très grande taille
• tester un serveur mail en créant des milliers de boites mails
• un cas spécifique du test de volumétrie est le test de volumétrie nulle, où une tâche vide est demandée au système, mais on entre là dans le domaine du test aux limites

Exemples de tests de longévité, d'endurance :

• Tester une application client/serveur en exécutant le client en boucle durant une période de temps donnée

Buts du test de charge :

• mettre à jour des bugs qui n'ont pas été découverts dans les tests unitaires ou d'intégration, comme des bugs dans la gestion mémoire, des fuites de mémoire, des buffers overflows, etc.
• s'assurer que l'application atteint le niveau de performance de référence établis lors des tests de performance. Ceci est réalisé en exécutant des tests de non régression de l'application face à une charge maximale.

 
Cette création est mise à disposition sous un contrat Creative Commons.
Article original publié par Grig Gheorghiu.

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.