java - Comment tester sous contrainte le processeur du service http (Tomcat)

Question

Prémisse : Bonjour à tous, je dois maintenant tester un serveur Tomcat pour savoir où se trouve le goulot d'étranglement de l'application. Cependant, pendant le processus de test, le processeur occupé par la ressource jvm n'a pas atteint 50 %, et mysql. a été entraîné vers le bas.

Maintenant, je veux découvrir le goulot d'étranglement du service d'application. Lorsque la concurrence est élevée, le CPU sera trop élevé. Comment y parvenir ?
La méthode à laquelle j'ai pensé est la suivante : créer plusieurs threads au niveau du code, ne pas lire ni écrire la base de données et laisser le CPU monter. Est-il possible? ?
Merci~~

Answer 1

D'une manière générale, le goulot d'étranglement des applications web est la base de données. Si le serveur d'applications (qu'il s'agisse de Tomcat ou autres) est surchargé, de manière générale, cela peut être résolu en ajoutant un serveur.

Si vous souhaitez réduire les coûts et découvrir où se trouvent les goulots d'étranglement des applications, il existe quelques astuces pour effectuer des tests de résistance, telles que :

Changez le moteur de stockage MySQL en blackhole afin que la base de données ne soit pas facilement détruite.

Answer 2

Si l'utilisation du CPU est trop importante, le pool de connexions à la base de données a été utilisé pour limiter la création de liens. Afin de réduire l'accès à la base de données, certaines données rarement mises à jour peuvent être placées dans un cache tel que Redis, afin qu'il ne soit pas nécessaire d'accéder à la base de données à chaque fois pour récupérer les données.

Pour les tests de stress simples, j'aime utiliser ab dans le serveur Apache. Pour les tests complexes, vous pouvez essayer JMeter pour faciliter l'analyse et découvrir où se situe le problème.

Answer 3

Le processeur occupé par les ressources jvm n'a pas atteint 50% et mysql a été entraîné vers le bas

Cela ressemble à un problème avec les opérations de base de données. Par exemple, SQL doit être optimisé ou une mise en cache doit être ajoutée pour réduire les opérations de base de données. Je ne vois rien à voir avec Tomcat.

Answer 4

MySQL est en panne. Cela ne devrait pas être le goulot d'étranglement de Tomcat. Vous devez vérifier si le SQL a été optimisé. De plus, activez les statistiques MySQL pour vérifier s'il y a un SQL lent, s'il y a une analyse complète de la table et si le SQL est lent. l'index est efficace. De plus, avez-vous utilisé un pool de connexions pour contrôler la simultanéité de la base de données ? La simultanéité prise en charge par MySQL est liée au nombre de cœurs CPU. Généralement, un SQL lent peut facilement faire tomber la base de données

Answer 5

Les goulots d'étranglement généraux du système peuvent essentiellement être résolus en augmentant le nombre de serveurs et en optimisant les requêtes. Les plus gros goulots d'étranglement se situent essentiellement au niveau du lien de base de données. Selon ce que vous avez dit, vous souhaitez tester le goulot d'étranglement de la simultanéité de vos requêtes, mais si vous ne vous connectez pas. l'accès à la base de données pour les tests est fondamentalement inefficace et n'aide pas le vrai projet. Le goulot d'étranglement obtenu n'est pas votre véritable goulot d'étranglement

.