Analyse et utilisation des tests de performance

Analyse et utilisation des tests de performance

1. Pourquoi tester les performances ?

Le système xx a été lancé avec succès. Selon la planification du projet précédent, il est prévu de servir plus de 1000 clients. À l'avenir, il y aura inévitablement une tendance à la croissance massive des informations dans le système d'entreprise.
Au fur et à mesure que le système devient plus stable en production, cela nous permet de nous concentrer davantage sur les problèmes de performances :

1. Quelle quantité de données peut être tolérée ?

2. Quel est le goulot d'étranglement du système ?

3. Comment est la qualité du code ?

   Ces questions doivent être résolues par des tests de performance

2. À quoi faut-il faire attention ?

1. Clarifier le but du test

性能测试的目的分为两种：

• Vérification : vérifiez que le système est conforme aux exigences de performance pertinentes. Tels que : pour répondre aux demandes simultanées de 500 personnes

• Positionnement et réglage : obtenez des données pertinentes grâce à des tests, puis analysez, positionnez et réglez les données.

2. Déterminer le contenu du test

• Clarifier les points et les priorités de l'entreprise

• Selon la priorité de la fonction et de la performance pour diviser le niveau de priorité de l'entreprise, déterminer l'entreprise à tester et l'entreprise non testée

• Déterminer les exigences de performance pertinentes pour différentes entreprises et scénarios : débit, temps de réponse, etc.

3. Comprendre la catégorie des tests de performance

1. Tests au niveau du réseau Tests actuels

   Débit et temps de réponse

2. test du système d'exploitation

   utilisation du processeur, taux d'échange de disque

3. Test au niveau de la base de données

   Le nombre de connexions simultanées à la base de données, le nombre de ressources de verrouillage utilisées et la taille du trafic d'E/S

4. Facteurs affectés

1. Bande passante réseau telle que : Ali 50M 100M

2. Le nombre de serveurs tels que : serveur Aliyun

3. Processeur du serveur, mémoire et autres performances telles que : disque SSD 2G 8G d'Ali, disque dur mécanique

4. Version du système d'exploitation du serveur

5. qualité du code

3. Fonctionnement de base

Jmeter utilise l'adresse en ligne du document : [https://blog.csdn.net/r657225738/article/details/114981779]{.underline}

1. Requête http simple

2. Variables utilisateur personnalisées

3. Extrayez les données de la demande et stockez-les dans le fichier

Scénario : ajout par lot, requête par lot
composants requis : [extracteur d'expression régulière-> programme de post-traitement BeanShell] Remarque :
encodage du texte : utf-8

4. Utilisez le fichier CSV pour lire les données

Scénario : modification par lots, suppression par lots

Composants requis : [Configuration du fichier de données CSV]

4. Utilisez les données pour parler

1. Comparaison avant et après optimisation du code

问题列表-我的问题

---

2. L'écart de performance entre les copies simples et doubles

5. Résumé de l'expérience

1. Idées d'optimisation de code

Afficher les journaux d'opérations de l'API via le suivi des liens APM

• 1. Réduire les accès inutiles à la bibliothèque

  2. Réduisez les appels de données inutiles

Exemple : Liste des problèmes - Mes problèmes avant et après la mise à jour

Grâce aux tests et au réglage du code, il y a deux points qui nécessitent l'attention de tous

• 1. Outil de test : Jemter pour les tests simultanés

  2. Emplacement du problème : l'API spécifique trouve la direction du code d'optimisation via le suivi des liens intranet APM

arriver à la conclusion :

1. Dans le test de simultanéité, l'asynchronisme de l'API améliore directement les performances. Si l'API n'est pas écrite de manière asynchrone avec une simultanéité de 20, le débit peut être inférieur à un chiffre. Une fois l'API modifiée en tâche asynchrone, avec une simultanéité de 100, le débit peut atteindre 150-200

2. La suppression des accès API inutiles dans le code peut continuer à améliorer les performances, et l'amélioration des performances est évidente. (Lié au nombre d'accès API non pertinents supprimés) Dans le test, 100 simultanéité, le débit peut atteindre 200-250

2. Solution d'erreur d'API lors du test de performance

在保证API地址与参数填写正确的情况下,如还报错则为以下两种情况

1. Rapport API 500

1.1数据库崩溃,卡死,需要重启

2. L'API signale 404

2.1所在企业Api服务卡死,需要重启

Six. Peu de connaissances

6.1 Signification des paramètres dans le rapport d'agrégation

• Valeur minimale : fait référence au temps minimum requis pour retourner les données après la demande au serveur

• Valeur maximale : fait référence au temps maximum nécessaire pour retourner les données après l'envoi de la requête au serveur

• Valeur anormale : fait référence à la proportion de requêtes qui seront déconnectées ou connectées anormalement

• TPS (débit) : fait référence au nombre de requêtes pouvant être traitées par seconde, par exemple 120/sec, c'est-à-dire que 120 requêtes réseau peuvent être traitées par seconde. 20/min, c'est-à-dire par minute

• Moyenne : fait référence à la moyenne de la somme de tous les temps de réponse des requêtes

• 99% : Cela signifie que 99% des requêtes sont en dessous de cette plage, comme 354ms / 99%, c'est-à-dire que 99% des requêtes terminent la réponse avant 354ms

6.2 Accroître le rôle de Répliqué (copie) / Échelle (échelle)

1. Comprenez par vous-même : Docker passera moins de temps à créer une nouvelle instance sur un autre nœud lorsqu'une défaillance se produit, ce qui contribue à améliorer les performances et à réduire les taux d'échec. Par exemple, il existe actuellement trois copies (répliquées), lorsqu'une des copies (Serveur) sera automatiquement transféré vers une copie disponible lorsqu'il ne pourra pas le supporter.

2. Explication professionnelle : Prenons comme exemple une copie contenant une seule instance. Maintenant, supposons qu'il y ait un échec. Docker Swarm remarquera que le service a échoué et le redémarrera. Le service va redémarrer, mais le redémarrage n'est pas instantané. Disons qu'il faut 5 secondes pour redémarrer. Pendant ces 5 secondes, votre service est indisponible. point de défaillance unique.

Que faire si votre réplica contient 3 instances. Désormais, lorsque l'une d'elles échoue (pas de service parfait), Docker Swarm remarquera que l'une des instances est indisponible et en créera une nouvelle. Pendant ce temps, vous avez encore 2 instances saines qui traitent les requêtes. Pour les utilisateurs de votre service, il ne semble pas y avoir de temps d'arrêt. Ce composant n'est plus un point de défaillance unique.

6.3 Règles d'ordonnancement des barèmes

将node1宕机后或将node1的docker服务关闭，那么它上面的task实例就会转移到别的节点上。当node1节点恢复后，它转移出去的task实例不会主动转移回来，只能等别的节点出现故障后转移task实例到它的上面。使用命令\"docker node ls\"，发现node1节点已不在swarm集群中了。

6.4 Signification populaire de la haute simultanéité

Par exemple, disons que vous ouvrez un snack-bar.

Vous avez 3 caissiers (fils de traitement des requêtes web), 5 chefs (connexions à la base de données).

Au début, l'affaire n'a pas duré longtemps. Il y a moins d'invités. 1 caisse enregistreuse peut le gérer. D'autres sont encore inactifs.

Plus tard, les affaires allaient de mieux en mieux. Ainsi, les 3 caisses enregistreuses fonctionnent (simultanément).

En conséquence, au bout d'un moment, une célébrité Internet est arrivée, et tout à coup le magasin est devenu populaire, et un grand groupe de personnes (haute simultanéité) est venu ici avec admiration.

En conséquence, les 3 caissiers avaient une longue file d'attente avec de grands noms devant eux (les demandes étaient bloquées et mises en file d'attente), et les caissiers n'étaient pas des robots, et parfois ils faisaient des erreurs dans la commande (exceptions simultanées).

En regardant le chef à l'arrière, il y a de plus en plus de commandes. Le chef a cuisiné et cuisiné, et il est de plus en plus fatigué, et la cuisine est de plus en plus lente (la pression sur la base de données est élevée, et le temps de réponse à la demande s'allonge).

Plus les plats sortent lentement, plus les gens feront la queue derrière (cercle vicieux après le blocage de la demande).

Certains clients sont partis sans attendre (le service faisait des heures supplémentaires), et vous ont même donné une mauvaise critique, ce qui a affecté leur humeur (affecté le service de niveau supérieur).

Quant au chef derrière, après avoir fait N plats, il n'en pouvait finalement plus, et ne pouvait plus le faire (la connexion à la base de données était épuisée).

Ainsi, la petite boutique ne peut que suspendre la prise en charge des clients (le serveur rejette la demande et signale l'erreur 502).

6.5 Signification commune du débit et du nombre simultané

Cas 1 : le débit et la simultanéité sont deux concepts totalement indépendants. Prenons l'exemple du guichet de la banque. Les décomptes simultanés font référence au nombre de personnes qui se précipitent au guichet de la banque en même temps. Le taux de débit fait référence au nombre de personnes que le guichet bancaire peut servir sur une période de temps

Cas 2 : Un robinet est ouvert pendant un jour et une nuit et 10 tonnes d'eau s'écoulent ; 10 robinets sont ouverts pendant 1 seconde et 0,1 tonne d'eau s'écoule. Bien sûr, le débit d'un tap est important. Pouvez-vous dire que la capacité de sortie d'eau d'un robinet est meilleure que celle de 10 robinets ? Par conséquent, nous devons ajouter l'unité de temps pour voir qui a le plus d'eau en 1 seconde. C'est le débit de 0,1 tonne d'eau/seconde
, erreur 502).