Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à cette recommandation de liste de contrôle d’efficacité des performances d’Azure Well-Architected Framework :
| PE :06 | Optimisez les performances de votre charge de travail en testant régulièrement dans un environnement de production pour vous assurer que votre charge de travail atteint les objectifs de performances souhaités et atteint vos objectifs métier. |
|---|
Le test de performances est une pratique de test non fonctionnelle utilisée pour évaluer le comportement d’une charge de travail dans différentes conditions. Il vous aide à identifier la dégradation des performances tôt, à résoudre les problèmes de manière proactive et à garantir l’alignement continu avec les contrats de niveau de service.
Lorsque vous mesurez les temps de réponse, le débit, l’utilisation des ressources et la stabilité, vous recueillez des preuves que votre charge de travail répond constamment aux cibles définies et fournit le niveau de performances dont votre entreprise a besoin.
Les stratégies clés de cet article reposent sur les pratiques de test fondamentales décrites dans les stratégies d’architecture OE :09 pour les tests. Nous vous recommandons d’examiner d’abord cet article. Les recommandations de ce guide sont limitées aux performances et se concentrent sur l’atteinte de cibles de performances afin que vos charges de travail restent alignées sur les objectifs métier en constante évolution.
Le tableau suivant définit les termes clés des performances utilisés dans cet article.
| Terme | Definition |
|---|---|
| Objectifs de performances | Les valeurs de performances spécifiques qu’une charge de travail doit respecter, telles que le temps de réponse, le débit ou le nombre d’utilisateurs simultanés. |
| Seuils de performances | Limites qui séparent les performances acceptables des performances inacceptables pour une métrique donnée. |
| Budget des performances | Partie d’une cible de performances globale allouée à chaque couche ou composant d’une charge de travail. |
| Budget d'erreur | Niveau autorisé d’erreurs ou de défaillances, dérivé des objectifs de niveau de service (SLO). |
| Critères d’acceptation | Les conditions qu’un résultat de test doit satisfaire pour que la charge de travail respecte ses exigences de performance. |
| Expérimentation basée sur des hypothèses | Méthode de test dans laquelle vous indiquez une prédiction sur les performances, testez-la par rapport à une base de référence et validez-la avec des résultats mesurés. |
| Base de référence des performances | Ensemble de métriques qui représentent le comportement d’une charge de travail dans des conditions normales, comme validé par les tests. |
| Transactions synthétiques | Requêtes scriptées qui simulent des interactions utilisateur réelles pour mesurer les performances du système dans des conditions contrôlées. |
| Régression des performances | Baisse des performances par rapport à une base de référence établie, introduite par une modification du code, de la configuration ou de l’infrastructure. |
| Dérive des performances | Baisse progressive des performances au fil du temps qui passe inaperçue sans tests réguliers par rapport aux lignes de base établies. |
Définir des objectifs mesurables pour vos tests de performances
Les objectifs de performance mesurables transforment les attentes subjectives en critères objectifs que vous pouvez tester et valider.
Définissez vos objectifs de performances et attribuez des budgets. Définissez et documentez des cibles de performances spécifiques, telles que le nombre d’utilisateurs simultanés que vous devez prendre en charge. Assurez-vous que ces cibles s’alignent sur vos objectifs de niveau de service et traduisez-les en objectifs de test mesurables.
Affectez des budgets de performances et d’erreurs sur différentes couches de votre charge de travail. Lorsque les tests de performances échouent, vos budgets vous aident à identifier la couche responsable et l’endroit où concentrer les efforts d’optimisation. Sans budgets, les tests défaillants vous indiquent uniquement que les objectifs de performances ne sont pas atteints, pas là où se trouve le problème.
Par exemple, vous pouvez définir des budgets de 400 ms pour le temps de réponse de l’API, 150 ms pour les requêtes de base de données et une limite de 1% sur les requêtes ayant échoué. Lorsqu’un test échoue, vous pouvez vérifier les résultats de chaque couche par rapport à son budget pour déterminer si le problème est des réponses d’API lentes, des requêtes de base de données lentes ou un pic d’erreurs.
Note
Évitez de définir des contrats SLA avant de comprendre vos flux d’utilisateurs et vos besoins en matière de performances. Les contrats SLA doivent être basés sur des besoins réels des utilisateurs et des objectifs métier, et non sur des cibles arbitraires.
Définissez les critères d’acceptation avec des seuils de réussite et d’échec clairs. Basez vos critères d’acceptation sur des métriques de performances telles que la latence, les temps de réponse, le débit, l’utilisation des ressources, les taux d’erreur et tous les autres indicateurs de performances qui s’alignent sur vos objectifs de performances.
Définissez des seuils pour chaque métrique afin que vos tests produisent des résultats de réussite ou d’échec clairs. Si votre SLO nécessite 95% de requêtes pour se terminer dans un délai de 200 ms, définissez le seuil de temps de réponse de l’API sur 200 ms au 95e centile. Toute exécution de test où le 95e centile dépasse 200 ms est un échec.
Démarrer tôt et tester en continu
L’analyse précoce des performances intercepte les goulots d’étranglement architecturaux avant qu’ils ne deviennent coûteux pour remédier.
Démarrez les tests de performances dès que possible dans le cycle de vie du développement logiciel de votre charge de travail. Vous n’avez pas besoin d’une application complète pour commencer. Les développeurs peuvent profiler du code localement, mesurer les temps de réponse et identifier les opérations gourmandes en ressources. Les tests précoces informent les décisions de conception, valident les choix architecturaux par rapport aux objectifs de performances et identifient les opportunités d’optimisation.
Testez en permanence votre charge de travail au fur et à mesure qu’elle évolue pour répondre à de nouvelles exigences. Chaque modification de code peut introduire des régressions de performances. Exécutez régulièrement des tests pour intercepter ces modifications au début. Incorporez des tests de performances dans des pipelines de déploiement et exécutez des tests automatisés périodiques pour détecter la dérive des performances avant d’atteindre la production.
Compromis. Les tests de performances précoces nécessitent une infrastructure dédiée et une expertise spécialisée, ce qui augmente les coûts opérationnels. Équilibrez cet investissement par rapport au coût des problèmes de performances découverts tardivement et des incidents en production.
Tester dans des conditions réelles
Les tests de performances doivent correspondre aux conditions réelles afin que vos résultats soient significatifs.
Mettre en miroir votre environnement de production
Votre environnement de test doit mettre en miroir la production aussi étroitement que pratique. Personnalisez votre approche pour l’environnement en fonction du profil de risque de votre charge de travail.
Pour les charges de travail stratégiques, faites correspondre la production exactement entre :
- SKU et configurations informatiques
- Paramètres de mise à l’échelle automatique
- Configurations de mise en cache
- Conditions réseau (latence, bande passante)
- Dépendances externes
Pour les charges de travail non critiques, les tests dans un environnement mis à l’échelle qui imite la production peuvent fournir des insights utiles à moindre coût.
Empêcher la dérive de la configuration. La dérive de configuration peut entraîner des résultats de test trompeurs. Implémentez des vérifications automatisées pour vérifier que votre environnement de test correspond à la production. Vérifiez que les versions correctes sont déployées avant d’exécuter des tests.
Valider les performances en production
Les environnements de test ne peuvent pas répliquer entièrement des conditions réelles qui affectent les performances. Les tests de production exposent des problèmes qui ne s’affichent que sous l’utilisation réelle et fournissent des lignes de base précises pour l’optimisation future. Certaines exigences de performances ne peuvent être validées que lorsque les utilisateurs réels, les données et l’infrastructure se croisent.
Exécutez des tests de production contrôlés. Planifiez des tests pendant les heures creuses pour comprendre comment votre charge de travail se comporte sous l’épuisement des ressources et récupère des défaillances.
Les tests de production révèlent des caractéristiques de performances dans des conditions réelles, notamment :
- Modèles de comportement utilisateur réalistes et volumes de données
- Véritable latence réseau et variations de bande passante
- Effets de distribution géographique
- Performances et dépendances de l’API tierce
- Comportement de mise en cache réel et caractéristiques de l’infrastructure
Utilisez des techniques de test progressif. Commencez par de petits pourcentages de trafic et augmentez progressivement. Surveillez les temps de réponse, le débit, les taux d’erreur et l’utilisation des ressources à chaque étape. Cette approche progressive limite les risques tout en identifiant le point de rupture, en révélant des goulots d’étranglement et en fournissant une vue précise du comportement du système en cas d’augmentation de la demande.
Surveillez les tests de production en continu pour trouver des problèmes précoces. Implémentez des protections automatisées qui interrompent les tests s’ils affectent négativement les utilisateurs, tels que les mécanismes de restauration automatisée et les alertes en temps réel. Ces techniques garantissent une réponse rapide et réduisent les perturbations.
Note
Lorsque vous exécutez des tests de performances contrôlés en production, vous devez allouer une capacité supplémentaire pour gérer la charge supplémentaire générée par les tests.
Risque: Le test de production affecte directement les clients réels, car il peut créer une charge supplémentaire et perturber le trafic. Implémentez toujours des mesures de sécurité, limitez l'exposition et ayez des plans de réversibilité prêts à minimiser l'impact potentiel sur l'entreprise. Équilibrez les avantages des tests réalistes par rapport à l'impact potentiel sur l'activité qui peut perturber les utilisateurs en direct.
Valider les modifications avec des expériences basées sur des hypothèses
Utilisez l’expérimentation basée sur des hypothèses pour guider vos tests de performances. Concevoir des expériences de performances individuelles afin qu’elles produisent des résultats significatifs.
Commencez par une hypothèse ciblée sur les performances de votre charge de travail et définissez des critères de réussite mesurables qui mènent à des décisions exploitables. Par exemple, votre hypothèse peut être : « L’ajout d’un index à la table orders réduit le temps de requête de 70% en cas de pic de charge ». Votre base de référence est le schéma actuel, et la variante est le schéma avec le nouvel index. Exécutez le même test de charge sur les deux versions. Capturez la latence des requêtes, l’utilisation du processeur de base de données et le débit, puis comparez les résultats pour déterminer si l’hypothèse est vraie.
Appliquer plusieurs types de test de performances
Les tests de performances couvrent une gamme de tests qui évaluent la vitesse, la stabilité et l’extensibilité dans différentes conditions. Chaque type de test cible des aspects de performances distincts de votre charge de travail. Il découvre des insights uniques et permet une évaluation complète qui va au-delà des tests fonctionnels.
Utilisez plusieurs types de test pour valider votre charge de travail à partir de différents angles. Par exemple, les tests de stress trouvent le point de rupture sous la charge maximale, mais seuls les tests d’endurance révèlent des fuites de mémoire qui s’affichent sur des heures ou des jours.
Choisissez des types de test en fonction de ce que vous devez valider.
Le tableau suivant indique quand utiliser chaque type de test et ce qu’il révèle sur votre charge de travail. Bien que ce tableau ne soit pas une liste exhaustive, il sert d’exemple illustrant.
| Type de test | Objectif principal | Quand appliquer | Ce qu’il révèle | Environnement |
|---|---|---|---|---|
| Test de charge | Vérifier que le système gère les volumes d’utilisateurs attendus sous la normale et les pics d’utilisation | Démarrer tôt, exécuter fréquemment | Performances de référence, limites de capacité, efficacité de la mise à l’échelle | Environnement de préproduction ou de production |
| Test de stress | Comprendre les limites système et les points de rupture | Avant que le système soit prêt pour la production | Capacité maximale, modes d’échec, comportement de récupération | Environnement de test de performances dédié |
| Test de charge ponctuelle | Vérifier que le système gère les pics de trafic soudains | Démarrer tôt, en particulier pour les applications publiques | Réactivité de l'autoscaling, gestion des files d'attente, dégradation contrôlée | Environnement de préproduction ou de production |
| Test d’endurance/de trempe | Détecter les problèmes qui apparaissent uniquement sur des périodes prolongées | Une fois les tests de charge initiaux réussis | Fuites de mémoire, épuisement des ressources, problèmes de pool de connexions | Environnement de type production avec allocation complète des ressources |
N’essayez pas d’implémenter tous les types de test immédiatement. Commencez par les tests de charge de base pour comprendre les performances de votre base de référence. À mesure que vous identifiez les risques et gagnez de l’expérience, développez les tests de stress, les tests de pic et éventuellement les tests d’endurance.
Utiliser des modèles d’utilisation réels et des caractéristiques de données
Les tests avec des données réalistes fournissent des insights précis sur la consommation des ressources, le comportement du système et les problèmes de performances masqués.
Créez différents jeux de données de test qui représentent différents scénarios, profils utilisateur et volumes de données. Utilisez des variantes d’entrée et une randomisation pour imiter la diversité réelle des utilisateurs. Incluez des cas de périphérie susceptibles d’entraîner des problèmes de performances, tels que des charges utiles volumineuses, des requêtes complexes ou une concurrence élevée.
Vos données de test doivent ressembler à des données de production réelles. Utilisez des données synthétiques qui ont des caractéristiques de données de production. Réservez des jeux de données de production (correctement anonymisés) pour certains scénarios tels que la mise en évidence des comportements de gestion des données tels que la cohérence des transactions, la latence et la gestion des volumes.
Simuler des transactions synthétiques qui imitent des flux de travail utilisateur réels. Scriptez ces transactions et exécutez-les à plusieurs reprises pour générer une charge qui reflète la façon dont votre charge de travail est réellement utilisée.
Vos scénarios de test doivent refléter des modèles d’utilisation réels tels que l’accès utilisateur simultané, les périodes de charge maximales et des séquences de transactions spécifiques. Assurez-vous que les scénarios s’alignent sur les objectifs métier afin que les résultats des performances reflètent la valeur utilisateur réelle.
Lors du test sous charge, incluez des appels d’API tiers réels. La simulation des dépendances externes rend les tests exécutés plus rapidement et de manière plus prévisible, mais il masque les problèmes de performances réels. Si votre application dépend d’une API de processeur de paiement, testez avec des appels réels pour comprendre la latence de bout en bout.
Utiliser les résultats des tests pour guider les décisions de conception
Vos résultats de test prennent des décisions de conception en établissant des lignes de base fiables et en guidant les efforts d’optimisation.
Établissez vos mesures de référence. Les lignes de base vous aident à identifier les tendances et les anomalies et à déterminer si les modifications d’optimisation offrent des améliorations. Vous avez besoin de bases de référence fiables pour suivre les tendances des performances au fil du temps.
Enregistrez les métriques de performances pendant les tests initiaux. Cet enregistrement est votre base de référence, un instantané des performances « normales ». Dans les exécutions suivantes, comparez de nouveaux résultats à cette ligne de base pour détecter les modifications de performances. Prenez en compte l’impact, la fréquence, le coût des correctifs et les risques de critères de modification lorsque vous examinez les données pour comprendre le comportement du système dans différentes conditions. Recherchez des modèles qui montrent où les performances se dégradent. Utilisez cet insight pour hiérarchiser les efforts d’optimisation.
L’optimisation est un processus itératif et doit être piloté par les données. Réservez un temps dédié dans votre cycle de développement pour l’optimisation des performances. Utilisez vos bases de référence pour mesurer l’impact des modifications et vous assurer qu’elles offrent les améliorations attendues sans introduire de régressions.
Mettre en corrélation les performances avec les métriques métier. Connectez les améliorations des performances aux résultats métier tels que le chiffre d’affaires, l’engagement des utilisateurs, la satisfaction des clients et le taux de conversion pour justifier un investissement continu dans l’optimisation des performances.
Note
Passez régulièrement en revue et mettez à jour vos lignes de base après des modifications significatives apportées à votre charge de travail, telles que les modifications architecturales, les nouvelles fonctionnalités ou les ajustements de mise à l’échelle. En effectuant cette action, vous vous assurez que vos objectifs de performances restent pertinents.
Maintenir les ressources de test alignées sur les modèles d’utilisation actuels
Vos ressources de test de performances contiennent des connaissances critiques sur le comportement attendu de votre charge de travail, les seuils de performances acceptables et les modèles de trafic réalistes.
Organisez les suites de test par type. Conservez les tests de charge, les tests de stress et les tests d’endurance dans des suites distinctes. Ne les mélangez pas. Chaque type a des exigences de configuration différentes, des durées d’exécution et des critères de réussite. Les suites organisées facilitent l’exécution de tests ciblés, comparent les résultats entre les exécutions et gèrent chaque suite indépendamment.
Actualisez régulièrement les données de test. Les données de test obsolètes entraînent des résultats irréalistes. Régénérez les données de test pour refléter les caractéristiques actuelles des données de production chaque fois que votre modèle de données change, que les volumes de données augmentent ou que les données démographiques évoluent.
Passez en revue les scénarios de test à mesure que votre charge de travail évolue. Planifiez des révisions régulières pour vous assurer que vos scénarios reflètent toujours l’utilisation réelle. Les scénarios deviennent obsolètes comme suit :
- Le comportement de l’utilisateur change au fil du temps
- Les modèles de trafic changent à mesure que votre base d’utilisateurs augmente
- De nouvelles fonctionnalités introduisent différents modèles d’utilisation
- Échelles d’infrastructure pour répondre aux nouvelles exigences de capacité
Facilitation Azure
Azure Pipelines vous permet d’intégrer des tests de performances dans votre pipeline CI/CD. Vous pouvez ajouter des tests de charge en tant qu’étape dans votre pipeline pour valider les performances et l’extensibilité de vos applications.
Azure Chaos Studio vous aide à injecter des erreurs réelles dans votre application afin de pouvoir exécuter des expériences d’injection de panne contrôlées. Les expériences vous aident à mesurer, comprendre et améliorer votre application cloud et votre résilience de service.
Test de charge Azure est un service de test de charge qui génère une charge à grande échelle sur n’importe quelle application. Load Testing fournit des fonctionnalités permettant d’automatiser les tests de charge et de les intégrer dans votre flux de travail d’intégration continue et de livraison continue (CI/CD). Vous pouvez définir des critères de test, tels que le temps de réponse moyen ou les seuils d’erreur, et arrêter automatiquement les tests de charge en fonction de conditions d’erreur spécifiques. Le test de charge offre un tableau de bord qui fournit des mises à jour actives et des métriques de ressources détaillées des composants d’application Azure pendant un test de charge. Vous pouvez analyser les résultats des tests, identifier les goulots d’étranglement des performances et comparer plusieurs exécutions de test pour comprendre les régressions de performances au fil du temps.
Azure Monitor est une solution de supervision complète pour collecter, analyser et répondre aux données de télémétrie à partir de vos environnements cloud et locaux. Application Insights est une extension de Monitor qui fournit des fonctionnalités APM. Vous pouvez utiliser Application Insights pour surveiller les applications pendant le développement et le test, et également en production.
Liens connexes
- Recommandations pour les tests de sécurité
- Recommandations pour la conception d’une stratégie de test de fiabilité
Liste de contrôle d’efficacité des performances
Reportez-vous à l’ensemble complet de recommandations.