J'ai eu l'occasion de définir des paramètres liés aux performances dans Spring Boot, alors prenez-en note.
Veuillez noter qu'il inclut également mon hypothèse. Je vais rafraîchir de temps en temps.
Pour le moment, le paramètre principal est lié au nombre de connexions simultanées.
openjdk version "11.0.6" org.springframework.boot:spring-boot-starter-web:jar:2.1.7.RELEASE org.springframework.boot:spring-boot-starter-jetty:jar:2.1.7.RELEASE org.springframework.boot:spring-boot-starter-jdbc:jar:2.1.7.RELEASE com.h2database:h2:jar:1.4.199
Jetty est un conteneur / serveur Web Java Servlet et un conteneur intégré pour Spring Boot. Jetty définit principalement le nombre de threads.
Éléments de réglage | sens | Valeur par défaut | application.Nom d'élément des propriétés |
---|---|---|---|
Nombre maximum de threads dans le pool de threads | La signification est comme indiqué sur la gauche, mais l'application.La définition d'une valeur dans les propriétés ne l'a pas modifiée par rapport à la valeur par défaut. Je pense que la raison en est que QueuedThreadPool n'a pas d'endroit pour accepter les paramètres de l'extérieur, mais je le décrirai dès que j'enquêterai. Cependant, je pense qu'un maximum de 200 est suffisant, il n'est donc peut-être pas nécessaire de le définir. | 200 | server.jetty.max-threads |
Nombre minimum de threads dans le pool de threads | Comme pour le nombre maximum de threads, sa définition n'a pas pris effet. Je vais me renseigner. | 8 | server.jetty.min-threads |
Nombre de threads accepteurs | Le thread accepteur accepte les demandes des clients et laisse le traitement au thread de sélection. Les threads accepteurs eux-mêmes ne font pas grand-chose, donc ce nombre de threads peut être petit. Je pense qu'il n'est presque pas nécessaire de changer la valeur par défaut. Le thread accepteur est également un thread dans le pool de threads. | -1 (Dérivé de l'environnement d'exploitation. Voir la page de référence pour la logique de dérivation.) | server.jetty.acceptors |
Nombre de fils de sélection | セレクターとは、ノンブロッキングIOでクライアントとの通信チャンネルを管理するコンポーネントです。従来のブロッキングIOでは、クライアントとの通信が開始してから完了するまで、スレッドがブロックされていました。Jettyで採用されているノンブロッキングIOでは、ちょっとした待ち時間ではスレッドはブロックされず、その間に別の処理を実行することができ、効率性が向上しています。このためには、通信するチャンネルを覚えておく必要があり、その役割を担うのがセレクターです。セレクターは、後続のJava処理を呼び出したりするので、Nombre de fils de sélectionは性能に大きな影響を与えます。なお、セレクタースレッドもスレッドプールのスレッドです。 | -1 (Dérivé de l'environnement d'exploitation. Voir la page de référence pour la logique de dérivation.) | jetty.server.selectors |
Si vous le définissez dans application.properties, ce sera comme suit.
application.properties
server.jetty.acceptors=2
server.jetty.selectors=3
Comment vérifier sur Mac. (Il devrait être possible de le confirmer dans d'autres environnements, mais cela n'a pas été confirmé.)
Tapez jconsole
dans le terminal pour l'exécuter. jconsole est un outil graphique inclus dans le JDK qui utilise JMX pour visualiser l'état des MBeans.
Lorsque vous le démarrez, l'écran suivant s'affiche. Sélectionnez l'application Spring Boot et essayez de vous connecter.
Si vous vérifiez l'état du thread, ce sera comme suit et vous pourrez confirmer que les paramètres sont effectifs.
Ici, comme mentionné ci-dessus, server.jetty.acceptors = 2
et server.jetty.selectors = 3
sont définis.
Au fait, il y a 8 threads commençant par qtp
car la valeur par défaut de la taille minimale (nombre de threads) du pool de threads est 8.
https://www.eclipse.org/jetty/documentation/current/architecture.html https://support.sonatype.com/hc/en-us/articles/360000744687-Understanding-Eclipse-Jetty-9-4-8-Thread-Allocation https://www.techscore.com/tech/Java/JavaSE/NIO/5/ https://www.techscore.com/tech/Java/JavaSE/NIO/5-2/ https://spring.pleiades.io/spring-boot/docs/current/reference/html/appendix-application-properties.html#server-properties
HikariCP est souvent utilisé dans Spring Boot en tant que pool de connexions à haut débit. Cela dépend de spring-boot-starter-jdbc-> HikariCP, et lorsque vous utilisez spring-boot-starter-jdbc, HikariCP est utilisé par défaut.
Dans HikariCP, définissez le nombre de connexions à maintenir dans le pool de connexions.
Éléments de réglage | sens | Valeur par défaut | application.Nom d'élément des propriétés |
---|---|---|---|
connectionTimeout | Temps d'attente maximal pour qu'un client obtienne une connexion à partir du pool de connexions. | 30000(30 secondes) | spring.datasource.hikari.connection-timeout |
idleTimeout | Si une connexion dans le pool de connexions reste inutilisée pendant cette durée, elle sera libérée du pool de connexions. Ce paramètre s'applique uniquement si minimumIdle est défini comme étant inférieur à maximumPoolSize. Même s'il existe de nombreuses connexions inactives, le nombre minimal de connexions inactives restera inchangé. Le fait de déterminer si la connexion est libérée ou non ne signifie pas que cette valeur de consigne devient elle-même la valeur de seuil, et il existe des variations à partir de cette valeur de consigne (valeur de consigne).+15 secondes en moyenne+Variation jusqu'à 30 secondes). Une valeur de 0 signifie que les connexions inactives ne seront pas libérées du pool. La valeur minimale autorisée est de 10000 ms (10 secondes). | 600000(10 minutes) | spring.datasource.hikari.idle-timeout |
maxLifetime | Les connexions qui ont été regroupées pendant cette durée seront libérées du pool de connexions. La connexion en cours d'utilisation sera supprimée après avoir attendu la fermeture de la connexion. Cependant, il est mauvais qu'un grand nombre de connexions soit libéré à la fois, donc il est contrôlé afin que cela n'arrive pas. | 1 800 000 (30 minutes) | spring.datasource.hikari.max-lifetime |
minimumIdle | Le nombre de connexions inactives HikariCP s'efforce de maintenir au minimum le pool. En d'autres termes, il n'y a aucune garantie qu'il ne tombera pas en dessous de ce nombre. S'il tombe en dessous, Hikarri CP générera ce nombre de connexions inactives au mieux par défaut. Cependant, afin d'obtenir les meilleures performances et de gérer les demandes de traitement soudaines, il est recommandé que HicariCP n'utilise pas ce paramètre en premier lieu et conserve la valeur par défaut (identique à maximumPoolSize). | Identique à maximumPoolSize. | spring.datasource.hikari.minimum-idle |
maximumPoolSize | Nombre maximal de connexions (en cours d'utilisation et inactives) à maintenir dans le pool. GetConnection si toutes les connexions du pool sont en cours d'utilisation()Ensuite, seul connectionTimeout est bloqué. | 10 | spring.datasource.hikari.maximum-pool-size |
Si vous le définissez dans application.properties, ce sera comme suit.
application.properties
spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.idle-timeout=600000
spring.datasource.hikari.max-lifetime=1800000
spring.datasource.hikari.minimum-idle=10
spring.datasource.hikari.maximum-pool-size=10
Comment vérifier sur Mac. (Il devrait être possible de le confirmer dans d'autres environnements, mais cela n'a pas été confirmé.)
Ajoutez les paramètres suivants.
application.properties
spring.datasource.hikari.register-mbeans=true
L'objet HikariCP est maintenant enregistré en tant que MBean et peut être surveillé en externe à l'aide de JMX.
Tapez jconsole
dans le terminal pour l'exécuter. jconsole est un outil graphique inclus dans le JDK qui utilise JMX pour visualiser l'état des MBeans.
Lorsque vous le démarrez, l'écran suivant s'affiche. Sélectionnez l'application Spring Boot et essayez de vous connecter.
Vous pouvez vérifier l'état des connexions actives et des connexions inactives comme suit.
Vous pouvez vérifier les paramètres appliqués comme suit.
https://github.com/brettwooldridge/HikariCP https://spring.pleiades.io/spring-boot/docs/current/reference/html/appendix-application-properties.html#data-properties https://matsumana.info/blog/2016/02/06/spring-boot-hikaricp-metrics/
Recommended Posts