[JAVA] Spring Boot performance related settings
I had a chance to make performance related settings in Spring Boot, so make a note of it.
Please note that it also includes my hypothesis. I will brush up from time to time.
At the moment, the main setting is related to the number of concurrent connections.
Various versions
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 (Java Servlet container / Web server)
Jetty is a Java Servlet container / web server and is a built-in container for Spring Boot. Jetty mainly sets the number of threads.
Setting items
| Setting items | meaning | Default value | application.Item name of properties |
|---|---|---|---|
| Maximum number of threads in the thread pool | The meaning is as shown on the left, but application.Setting the value in properties did not change it from the default value. I think the reason is that QueuedThreadPool does not have a place to accept settings from the outside, but I will describe it as soon as I investigate. However, I think that a maximum of 200 is enough, so it may not be necessary to set it. | 200 | server.jetty.max-threads |
| Minimum number of threads in the thread pool | As with the maximum number of threads, setting it did not take effect. I will investigate. | 8 | server.jetty.min-threads |
| Number of acceptor threads | The acceptor thread accepts requests from clients and leaves the processing to the selector thread. The acceptor threads themselves don't do much, so this number of threads can be small. I think there is almost no need to change from the default. The acceptor thread is also a thread in the thread pool. | -1 (Derived from the operating environment. See the reference page for the derivation logic.) | server.jetty.acceptors |
| Number of selector threads | セレクターとは、ノンブロッキングIOでクライアントとの通信チャンネルを管理するコンポーネントです。従来のブロッキングIOでは、クライアントとの通信が開始してから完了するまで、スレッドがブロックされていました。Jettyで採用されているノンブロッキングIOでは、ちょっとした待ち時間ではスレッドはブロックされず、その間に別の処理を実行することができ、効率性が向上しています。このためには、通信するチャンネルを覚えておく必要があり、その役割を担うのがセレクターです。セレクターは、後続のJava処理を呼び出したりするので、Number of selector threadsは性能に大きな影響を与えます。なお、セレクタースレッドもスレッドプールのスレッドです。 | -1 (Derived from the operating environment. See the reference page for the derivation logic.) | jetty.server.selectors |
If you set it in application.properties, it will be as follows.
application.properties
server.jetty.acceptors=2
server.jetty.selectors=3
How to check if the settings are working
How to check on Mac. (It should be possible to confirm it in other environments, but it has not been confirmed.)
① Start the Spring Boot application
② Start jconsole
Type jconsole in the terminal to run it. jconsole is a GUI tool that comes with the JDK and uses JMX to visualize the state of MBeans.
When you start it, the following screen will be displayed. Select the Spring Boot application and try connecting.
③ Check the thread status
If you check the thread status, it will be as follows, and you can confirm that the settings are effective.
As mentioned above, server.jetty.acceptors = 2 and server.jetty.selectors = 3 are set here.
By the way, there are 8 threads starting with qtp because the default value of the minimum size (number of threads) of the thread pool is 8.
reference
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 (connection pool)
HikariCP is often used in Spring Boot as a high-speed connection pool. It depends on spring-boot-starter-jdbc-> HikariCP, and if you use spring-boot-starter-jdbc, HikariCP will be used by default.
In HikariCP, set the number of connections to be maintained in the connection pool.
Setting items
| Setting items | meaning | Default value | application.Item name of properties |
|---|---|---|---|
| connectionTimeout | The maximum wait time for a client to get a connection from the connection pool. | 30000(30 seconds) | spring.datasource.hikari.connection-timeout |
| idleTimeout | If a connection in the connection pool is left unused for this amount of time, it will be released from the connection pool. This setting applies only if minimumIdle is defined to be less than maximumPoolSize. Even if there are many idle connections, the minimum Idle number of connections will remain unreleased. Judgment as to whether or not the connection is released does not mean that this set value itself becomes the threshold value, and there are variations starting from this set value (set value).+15 seconds on average+Up to 30 seconds variation). A value of 0 means that idle connections will not be released from the pool. The minimum value allowed is 10000ms (10 seconds). | 600000(10 minutes) | spring.datasource.hikari.idle-timeout |
| maxLifetime | Connections that have been pooled for this amount of time are released from the connection pool. The connection in use will be deleted after waiting for the connection to be closed. However, it is bad that a large number of connections are released at once, so it is controlled so that it does not happen. | 1800000 (30 minutes) | spring.datasource.hikari.max-lifetime |
| minimumIdle | The number of idle connections HikariCP strives to keep in the pool at a minimum. In other words, there is no guarantee that it will not fall below this number. If it falls below this, Hikarri CP will generate this many idle connections at best default. However, in order to achieve the best performance and to handle sudden processing requests, it is recommended that HicariCP does not use this setting in the first place and keeps the default value (same as maximumPoolSize). | Same as maximumPoolSize. | spring.datasource.hikari.minimum-idle |
| maximumPoolSize | The maximum number of connections (both in use and idle) to maintain in the pool. GetConnection if all connections in the pool are in use()Then, only connectionTimeout is blocked. | 10 | spring.datasource.hikari.maximum-pool-size |
If you set it in application.properties, it will be as follows.
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
How to check if the settings are working
How to check on Mac. (It should be possible to confirm it in other environments, but it has not been confirmed.)
(1) Set HikariCP object to be registered as MBean
Add the following settings.
application.properties
spring.datasource.hikari.register-mbeans=true
The HikariCP object is now registered as an MBean and can be monitored externally using JMX.
② Start the Spring Boot application
③ Start jconsole
Type jconsole in the terminal to run it. jconsole is a GUI tool that comes with the JDK and uses JMX to visualize the state of MBeans.
When you start it, the following screen will be displayed. Select the Spring Boot application and try connecting.
④ Check the status of MBean
You can check the status of active connections and idle connections as follows.
You can check the applied settings as follows.
reference
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