Prémisse :
1. L'entreprise a effectué un test de stress sur une machine déployée avec le service http Le premier jour, le test a été effectué pendant une nuit (10h) (200 simultanées à la fois), et le débit était d'environ. 56%. Le lendemain (tomcat n'a pas été redémarré pendant cette période), un test de nuit (10 heures) (200 simultanéités à la fois) a également été réalisé, mais le débit a chuté à environ 16 %. L'environnement est le même, pourquoi l'écart est-il si grand ?
2. Lorsque j'ai testé 1 000 simultanéités le premier jour, le nombre de threads était d'environ 1 000+, mais le deuxième jour (je n'ai pas redémarré Tomcat pendant cette période), lorsque j'ai testé 1 000 simultanéités, le nombre de threads est tombé à 700+. Pourquoi le nombre de threads est-il tombé à 700+ auparavant ? C'est directement proportionnel au nombre de threads, mais pas plus tard ?
Pour les deux prémisses ci-dessus, Tomcat a-t-il des stratégies, ou le pool de connexions jdbc ou le pool de connexions redis provoque-t-il le phénomène ci-dessus (en utilisant le mécanisme de recyclage G1) ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Cette situation est compliquée. Sa complexité dépend de l'environnement d'exécution de votre projet et des autres services dont il dépend. Si votre environnement de test de stress est complexe (c'est-à-dire que de nombreuses personnes exécutent leurs propres tâches sur votre serveur), il est prévisible que les résultats du test de stress seront instables.
Lorsque vous rencontrez une baisse de débit, déterminez d'abord où se trouve le goulot d'étranglement :
Les ressources locales sont-elles limitées ? Les ressources natives incluent principalement le processeur, la mémoire, la bande passante réseau et le débit du disque. Tout cela nécessite observation et enquête.
Si les services dépendants sont serrés, par exemple si le temps de traitement de la base de données et de l'interface externe est trop long.
Si aucun de ces éléments ne permet de localiser clairement le problème, alors entrez dans l'étape de débogage du programme : lors de chaque processus de traitement de requête, enregistrez la durée de chaque étape et découvrez à quelle étape se situe le goulot d'étranglement. Cette granularité sera très fine et elle sera nécessaire. à modifier à plusieurs reprises, enregistrez, exécutez et observez à plusieurs reprises, mais vous trouverez certainement le problème.
Ne faites pas de suppositions sans fondement dès que vous rencontrez un problème. La « pensée divergente » ne vous aidera pas à ce moment-là. Ce que vous devez faire, c'est suivre le problème et l'analyser rigoureusement.