Méthodologie de test de pression et d'analyse de performance
Principes de base des tests de performance
Classifications communes des tests de performance
Test de performance. Il est utilisé pour vérifier si les performances du système répondent aux attentes de conception. D'une manière générale, la pression sur le système sera relativement faible et le système ne sera pas écrasé. C'est juste une simple vérification.
test de chargement. En appliquant en permanence une pression de charge, nous recherchons la capacité de traitement optimale et le meilleur état de performance du système pour atteindre l'indice de performance maximal. De manière générale, les résultats des tests de charge sont un peu supérieurs aux résultats des tests de performances.
Essai de stabilité. Il peut être considéré comme un sous-ensemble de tests de charge, appliquant une pression inégale pendant une longue période, puis vérifiant si tous les indicateurs du système sont normaux.
Test de résistance : c'est courant pour nous. Généralement, nous appelons cela un test de résistance, qui est utilisé pour déterminer la capacité maximale que le système peut supporter. Le test de résistance appuie généralement au point maximum que le système peut supporter, puis tire une conclusion de pointe.
Type de mesure de pression et mode d'application de pression
Il existe généralement deux types de tests de résistance : les tests de résistance à service unique et les tests de résistance à lien complet.
Il existe deux façons courantes d'appliquer une pression :
Mode simultané (simulant le mode utilisateur du point de vue de l'utilisateur)
La simultanéité fait référence au nombre d'utilisateurs simultanés. D'un point de vue commercial, le nombre d'utilisateurs en ligne simultanés est simulé pour atteindre le niveau de simultanéité attendu. Pour calculer le débit, une conversion est requise. Mais dans certains scénarios, c'est plus conforme aux attentes de la scène
Mode RPS (simule le mode de débit en termes de débit demandé)
RPS (Requests Per Second) fait référence au nombre de requêtes par seconde. Le mode RPS est "mode de débit". En définissant le nombre de requêtes envoyées par seconde, du point de vue du serveur, la capacité de débit du système peut être directement mesurée, éliminant ainsi la conversion fastidieuse du mode simultané au RPS, et cela peut être fait en une seule étape.
Pratique de test de performance avancée Jmeter
Le mode simultané et le mode RPS n'ont ni avantages ni inconvénients, et chacun a ses propres scénarios applicables.
Outils de test de résistance courants
Les outils de mesure de pression couramment utilisés sont les suivants :
· wrk : https://github.com/wg/wrk
· ab : https://httpd.apache.org/docs/2.4/programs/ab.html
· banc web
Performance
Indicateurs de performance communs
Indicateurs métier : simultanéité, débit, temps de réponse
nombre simultané. Il fait référence au nombre de demandes traitées par le système en même temps. Pour les systèmes Internet , il fait généralement référence au nombre d'utilisateurs qui accèdent au système en même temps.
Débit (valeur maximale de QPS) : fait référence au nombre de requêtes traitées par le système par unité de temps, reflétant la capacité de traitement du système. Nous utilisons généralement des indicateurs tels que TPS et QPS pour mesurer. Le débit peut également être divisé en débit moyen, débit de pointe et débit minimum.
Temps de réponse : Le temps de traitement d'une transaction. Il fait généralement référence à l'intervalle de temps entre l'envoi d'une demande, le retour du serveur après le traitement et la réception des données de réponse. Généralement, il existe un temps de réponse moyen, P95 et P99.
Le temps de réponse et le débit doivent atteindre un point d'équilibre. À mesure que le débit augmente, le temps de réponse maintiendra d'abord un certain point, puis commencera à augmenter rapidement, suivi par le débit difficile à augmenter. Nous avons des exigences en matière de temps de réponse, nous ne pouvons donc pas simplement rechercher le débit, nous devons trouver le débit maximal dans un délai de réponse raisonnable.
Le temps de réponse doit être basé sur le taux de réussite. En cas d'échec, le temps de réponse n'est pas valide. Le taux de réussite est généralement de 100 %.
La relation entre eux est :
QPS (TPS) = nombre simultané / temps de réponse moyen
Valeur théorique du débit = nombre de concurrents/temps de réponse moyen
Nombre simultané = RPS * temps de réponse moyen
Ressources système : taux d'inactivité du processeur, utilisation de la mémoire, E/S réseau, volume de lecture et d'écriture du disque, nombre de poignées, etc.
Les compteurs de performances font référence à certaines données d'indicateurs de performances du serveur ou du système d'exploitation, notamment la charge système, le nombre d'objets et de threads, l'utilisation de la mémoire, l'utilisation du processeur, l'utilisation des E/S du disque et du réseau et d'autres indicateurs . Ces indicateurs sont des paramètres importants pour la surveillance du système, reflétant certains indicateurs clés de la charge du système et de la capacité de traitement, et généralement ces indicateurs sont fortement corrélés aux performances. Ces indicateurs sont élevés, deviennent un goulot d'étranglement et indiquent généralement qu'il peut y avoir des problèmes de performances.
La meilleure façon est d'utiliser le pourcentage
Il n'est pas fiable de se référer à la valeur moyenne. La méthode statistique la plus correcte consiste à utiliser des statistiques de distribution en pourcentage. La meilleure pratique consiste à utiliser des pourcentages. Par exemple, l'indicateur Top Percentile (TP), TP50 signifie que 50% des demandes sont inférieures à une certaine valeur, et TP90 signifie que 90% des demandes sont inférieures à un certain temps.
Indicateurs d'observation de mesure de pression
Quel que soit le type de stress test, les indicateurs à observer dans le stress test doivent généralement inclure :
· Taux de réussite, taux d'échec
· Ressources système (CPU, mémoire, bande passante, IO)
Temps de réponse , temps de réponse moyen, temps de réponse P95/P99, vous devez faire attention à P95 et P99, pas seulement au temps moyen, le temps P99 peut mieux juger de l'expérience temporelle des utilisateurs en ligne
· Débit (RPS/TPS)
Voici un exemple de données de mesure de pression de base :
Téléchargement en cours... Retélécharger Annuler
Générez des rapports de tests de résistance rigoureux
Lorsque nous analysons les problèmes de performance du système, nous devons trouver les points clés. Cela nécessite que notre rapport de stress test soit vraiment efficace, très rigoureux et clair. Nous devons analyser le goulot d'étranglement étape par étape, et nous devons comprendre pourquoi le goulot d'étranglement est atteint. , et ensuite comment l'optimiser. ? Par conséquent, nous sommes tenus de produire un rapport de test de résistance rigoureux. Voici quelques expériences :
Lors des stress tests, il est nécessaire de trouver un point d'inflexion de performance ; si la pression atteint le goulot d'étranglement dès que la pression monte, alors il faut reculer un peu jusqu'à trouver un point d'inflexion de performance optimal. Les performances du système sont de forme parabolique. Continuer à appliquer une pression après avoir atteint le pic de performances entraînera une dégradation des performances. Par conséquent, la chose la plus importante pour notre test de résistance est de trouver le meilleur point d'inflexion des performances. Par conséquent, la pression est appliquée progressivement pendant tout le processus d'application de la pression et la pression se poursuit après avoir atteint le pic de performance. Si la performance n'augmente pas mais diminue après avoir continué à appliquer la pression, cela signifie que le point d'inflexion a été atteint.
Comment analyser le goulot d'étranglement des performances et trouver la raison pour laquelle le QPS ne peut pas être amélioré ?
Le QPS n'augmentera pas tout le temps, après un certain point, il sera plat ou même en baisse, et il y aura un point d'inflexion des performances. A ce moment, il est nécessaire de commencer à analyser les raisons.
La méthode spécifique consiste à capturer d'abord la situation du profil (cpu, bloc, io, mémoire) qui n'a pas atteint la limite, puis saisir celle qui vient d'atteindre la limite, et enfin saisir celle qui a dépassé la limite, puis analysez quelles ressources système se trouvent dans ces situations ou si l'interface externe cause des problèmes de performances.
Si un certain composant ou service externe est le point de goulot d'étranglement des performances, une analyse plus approfondie est nécessaire. Ne gère-t-il pas le nombre de connexions ? On ne peut pas dire que le problème est résolu une fois qu'un certain composant est trouvé, et un examen plus approfondi et plus approfondi est nécessaire.
Connaître les performances et les points d'inflexion que le stand - alone et le cluster peuvent porter respectivement
Quel est le RPS maximal d'une seule machine ?
Quel est le QPS après une expansion parallèle ? Est-ce une croissance linéaire ? (Il ne croîtra certainement pas de manière linéaire. Après un certain niveau, il y aura des goulots d'étranglement dans les ressources associées. La clé est de trouver les points de goulot d'étranglement correspondants)
Comment analyser les ressources système, prenez le CPU comme exemple
Regardez d'abord le CPU. Si le CPU n'est pas plein, cela signifie que le problème n'est pas le CPU, donc vous n'avez pas besoin de vous soucier du CPU, et ensuite vous avez besoin d'autres ressources telles que io, swap, mémoire, carte réseau, etc...
S'il y a plusieurs cœurs de processeur, observez l'utilisation du processeur de chaque cœur au lieu de l'utilisation globale du processeur.
Si le processeur fonctionne à pleine capacité, saisissez le profil du processeur et observez les appels qui prennent le plus de temps.
Faire un bon travail d'estimation de capacité
Avant que le système ne soit mis en ligne, il est nécessaire de pouvoir avoir une estimation/évaluation, puis de passer la vérification du test de pression pour comprendre chaque détail, y compris les ressources, les dépendances, le déploiement, la distribution de la salle informatique, la stratégie de rétrogradation, le plan de reprise après sinistre, la sauvegarde plan
L'estimation de la capacité est indispensable pour qu'un système à grande échelle soit mis en ligne, car ce n'est qu'en faisant une estimation raisonnable de la capacité que nous pourrons mieux concevoir notre système en fonction du niveau de charge du système. Vivez plus de trafic ; une fois que le plan est correct, nous devons utiliser des méthodes de test de performance pour vérifier s'il répond aux attentes. Après une planification et une évaluation raisonnables de la capacité, nous ne pouvons que savoir à quel point nous devons insister lorsque nous allons au système de test de pression avant de passer en ligne. Ensuite, l'estimation de la capacité n'est pas une gifle. L'évaluation de la capacité doit prendre en compte les éléments suivants points:
1. Obtenir des indicateurs commerciaux et évaluer le nombre total de visites.
Renseignez-vous sur les produits et les opérations pour obtenir des indicateurs uv, pv et autres.
2. Évaluez le RPS moyen des visites.
86400 secondes par jour, on considère généralement que la requête a lieu dans la journée, soit 4w secondes.
Le montant total est divisé par le temps total, et un jour est compté comme 4w secondes.
3. Évaluez le RPS maximal.
Lors de la planification de la capacité du système, nous ne devons pas seulement prendre en compte le QPS moyen, mais aussi le QPS maximal.
Selon le diagramme de la courbe d'activité.
En règle générale, le RPS maximal est 3 à 4 fois supérieur au RPS moyen.
4. Évaluer les indicateurs pertinents de chaque module et sous-système dans l'ensemble du système d'entreprise.
5. Évaluez le système, la limite QPS autonome et évaluez le nombre de machines nécessaires.
Effectuer des tests de résistance et des analyses de données.
6. Redondance appropriée Pour les résultats obtenus à partir du test de résistance, nous devons faire une certaine redondance après le lancement effectif, afin d'éviter le fait que la pression en ligne réelle soit trop importante pour provoquer une expansion rapide.
Faire un bon travail d'analyse et de synthèse
Faites un bon travail d'analyse et de synthèse, par exemple :
Une fois ce système mis en ligne, sera-t-il vraiment capable d'y résister ? En plus d'avoir des données de test de résistance, vous devez également avoir vos propres estimations. Dans votre propre système, quels aspects peuvent avoir des goulots d'étranglement, lesquels poseront des problèmes après la mise en ligne ? Il doit y avoir une préparation suffisante et une évaluation/estimation globale avant que le système ne soit mis en ligne.
Une fois le système en ligne, que dois-je faire si je ne peux pas le gérer ? Existe-t-il un système de limitation de débit ? Existe-t-il une option de rétrogradation ?
Quelle est la situation actuelle du système avec 100 000 utilisateurs ? Donc, si la situation est de 10 millions d'utilisateurs, est-ce une croissance linéaire ? Quelles considérations doivent être prises ?
Avant que le système ne soit mis en ligne, il est nécessaire de pouvoir avoir une estimation/évaluation, puis de passer la vérification du test de pression pour comprendre chaque détail, y compris les ressources, les dépendances, le déploiement, la distribution de la salle informatique, la stratégie de rétrogradation, le plan de reprise après sinistre, la sauvegarde plan
Méthodes de mesure de pression pour certains cas particuliers
Préparation des données de test
Des données de test de haute qualité doivent pouvoir refléter véritablement les scénarios d'utilisation de l'utilisateur. Nous choisissons généralement des données réelles en ligne comme source de données, après échantillonnage, filtrage et désensibilisation, comme données de test pour les tests de performance. Mais avant de tester avec des données réelles, vous devez d'abord simuler les données de test hors ligne, au moins vérifier les exigences de performances de base de l'ensemble du système avant d'utiliser des données réelles pour les tests de performances.
Méthode de test de stress pour la couche de stockage ( base de données et cache)
Pour les services sans état, il est facile d'améliorer la capacité de simultanéité, et la capacité peut être étendue sans réfléchir. Mais pour un système de stockage avec état, le nombre maximum de simultanéité qu'il peut prendre en charge n'est pas évolutif à l'infini, nous devons donc être en mesure de comprendre à quel point notre couche de stockage de données peut résister, et le test de pression pour ce type de cluster de stockage est généralement :
· Appuyez sur le test sur une seule machine d'abord
Ensuite, analysez la capacité globale du cluster. Il convient de noter que la capacité que le cluster peut supporter n'est pas la valeur cumulée d'une seule machine. Généralement, chaque fois qu'une machine est ajoutée au cluster, elle peut être grossièrement évaluée par 80 % méthode décroissante.
Enfin , il convient de noter que la capacité globale du cluster doit atteindre une configuration raisonnable en fonction de la situation réelle, non que plus il y a de machines dans le cluster, mieux c'est. Appuyez sur une valeur qui répond aux attentes.
Pratique de test de performance avancée Jmeter
Tutoriel d'artefact de capture de paquets d'interface Fiddler