Ce guide définit les exigences techniques pour planifier et exécuter des tests de performance avec Performance Testing Service (PTS). Respectez ces exigences pour évaluer la capacité réelle de votre système, prévenir les risques en production et valider la gestion par votre infrastructure des modèles de trafic attendus.
Périmètre
Ces exigences s'appliquent à tous les projets impliquant des tests de performance. Le guide aborde les points suivants :
Environnements système
Métriques de test
Modèles métier et modèles de test
Volume de données
Types de test
Sessions métier et scénarios
Surveillance et analyse des goulets d'étranglement
Optimisation
Tests de charge distribués avec PTS
Environnements système
Choisir un environnement
Les environnements système se répartissent entre production, test et autres environnements. Les tests de performance s'exécutent généralement dans un environnement de production ou un environnement de test dédié. Chaque option présente des compromis :
| Environnement | Avantages | Inconvénients |
|---|---|---|
| Production | Mesures précises sur l'infrastructure réelle | Nécessite le nettoyage des données de test ; risque pour les services actifs en cas de planification inadéquate |
| Test | Isolé du trafic actif ; risque maîtrisable | Coûteux pour répliquer la production à grande échelle ; les résultats peuvent ne pas refléter le comportement en production |
Environnement de production : exécutez les tests de charge pendant les heures creuses pour éviter d'affecter les services actifs. Les tests de charge full-link d'Alibaba Cloud offrent une approche plus efficace pour les tests en production. Après le test, nettoyez les données de test ou filtrez-les des rapports Business Intelligence (BI).
Environnement de test : dimensionnez-le à une fraction de l'échelle de production, typiquement la moitié, le quart ou un huitième. Les stratégies courantes incluent le déploiement de clusters de test séparés pour des applications spécifiques au sein de la production, ou le partage de bases de données entre environnements. Importez des données masquées depuis la production (généralement les 6 à 12 derniers mois) pour maintenir la pertinence des données.
Exigences de l'environnement de test
Alignez l'environnement de test sur la production autant que possible :
| Exigence | Détails |
|---|---|
| Architecture | Même architecture système que la production |
| Spécifications des instances | Mêmes types d'instances Elastic Compute Service (ECS) ou spécifications de conteneurs |
| Versions logicielles | Mêmes versions du système d'exploitation, des intergiciels, de la base de données et de l'application |
| Paramètres de configuration | Mêmes paramètres pour le système d'exploitation, les intergiciels, la base de données et l'application |
| Volume de données | Même ordre de grandeur que la production |
| Approche de mise à l'échelle | Réduisez le nombre de générateurs de charge et diminuez proportionnellement les autres ressources. Visez la moitié ou le quart de la configuration de production |
Examiner l'environnement de test
Avant le test, examinez chaque couche de l'environnement de test pour établir une ligne de base pour la surveillance et l'analyse des goulets d'étranglement :
| Couche | Éléments à examiner | Objectif |
|---|---|---|
| Architecture système | Composition du système, fonctions des couches, différences avec la production | Analyse des goulets d'étranglement et évaluation des performances en production |
| Système d'exploitation | Plateforme et version du système d'exploitation | Surveillance par les outils |
| Intergiciels | Types et versions des intergiciels | Surveillance par les outils et analyse des goulets d'étranglement |
| Base de données | Types et versions de la base de données | Surveillance par les outils et analyse des goulets d'étranglement |
| Application | Instances en cours d'exécution et leurs paramètres | Détection des problèmes et analyse des goulets d'étranglement |
Utilisez un outil Application Performance Management (APM) tel qu'Application Real-Time Monitoring Service (ARMS) pour tracer les problèmes à travers les couches intergiciel, base de données et application.
Métriques de test
Catégories de métriques
Suivez les métriques selon quatre catégories :
| Catégorie | Métriques clés |
|---|---|
| Métier | Utilisateurs simultanés, transactions par seconde (TPS), taux de réussite, temps de réponse (RT) |
| Ressource | Utilisation du CPU, utilisation de la mémoire, E/S disque, E/S réseau, paramètres du noyau (sémaphores, nombre de fichiers ouverts) |
| Application | Threads inactifs, connexions à la base de données, nombre de garbage collection (GC), nombre de full GC, durée des méthodes |
| Frontend | Temps de chargement de la page, temps de résolution DNS, temps de connexion, temps de transfert |
Définir les seuils de métriques
Définissez les seuils pour chaque métrique avant le test. Sans seuils clairs, les résultats du test manquent de sens opérationnel ; les différentes parties prenantes (développement, opérations, métier) ont des attentes différentes et se soucient de métriques distinctes.
Références pour les métriques métier :
| Métrique | Recommandation |
|---|---|
| Temps de réponse (RT) | Maintenez-le sous 1 seconde pour la plupart des services. Les systèmes haute performance comme Taobao atteignent généralement un RT de quelques dizaines de millisecondes. Spécifiez si votre seuil s'applique aux valeurs moyennes, médianes, p95 ou p99 ; agréger les temps de réponse en une simple moyenne peut masquer les pics de latence qui affectent les utilisateurs réels |
| TPS | Varie selon l'échelle du système : 50 à 1 000 pour les petites et moyennes entreprises, 1 000 à 50 000 pour les banques, 30 000 à 300 000 pour les plateformes à fort trafic comme Taobao |
| Taux de réussite | La norme industrielle dépasse 99,6 % sous charge |
Recommandations pour les métriques de ressources :
Limitez l'utilisation du CPU à 75 % ou moins
Évitez toute utilisation de la partition swap
Idéalement, lorsqu'un système atteint sa limite de capacité, une ressource (CPU, mémoire, E/S) devrait constituer le goulot d'étranglement plutôt qu'un problème au niveau de l'application. L'ajout de ressources à un système limité par les ressources augmente sa capacité ; l'ajout de ressources à un système limité par l'application n'a pas cet effet.
Modèles métier
Rôle des modèles métier
Chaque opération métier (connexion, recherche, paiement) consomme des quantités différentes de ressources système. Le mélange des types d'activités et leurs proportions relatives déterminent la capacité globale du système. Si le mélange de trafic de test ne correspond pas à la production, les résultats n'ont aucune valeur pratique.
Par exemple, dans le commerce électronique, différents types de promotions et catégories de produits modifient le ratio entre les opérations intensives en lecture et celles intensives en écriture. Une modélisation précise du trafic dans PTS capture ces modèles et révèle le véritable goulot d'étranglement du système.
Sélectionner les types d'activités
Choisissez les opérations métier à fort volume, à haut risque et à forte croissance comme cas de test représentatifs.
Pour les systèmes déjà en production :
Collectez les types d'activités et les volumes lors des différentes périodes de pointe. Si le mélange varie significativement selon les périodes, définissez plusieurs modèles métier.
Identifiez les fenêtres temporelles présentant une consommation élevée de ressources ou des anomalies pendant les heures de pointe, et investigatez leurs causes racines.
Passez en revue les incidents de production passés. Si un incident a été causé par une opération métier exclue des tests précédents, ajoutez-la aux futurs modèles de test.
Pour les systèmes non encore en production :
Déterminez les types d'activités et leurs proportions grâce aux entretiens avec les parties prenantes et à l'analyse des besoins.
Évaluez si certaines opérations métier pourraient connaître des pics lors de promotions ou d'événements.
Après les premières exécutions de test, examinez la consommation de ressources par opération. Si une opération à faible proportion consomme des ressources disproportionnées, ajustez son poids dans le modèle.
Volume de données
Volume de données de base
Le volume de données de base fait référence aux données existantes dans la base de données : historiques, données de référence et données métier accumulées. Le volume des données existantes affecte directement les performances des requêtes : une recherche parmi des milliers d'enregistrements se comporte très différemment d'une recherche parmi des millions.
Exigences :
Alignez le volume de données de l'environnement de test sur le même ordre de grandeur que la production.
Tenez compte de la croissance des données sur les trois prochaines années. Si les données croissent rapidement, chargez des données supplémentaires dans l'environnement de test.
Lors de l'insertion de comptes de test dans un environnement de production, planifiez une préparation minutieuse des données et une logique de nettoyage.
Les tests de charge full-link nécessitent également le même ordre de grandeur entre les environnements de test et de production.
Volume de données paramétrées
Les données paramétrées pilotent la variabilité des entrées de test (ID utilisateur, ID produit, termes de recherche). De petits jeux de données provoquent des hits en cache qui gonflent artificiellement les résultats de performance.
Exigences :
Maximisez le volume de données paramétrées. Si nécessaire, videz les caches ou générez des données supplémentaires par programme.
Répartissez les données paramétrées de manière réaliste. Si une opération métier présente des schémas de distribution géographique (par exemple, des requêtes d'inventaire spécifiques à une région), reflétez cela dans les données de test.
Modèles de test
Les modèles de test dérivent des modèles métier. Dans la plupart des cas, ils sont identiques. Toutefois, si une opération métier ne peut pas être simulée (en raison de contraintes techniques ou de politiques de sécurité), retirez-la du modèle de test et recalculez les proportions restantes.
Si une opération retirée présente un risque significatif (par exemple, un flux de paiement), évaluez ce risque séparément. Si le risque est élevé, trouvez une approche de test alternative plutôt que de simplement l'exclure.
Types de test
Les types de tests de performance se divisent en deux grandes catégories — tests de charge et tests de stress — avec plusieurs variantes spécialisées :
| Type de test | VUs / débit | Durée | Quand utiliser | Requis ? |
|---|---|---|---|---|
| Test de référence de transaction unique | Faible | Courte | Établir les performances de base pour des opérations individuelles | Optionnel |
| Test de charge de transaction unique | Incrémental | Moyenne | Évaluer la consommation de ressources pour une opération spécifique. Recommandé pour les systèmes non encore en production | Optionnel |
| Test de charge de transactions mixtes (test de capacité) | Production moyenne | Moyenne à longue | Déterminer la capacité globale du système sous des charges de travail mixtes réalistes | Requis |
| Test de stress de transactions mixtes | Supérieur à la moyenne | Moyenne | Trouver le point de rupture en poussant au-delà de la charge de pointe attendue | Optionnel |
| Test de mutation métier | Pic sur une seule opération | Courte | Valider le comportement du système lorsqu'une opération spécifique connaît un pic inattendu | Optionnel |
| Test de stabilité de transactions mixtes | Production moyenne | Longue (heures+) | Vérifier les performances soutenues sur de longues périodes | Requis |
| Test de fiabilité de transactions mixtes | Production moyenne | Longue | Tester le basculement, la récupération et la dégradation dans des conditions de défaut | Optionnel |
| Test par lots | Variable | Variable | Mesurer les performances du traitement par lots | Optionnel |
| Test d'impact des lots sur les transactions mixtes | Mixte | Longue | Évaluer comment les travaux par lots affectent les performances des transactions en ligne concurrentes | Optionnel |
Stratégie de progression
Commencez par les types de test les plus simples et progressez vers les plus complexes. Exécutez d'abord les tests de référence de transaction unique pour établir les lignes de base, puis passez aux tests de charge de transactions mixtes, et enfin aux tests de stress et de stabilité. Au minimum, exécutez les deux types requis : test de charge de transactions mixtes et test de stabilité de transactions mixtes.
Aucun type de test unique ne découvre tous les risques. Différents types de test ciblent différents modes de défaillance. Priorisez en fonction du profil de risque de votre système.
Sessions métier
Une session métier est une séquence ordonnée d'appels API représentant un workflow utilisateur complet. Par exemple, une session e-commerce typique pourrait suivre ce schéma :
Parcourir le catalogue de produits
Rechercher un produit spécifique
Ouvrir une page de détail du produit
Ajouter l'article au panier
Se connecter
Finaliser la commande
Effectuer le paiement
La précision de ces sessions affecte directement la capacité des tests à refléter les performances réelles.
Exigences :
Concevez les sessions en vous basant sur les règles métier réelles de la production et les workflows utilisateurs.
Incluez des pauses réalistes entre les étapes pour simuler le temps de réflexion de l'utilisateur. Sans temps de réflexion, le test génère des taux de requête irréalistes qui ne correspondent pas aux modèles de trafic de production.
Ajoutez des points de contrôle (assertions) aux étapes clés pour vérifier les réponses du serveur. Pour plus de détails, consultez Paramètres de réponse de l'interface
Paramétrez toutes les données variables (identifiants utilisateur, ID produit, requêtes de recherche) et maximisez le volume de données.
Scénarios
Un scénario de test de charge combine plusieurs appels API HTTP/HTTPS ou URL en une charge de travail simulant le trafic réel de production. Chaque scénario définit le profil de charge : mode de pression, méthode de montée en charge et durée.
L'exigence critique : la proportion de TPS de chaque opération métier dans le test doit correspondre à la proportion métier réelle pendant les heures de pointe de production.
Mode RPS et mode concurrence
PTS prend en charge deux modes de charge. Choisissez le mode qui correspond à la façon dont votre système reçoit le trafic réel :
Modèle de charge ouverte (mode RPS -- recommandé) : vous contrôlez le taux d'arrivée des requêtes. Utilisez ce mode lorsque votre système fait face à un trafic entrant non contrôlé, comme une application web publique. C'est le scénario le plus courant.
Modèle de charge fermée (mode concurrence) : vous contrôlez le nombre d'utilisateurs simultanés. Utilisez ce mode lorsque votre système contrôle l'admission, comme un centre d'appels avec un nombre fixe d'agents.
Si votre système réel fonctionne en charge ouverte mais que vous testez avec un modèle de charge fermée, les résultats du test ne reflètent pas le comportement réel en production. Le modèle de concurrence limite implicitement les taux de requête en fonction du temps de réponse, ce qui masque les problèmes de performance qui apparaissent sous des conditions de trafic réelles.
Exemple : deux interfaces A et B ont un ratio de production de 1:4, avec des temps de réponse respectifs de 1 ms et 100 ms.
| Mode | Configuration | Résultat |
|---|---|---|
| Mode RPS (recommandé) | Définir A à 100 RPS, B à 400 RPS | Ratio direct 1:4. Le modèle métier correspond à la production |
| Mode concurrence | Définir A à 1 utilisateur simultané, B à 400 utilisateurs simultanés | Doit compenser la différence de RT de 100x. Le ratio devient 1:400 en concurrence pour atteindre 1:4 en débit |
Le mode RPS élimine le besoin de calculer des ajustements de concurrence basés sur les différences de temps de réponse, offrant un contrôle plus précis sur le mélange de trafic.
Surveillance
Importance d'une surveillance complète
La surveillance pendant les tests de performance sert deux objectifs : détection des goulets d'étranglement en temps réel et analyse des causes racines après le test. Sans métriques complètes sur toutes les couches, identifier la source d'un goulot d'étranglement relève de la conjecture.
Métriques à surveiller
| Couche | Métriques clés |
|---|---|
| Système d'exploitation | Utilisation du CPU (User, Sys, Wait, Idle), utilisation de la mémoire (y compris swap), E/S disque, E/S réseau, paramètres du noyau |
| Intergiciels | Pools de threads, pools de connexions Java Database Connectivity (JDBC), métriques Java Virtual Machine (JVM) (fréquence GC, fréquence full GC, taille du heap) |
| Base de données | Requêtes SQL lentes, verrous, taux de hit du cache, sessions, nombre de processus |
| Application | Durée des méthodes, traitement synchrone vs asynchrone, mise en tampon, comportement du cache |
Analyse des goulets d'étranglement
Les goulets d'étranglement de performance tombent généralement dans quatre catégories : ressources du système d'exploitation, configuration des intergiciels, problèmes de base de données et logique applicative.
Focus d'analyse par couche
| Couche | Points d'attention |
|---|---|
| Système d'exploitation | CPU, mémoire, E/S disque, E/S réseau |
| Intergiciels | Pools de threads, pools de connexions JDBC, métriques JVM (fréquence GC, fréquence full GC, taille du heap) |
| Base de données | Requêtes SQL lentes, attentes de verrou, interblocages, taux de hit du cache, sessions, nombre de processus |
| Application | Durée des méthodes, efficacité des algorithmes, traitement synchrone vs asynchrone, utilisation du cache, mise en tampon |
| Générateur de charge | Consommation de ressources sur les machines génératrices de charge. Dans la plupart des cas, les générateurs de charge sont peu susceptibles d'être le goulot d'étranglement. PTS dispose de mécanismes de protection et de planification intégrés qui gèrent cela automatiquement |
Une analyse ciblée à chaque couche permet une optimisation efficace : corrigez le véritable goulot d'étranglement plutôt que d'ajouter des ressources sans impact.
Optimisation
Après avoir identifié les goulets d'étranglement, optimisez le système et relancez les tests pour vérifier les améliorations. Les domaines d'optimisation courants incluent :
| Couche | Cibles d'optimisation |
|---|---|
| Intergiciels | Tailles des pools de threads, tailles des pools de connexions à la base de données, paramètres JVM |
| Base de données | Optimisation des requêtes SQL lentes, résolution des interblocages et attentes de verrou, amélioration du taux de hit du cache, ajustements des paramètres de processus et de sessions |
| Application | Temps d'exécution des méthodes, optimisation des algorithmes, conversion synchrone vers asynchrone, stratégie de cache, dimensionnement des tampons |
| Ressources système | Une consommation élevée de CPU ou de mémoire est généralement causée par des paramètres d'application ou des configurations de paramètres sous-optimaux, et non par un manque de matériel. Traitez les problèmes au niveau de l'application avant de mettre à l'échelle les ressources |
Tests de charge distribués avec PTS
Performance Testing Service (PTS) est une plateforme SaaS pour les tests de charge distribués. Aucune installation ou déploiement supplémentaire n'est requis.
Simulation de trafic
PTS génère le trafic de test à partir de nœuds Content Delivery Network (CDN) dans des centaines de villes et auprès de plusieurs opérateurs dans le monde entier. Cette approche simule des modèles d'accès utilisateur réalistes, y compris la distribution géographique et le routage spécifique aux opérateurs.
Conception de scénario
-
Enregistrez les scénarios à l'aide de plugins d'enregistrement de navigateurs grand public, ou orchestrez l'exécution séquentielle et parallèle des API via une interface visuelle, sans codage requis.
Paramétrez les requêtes à l'aide de fichiers de données, de fonctions intégrées, d'opérations sur les chaînes et d'extraction de réponses. PTS sert de fabrique de données qui formate les paramètres de requête via un encodage simple.
Maintenez l'état des cookies et des sessions à travers les appels API, avec des instructions extensibles prenant en charge le temps de réflexion multi-formulaire et la régulation du trafic.
Déboguez les scénarios et les API individuelles avant d'exécuter des tests à grande échelle.
Contrôle de charge
Deux modes de charge : mode concurrence et mode requêtes par seconde (RPS)
Démarrage rapide : lancez les tests de charge en quelques minutes
Ajustement en temps réel : les changements de trafic prennent effet en quelques secondes
Capacité d'impulsion : générez des pics instantanés de millions de requêtes par seconde (QPS)
Contrôles de sécurité : arrêtez immédiatement le trafic de test de charge si nécessaire
Rapports
PTS collecte des données en temps réel pendant chaque test, y compris la concurrence, les TPS, le RT et les journaux échantillonnés pour chaque API. Les rapports sont générés automatiquement pour l'analyse post-test.
Industries prises en charge
PTS prend en charge les charges de travail dans le commerce électronique, les médias, la finance et l'assurance, la logistique, la publicité et le marketing, ainsi que les réseaux sociaux.