Test de charge et mesure des performances applicatives
Un test de charge consiste à simuler un nombre d’utilisateurs virtuels prédéfinis, afin de valider que l’application est conçue pour une charge attendue d’utilisateurs. Ce type de test permet de mettre en évidence les points sensibles et critiques de l’architecture technique. Avec l’aide d’agents applicatifs d’introspection (APM), on mesure les performances applicatives en temps réel.

Un test de charge consiste à simuler un nombre d’utilisateurs virtuels prédéfinis, afin de valider que l’application est conçue pour une charge attendue d’utilisateurs. Ce type de test permet de mettre en évidence les points sensibles et critiques de l’architecture technique. Avec l’aide d’agents applicatifs d’introspection (APM), on mesure les performances applicatives en temps réel.
Contexte
Dans l’exemple suivant, un test de charge doit être réalisé afin de valider des corrections et améliorations applicatives. Ce test a été effectué sur l’environnement de recette d’une application mobile à l’aide de l’outilOctoperf. Des agents APM AppDynamics ont été installés sur les serveurs applicatifs.
Dans le cadre de ce test, jusqu’à 300 utilisateurs simultanés ont été simulés sur une durée d’une heure. Deux points de tir distinct ont été utilisés afin de répartir la charge à plusieurs endroits en Europe.
Résultats du nouveau test de charge
Comme on peut le constater sur les deux graphiques « avant/après » ci-dessous, l’amélioration est très nette.
On obtient des temps de réponse beaucoup plus stables et des pics à 16s à partir de 270 utilisateurs simultanés. Lors du précédent test, les pics pouvaient atteindre plus de 22 secondes à 180 utilisateurs et certaines requêtes arrivaient en timeout (pas de réponse).
Test de charge numéro 1
Test de charge numéro 2
Le nombre de connexions simultanées maximum à la base de données est passé d’environ 160 à seulement 45. En moyenne, le nombre de connexions est de 18 contre 30 lors du précédent test de charge.
Ci-dessous, on peut observer un début de latence côté serveur à partir de 240 utilisateurs. Une analyse plus approfondie pourrait permettre de déterminer un éventuel problème de mémoire (fuite, …).
Conclusion
Il existe plusieurs situations où le test de charge peut apporter de précieuses informations comme la mise en place d’une nouvelle version de l’application, des modifications de l’infrastructure (serveurs) ou encore une augmentation du nombre d’utilisateurs simultanés. Le test de charge permet de déterminer la capacité maximale que peut accepter l’application ainsi que les performances de celle-ci.
Lorsque l’on couple un test de charge avec des agents APM tels queAppDynamicsouAppInternals, on obtient des métriques sur l’application ainsi que l’évolution de la gestion de la mémoire. Cela apporte une vue de l’application et de son comportement en temps réel lorsque l’application est chargée.
corentin
Autres articles
Toutes les ressources
Observabilité à grande échelle : du cadrage à l’autonomie des équipes
Du cadrage à l’amélioration continue en RUN, nos retours de terrain pour déployer l’observabilité et faire progresser l’autonomie des équipes.
LireDiagnostiquer les incidents Microsoft Teams en quelques minutes : testez MS Teams Observability dans Dynatrace (mode démo)
Microsoft Teams est devenu un outil critique pour les entreprises. Réunions stratégiques, collaboration quotidienne, téléphonie, centres de contacts : quand Teams fonctionne mal, l’impact est immédiat pour les utilisateurs… et pour les équipes IT. Le problème, ce n’est pas l’absence de données.
Lire
Suivi du centre de contacts pour Microsoft Teams : les cas d’usage essentiels pour comprendre et améliorer vos appels
Un guide pour clarifier l’usage, équilibrer les flux et diagnostiquer les appels Teams.
Lire