Analyse des performances des applications : indicateurs, tests et surveillance

Informatec Digital » Ressources » Analyse des performances des applications : indicateurs, tests et surveillance

Pour atteindre ce niveau de qualité, il ne suffit pas de « tester un peu avant de publier ». Cela nécessite une combinaison de facteurs. surveillance continue (APM et RUM)Des tests de performance bien conçus, des indicateurs clairs et des outils capables de simuler aussi bien l'utilisation quotidienne que les pics de trafic extrêmes sont essentiels. De plus, cette démarche doit être stratégique : mesurer ce qui compte vraiment pour l'entreprise et automatiser autant que possible afin d'éviter de réagir constamment aux problèmes.

Performance des applications : définition, importance et indicateurs de performance

Lorsque nous parlons de performances d'une application, nous faisons référence à La capacité d'une application à répondre rapidement, à être stable et à évoluer. lorsque le nombre d'utilisateurs ou le volume de données augmente, sans pour autant provoquer de pics de consommation de ressources ni dégrader l'expérience utilisateur. Ceci s'applique à applications mobiles, web et de bureauAPI, microservices ou systèmes d'entreprise complexes.

L'essentiel est de mesurer systématiquement une série de indicateurs de performance des applications (KPI) qui nous permettent de comprendre si l'application atteint ses objectifs techniques et commerciaux, et de détecter à temps les premiers dysfonctionnements, avant que l'utilisateur final ne les remarque ou que des alarmes ne se déclenchent en production.

Parmi les indicateurs les plus couramment utilisés pour évaluer les performances d'une application, on trouve :

• l'utilisation du processeur: la quantité de processeur consommée par l'application et la présence de pics révélant des calculs excessifs, des boucles mal conçues ou des processus bloquant la réponse.
• utilisation de la mémoire: volume de mémoire occupée, apparition de fuites, défauts de page ou hyperpagination indiquant que le système passe plus de temps à déplacer des données qu'à exécuter la logique métier.
• Requêtes par minute et octets par requêteCela indique le nombre de requêtes traitées par l'application ou l'API et la quantité de données gérées pour chaque requête. Cela permet d'évaluer la capacité du serveur et de vérifier si le volume de données par appel est raisonnable.
• Latence et temps de réponse: le temps nécessaire à l'application pour répondre, entre le moment où l'utilisateur effectue une action ou où le client envoie une requête et celui où elle reçoit une réponse utile.
• Disponibilité et temps de fonctionnement: pourcentage de temps pendant lequel le service est opérationnel, généralement surveillé par des pings récurrents ou des contrôles synthétiques.
• Taux d'erreur: proportion de requêtes qui se terminent par une erreur (codes HTTP 4xx/5xx, exceptions non gérées, défaillances fonctionnelles).
• Score Apdex et satisfaction des utilisateurs: indice qui résume, en une seule valeur, le pourcentage d'utilisateurs satisfaits, tolérants ou frustrés en fonction des temps de réponse.
• Performance de la collecte des déchets (GC)Sur les plateformes dotées d'une gestion automatique de la mémoire (Java, .NET, Android), combien de temps est consacré au GC, combien de pauses il introduit et comment cela affecte l'utilisation du processeur et la fluidité.
• débit ou performance: nombre de transactions ou de requêtes traitées par unité de temps, un paramètre essentiel dans les systèmes à forte concurrence.

L'objectif du suivi de ces indicateurs n'est pas de collecter des graphiques : il s'agit de comprendre l'état actuel de l'application, anticiper les goulots d'étranglement, prioriser les améliorations et démontrer, données à l'appui, que les optimisations ont un impact à la fois sur l'expérience utilisateur et sur les résultats commerciaux.

APM, RUM et surveillance des performances en temps réel

Dans les environnements modernes, avec des architectures distribuées, des conteneurs, des clouds hybrides et des microservices, il est pratiquement impossible de contrôler les performances sans une bonne stratégie de gestion des performances. outil de surveillance des performances des applications (APM) combinés aux techniques de surveillance des utilisateurs réels (RUM) et, de plus en plus, aux composants d'observabilité avancés.

Les solutions APM/RUM (telles que celles d'Elastic, Instana, Applications Manager, Turbonomic intégrées à l'APM, etc.) offrent visibilité de bout en bout de ce qui se passe dans votre application : temps de réponse, traces distribuées, requêtes de base de données, appels externes, erreurs et anomalies, intégrés aux métriques d’infrastructure.

El Surveillance d'utilisateur réel (RUM) Il capture l'expérience utilisateur réelle : temps de chargement des écrans, blocages de l'interface, erreurs du navigateur ou de l'application mobile et latence perçue selon les régions et les appareils. Il complète les tests de performance synthétiques et les tests en laboratoire, qui sont essentiels mais ne remplacent pas les données réelles.

Les plateformes APM modernes, quant à elles, offrent des fonctionnalités telles que :

• Surveillance en temps réel Indicateurs clés de performance (KPI) : disponibilité, Apdex, taux d’erreur, vitesse de transfert, La consommation de ressources.
• Traces distribuées pour suivre une transaction à travers plusieurs microservices, files d'attente, bases de données et services externes, en identifiant le maillon le plus lent.
• Cartes de dépendance Des outils automatisés qui montrent comment les services, les bases de données, les files d'attente et les interfaces sont liés, facilitant ainsi la détection de la cause première d'une panne.
• Profilage du code et des threads pour localiser les méthodes, les requêtes SQL ou les sections de code qui consomment trop de ressources CPU ou bloquent le thread d'interface.
• Alertes intelligentes et AIOps qui combinent l'apprentissage automatique et l'analyse des séries temporelles pour détecter les anomalies, réduire les fausses alertes et prioriser les incidents critiques.

La combinaison de l'APM, du RUM et de la surveillance synthétique donne lieu à un visibilité à 360° des performancesCela permet de comprendre ce que voit l'utilisateur, le fonctionnement interne de l'application et la réaction de l'infrastructure sous-jacente. Les équipes DevOps et ITOps peuvent ainsi réagir rapidement aux incidents et, mieux encore, les prévenir.

Indicateurs clés de performance dans les applications mobiles et web

Dans les applications mobiles et web, certains indicateurs de performance sont particulièrement sensibles car ils influent directement sur la perception des utilisateurs et le succès du produit. Un suivi rigoureux de ces indicateurs fait toute la différence entre une application qui captive les utilisateurs et une autre qui est désinstallée après deux utilisations.

L'un des points critiques du mobile est le latence de démarrage de l'applicationAutrement dit, le temps qui s'écoule entre le moment où l'utilisateur appuie sur l'icône (ou une notification) et le moment où les données utiles s'affichent à l'écran. On distingue plusieurs types :

• démarrage à froidL'application n'est pas en mémoire ; le système doit créer un processus, charger le code, initialiser les bibliothèques et afficher le premier écran.
• Démarrage à mi-chaudLe processus existe, mais l'activité est recréée ou restaurée à un état antérieur.
• Démarrage à chaudIl vous suffit de gonfler à nouveau votre point de vue ou de reprendre votre activité, avec très peu d'efforts supplémentaires.

À titre de référence, il est fortement recommandé de viser démarrages à froid inférieurs à 500 ms Étant donné que les latences p95 et p99 (percentiles les plus élevés) sont proches de la médiane, si certains utilisateurs attendent plusieurs secondes tandis que d'autres ouvrent l'application en une demi-seconde, il y a un déséquilibre.

Un autre aspect critique est la Défilement et verrouillage de l'interfaceSur les écrans animés (flux, listes, galeries), les utilisateurs s'attendent à une fluidité parfaite. Lorsque le système ne parvient pas à générer des images à la fréquence de rafraîchissement de l'appareil (60 Hz, 90 Hz ou même 120 Hz), des saccades apparaissent. Ces saccades se produisent lorsque l'application met plus de temps que la durée d'une image (par exemple, plus de 16,7 ms à 60 images par seconde) pour afficher le contenu.

Outre la fluidité, il est nécessaire de surveiller le transitions entre les écransChanger d'onglet, ouvrir les détails d'une liste ou afficher une boîte de dialogue doit se faire de manière quasi instantanée, avec des animations fluides et sans scintillement ni écrans blancs prolongés.

En toile de fond, mais tout aussi important, se trouvent la consommation des batteries et l'efficacité énergétique. Tâches inutiles, allocations de mémoire massives et utilisation intensive du processeur Elles réduisent l'autonomie de la batterie et provoquent une surchauffe de l'appareil. Android Runtime (ART) offre une efficacité accrue, mais si la boucle interne de votre application crée des milliers de nouveaux objets par seconde, le coût de l'allocation et du nettoyage de la mémoire sera perceptible.

Flux de travail pour identifier et corriger les problèmes de performance

Pour éviter de dépendre de la chance, il est très utile d'établir un flux de travail d'analyse systématique des performancesCette approche combine des tests manuels détaillés en laboratoire avec la collecte de métriques agrégées en production. Une approche typique comprend les étapes suivantes :

Premièrement, nous devons identifier le parcours utilisateurs critiquesAutrement dit, les flux qui ont le plus grand impact sur l'expérience et l'activité :

• Lancements fréquents de l'application (icône, notifications, liens profonds).
• Écrans à défilement continu sur de grandes quantités de données.
• Transitions clés entre les vues et les activités.
• Processus longs tels que la navigation, la lecture audio/vidéo, le passage en caisse, etc.

Une fois définies, elles sont mises en œuvre et analysées à l'aide de outils de profilage et de traçage comme Perfetto ou Systrace pour observer l'activité du périphérique avec une précision à la microseconde, des générateurs de profils de mémoire pour détecter les fuites et les points chauds d'allocation, ou des outils comme Simpleperf pour déterminer quelles fonctions consomment le plus de ressources CPU.

Il est important de souligner qu'une analyse détaillée des performances nécessite déboguer les exécutions individuelles Ces itinéraires sont reproduits de manière contrôlée, ce qui permet de reproduire les problèmes. L'analyse des données agrégées est utile pour détecter les tendances et les régressions, mais elle ne remplace pas une analyse approfondie des traces spécifiques.

Dans le même temps, il est conseillé de configurer Collecte continue de métriques Dans les environnements de test automatisés et de production : temps de démarrage, taux de blocage, métriques d’images (par exemple, via FrameMetricsAggregator sur Android), métriques de champ Play Console, macro-benchmarks de défilement, etc. Ces métriques permettent de constater la variabilité réelle entre les appareils, les versions du système d’exploitation et les conditions réseau.

Paramètres de l'application et du système pour une mesure précise

L'un des écueils les plus courants est de mesurer les performances dans des conditions irréalistes. Pour que les résultats soient utiles, il est nécessaire configurer à la fois l'APK et le système avec soin, en veillant à ce que l'environnement de test ressemble à celui de la production, tout en contrôlant le bruit.

Du côté de l'application, c'est essentiel Ne pas effectuer de mesures sur les versions de débogageLes variantes de débogage ajoutent des vérifications, des journaux et des indicateurs qui modifient considérablement les temps d'exécution. Sous Android 10 et versions ultérieures, il est possible d'utiliser l'attribut profileable android:shell="true" dans le manifeste pour activer le profilage sur les versions de production, tout en conservant un comportement proche du comportement réel.

Il est également conseillé d'utiliser le réduction de code Les environnements de production (ProGuard, R8, etc.) sont importants, car la taille et l'organisation du code peuvent engendrer des différences de performances notables. Il est cependant crucial de revoir les règles : certaines configurations peuvent supprimer des points de surveillance importants, ce qui nécessite des ajustements pour l'environnement de test.

Concernant la compilation, il est judicieux de ramener l'application à un état connu, généralement et clairement en mode vitesse o profil de vitesseCes deux options réduisent la quantité de code interprété par DeX et le besoin de compilation JIT en arrière-plan, ce qui stabilise les résultats. Le mode de profilage de vitesse tente de se rapprocher davantage du comportement en production, mais nécessite une phase de préchauffage de l'application et la gestion des profils (par exemple, les profils de base).

Du point de vue du système, lorsque des mesures de très haute fidélité (micro-benchmarks) sont nécessaires, il est courant calibrer l'appareilL'exécution de tests comparatifs A/B sur le même terminal et la même version du système d'exploitation, la configuration des fréquences du processeur/GPU, la désactivation des petits cœurs ou la limitation thermique avec des scripts comme lockClocks, etc. ne représentent pas la réalité, mais permettent de réduire le bruit dans des scénarios très spécifiques.

Pour des mesures plus proches de l'expérience utilisateur (temps de démarrage, consommation de la batterie, plantages de l'interface utilisateur), il est recommandé d'utiliser frameworks de test tels que Macrobenchmarkqui automatisent bon nombre de ces étapes et évitent des erreurs de configuration subtiles mais critiques.

Schémas typiques des problèmes de performance

Dans presque toutes les applications qui font l'objet d'une analyse approfondie, certaines choses apparaissent schémas récurrents de problèmes Il est bon de le savoir, car des solutions assez claires existent généralement si les problèmes sont détectés à temps.

L’un des plus courants est le Démarrage lent en raison de l'activité sur le trampolineCe problème survient lorsqu'après une action de démarrage (icône, notification, lien profond), une activité intermédiaire est lancée sans afficher d'images, puis l'activité principale démarre. Les traces montrent deux événements `activityStart` consécutifs sans aucun traitement visuel entre les deux. Ce « saut » ajoute de la latence au démarrage sans apporter de valeur ajoutée. La solution consiste généralement à refactoriser l'initialisation dans un composant réutilisable ou à l'intégrer directement dans l'activité principale.

Un autre classique est le allocations inutiles qui déclenchent la collecte des déchetsSi une analyse Systrace ou des profils de mémoire révèlent des cycles de ramasse-miettes s'exécutant toutes les quelques secondes lors d'une opération de longue durée, il est fort probable que du code alloue des objets de manière répétée et constante au sein de boucles intensives. La solution ne consiste pas à supprimer chaque nouvelle instruction, mais plutôt à cibler les points chauds, en réutilisant des structures ou en appliquant des mécanismes de mise en pool lorsque cela est pertinent.

On les trouve également souvent images avec des gels dans le pipeline graphiqueDans une trace d'exécution normale, les appels à Choreographer.doFrame() se produisent à un rythme régulier (par exemple, toutes les 16,7 ms). En zoomant sur les zones où ces appels se produisent à cette fréquence, on peut identifier des vues gourmandes en ressources, des mises en page trop complexes, des opérations d'E/S exécutées sur le thread d'interface utilisateur ou des RecyclerView mal configurées.

Plus précisément, RecyclerView est à l'origine de nombreux problèmes : invalidation de l'ensemble des données avec notifyDataSetChanged() alors que seuls quelques éléments sont modifiés, configuration incorrecte des pools de vues recyclées dans les RecyclerView imbriqués, ou encore non-exécution de certaines opérations. préchargement des données Cela suffit lorsque la fin de la liste est atteinte. Tout cela engendre un rendu coûteux, des sauts dans le défilement et des temps d'attente perceptibles pour l'utilisateur.

Tests de performance : types, étapes et bonnes pratiques

Au-delà du suivi de la production, toute stratégie sérieuse a besoin d'un plan solide de tests de performance des applications dans des environnements contrôlés. Ces tests nous permettent de valider la capacité, la stabilité et l'évolutivité avant de déployer des modifications ou de nouvelles versions auprès des utilisateurs.

Il existe plusieurs types de tests, chacun ayant son objectif spécifique :

• Essais de chargeIls évaluent le comportement de l'application sous une charge prévue d'utilisateurs ou de transactions, en mesurant les temps de réponse, le débit et la consommation de ressources afin de détecter les goulots d'étranglement avant le déploiement.
• Tests de résistanceIls poussent le système au-delà de ses limites normales pour observer ses résistances, ses défaillances et sa capacité de récupération. Ils sont essentiels à la planification des capacités et à la gestion des pics d'activité comme le Black Friday.
• Tests d'endurance/d'immersionIls maintiennent une charge soutenue pendant des heures, voire des jours, afin de déceler les problèmes de dégradation lente, de fuites de mémoire ou d'épuisement des ressources.
• Tests de pointeIls simulent des augmentations de charge soudaines et répétées (par exemple, des campagnes, des lancements de fonctionnalités, des diffusions en direct) afin de vérifier que l'application et l'infrastructure peuvent gérer des changements soudains.
• tests de volumeIls analysent le comportement de l'application lorsque le nombre d'utilisateurs augmente significativement. quantité de données (taille de la base de données, fichiers, messages), validation des temps de réponse, de la fiabilité du stockage et de la perte de données.
• Tests de mise à l'échelleIls vérifient comment l'application réagit lorsque la charge augmente progressivement, et si la mise à l'échelle horizontale ou verticale produit l'amélioration des performances attendue.

Le processus de test de performance typique comprend plusieurs phases distinctes. Premièrement, un analyse des exigencesComprendre quels temps de réponse, débits, niveaux de disponibilité ou limites d'erreur sont acceptables pour l'entreprise. Ensuite, une phase de planification et stratégie qui définit le périmètre des tests, l'environnement, les outils et les indicateurs qui seront surveillés.

Les éléments suivants sont conçus cas de test Couvrant différents scénarios de charge, conditions de réseau et volumes de données, l'environnement de test est configuré (matériel, logiciel, réseau, outils d'injection de charge et de surveillance), et les tests sont exécutés, en collectant soigneusement les données de performance.

La phase critique est la surveillance et analyseCela implique de corréler les temps de réponse avec l'utilisation du processeur, les latences réseau avec les taux d'erreur, les pics de trafic avec les surcharges de bases de données, etc. Après avoir consigné les résultats dans des rapports clairs destinés aux parties prenantes, le processus se poursuit avec… optimisation et nouveaux testsLe code, les configurations ou les ressources sont ajustés, et les tests sont répétés jusqu'à ce qu'il soit validé que les améliorations prennent effet.

Outils et cadres pour les tests de performance

Pour mettre tout cela en pratique, il est nécessaire de s'appuyer sur outils de test de performance Spécifiques, à la fois open source et commerciales, couvrant l'automatisation, la génération de charge, la surveillance et l'analyse. Voici quelques catégories pertinentes :

• outils open sourceDes projets tels qu'Apache JMeter, Gatling, k6, Locust, Taurus, nGrinder, ou des frameworks de tests unitaires et fonctionnels (JUnit, XCTest, Appium) étendus avec des scénarios de performance permettent la construction de suites de tests très puissantes à faible coût de licence.
• Outils de test de charge commerciaux et APMDes solutions telles que WebLOAD, LoadNinja, NeoLoad, LoadView, BlazeMeter, Rational Performance Tester, Silk Performer, Eggplant, CloudTest ou Parasoft offrent des environnements intégrés avec génération de charge basée sur le cloud, rapports avancés et assistance professionnelle.
• Solutions spécialisées et observablesDes produits tels que Applications Manager, Instana, Dynatrace, IBM Turbonomic ou des plateformes de surveillance réseau comme SolarWinds, qui se concentrent sur la surveillance continue, la détection des anomalies et la corrélation entre les performances des applications, l'infrastructure et l'expérience utilisateur.
• Outils spécifiques à la plateformeDans le cas d'Android, par exemple, des outils tels que Perfetto, System Tracing, le profileur de mémoire d'Android Studio, Simpleperf, Systrace ou les métriques d'images de la Play Console permettent une analyse très fine du comportement au niveau du système.

Lors du choix entre l'un et l'autre, il est conseillé de prendre en compte des facteurs tels que Facilité d'utilisation, prise en charge des protocoles et technologies, évolutivité, intégration avec l'intégration continue et le déploiement continu (CI/CD)Le modèle de licence, l'extensibilité et la qualité du support (communautaire ou commercial) sont également des facteurs importants. Il est fréquent d'en combiner plusieurs : un pour la génération de charge, un autre pour la gestion des performances applicatives (APM) et un troisième pour l'observabilité de l'infrastructure.

En résumé, l'analyse et le suivi des performances des applications nécessitent une combinaison de métriques bien choisies, d'outils appropriés et de processus de test rigoureux, mais les résultats en valent largement la peine : des applications plus rapides, plus stables et plus efficacesDes utilisateurs plus satisfaits, moins d'incidents de production et, bien sûr, un impact positif direct sur la réputation de la marque et les revenus.

Article connexe:

Découvrez Qt Creator IDE : l'environnement le plus puissant pour créer des applications multiplateformes