Test de performance - Quelles sont les raisons pour lesquelles le TPS ne peut pas monter ? 【Multi-testeur de Hangzhou_Wang monsieur】【Multi-testeur de Hangzhou】

1. Bande passante du réseau
Dans le test de résistance, il faut parfois simuler un grand nombre de demandes d'utilisateurs. Si les paquets de données transmis par unité de temps sont trop volumineux et dépassent la capacité de transmission de la bande passante, cela entraînera une concurrence pour les ressources du réseau, ce qui entraînera demandes reçues par le serveur. Le nombre n'atteint pas la limite supérieure de la capacité de traitement du serveur.
2. Le nombre de connexions disponibles dans le pool de connexions est trop petit, ce qui fait attendre les demandes. Les pools de connexion sont généralement divisés en pools de connexion de serveur (tels que Tomcat) et pools de connexion de base de données (ou compris comme le nombre maximal de connexions autorisées). Les connexions longues ne sont pas maintenues et les connexions TCP sont fréquemment interrompues. 3. Si l'allocation de mémoire du tas de GC est déraisonnable,
cela
conduira à des gc fréquents, et gc provoquera une suspension de thread. En particulier, fullgc entraînera une suspension à long terme des threads, des échecs de code, l'utilisation de la méthode contenant de la liste pour traverser et dédupliquer, le blocage des threads ou l'échec de l'allocation de mémoire
jvm, un fullgc fréquent, un débordement de mémoire
4.
Dans le cas d'une concurrence élevée dans configuration de la base de données, si demande de données Lorsque vous avez besoin d'écrire dans la base de données et devez écrire dans plusieurs tables, le nombre maximal de connexions à la base de données n'est pas suffisant, ou le SQL pour écrire des données n'a pas d'index, ou il n'y a pas de maître- séparation des esclaves, séparation lecture-écriture, ce qui ralentira le traitement des transactions de la base de données. Certaines bases de données ne sont pas indexées et l'espace de cache de la base de données est insuffisant, ce qui affectera également le TPS.
5. Les ressources matérielles
comprennent le processeur (configuration, taux d'utilisation, etc.), la mémoire (taux d'occupation, etc.), le disque (E/S, échange de pages, etc.) 6. La
capacité de charge d'une seule presse est limitée, si le nombre de demandes d' utilisateurs à simuler dépasse sa charge La limite affectera le TPS (un test de pression distribué est nécessaire pour résoudre le problème à ce moment
) . Le hachage n'est pas fusionné, le cache est en panne et une seule commande prend trop de temps. 8. Parmi les ressources matérielles, les ressources du processeur et du serveur de mémoire sont insuffisantes, la commutation de contexte est trop rapide, les interruptions sont trop élevées et les échanges de swap sont fréquent



Lorsque la pression est élevée, le tps fluctue fréquemment, provoquant l'échec du tps total. Vérifiez s'il y a fullgc (tail -f gc_mSrv1.log | grep full) Si
le paramètre de rythme est trop petit, cela entraînera également l'échec du tps. Pour les transactions avec une grande gigue, ajoutez plus d'utilisateurs.
La gigue tps et la transaction gigue à pression unique se sont avérées très stables. À ce moment-là, on soupçonnait qu'elle était causée par trop de pression, donc lorsque la capacité a été émise, la transaction avec le plus de pression a été allouée à d'autres presses, puis le tps n'a pas tremblé. Remarque : plusieurs appuis n'affectent que la gigue tps, pas le processeur du serveur. Vérifiez si le temps de réponse a expiré et si le nombre d'utilisateurs est suffisant.