Ich hatte die Möglichkeit, in Spring Boot leistungsbezogene Einstellungen vorzunehmen. Notieren Sie sich dies.
Bitte beachten Sie, dass es auch meine Hypothese enthält. Ich werde von Zeit zu Zeit auffrischen.
Im Moment hängt die Haupteinstellung mit der Anzahl der gleichzeitigen Verbindungen zusammen.
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 ist ein Java-Servlet-Container / Webserver und ein integrierter Container für Spring Boot. Jetty legt hauptsächlich die Anzahl der Threads fest.
Elemente einstellen | Bedeutung | Standardwert | application.Elementname der Eigenschaften |
---|---|---|---|
Maximale Anzahl von Threads im Thread-Pool | Die Bedeutung ist wie links gezeigt, aber Anwendung.Durch das Festlegen eines Werts in Eigenschaften wurde der Standardwert nicht geändert. Ich denke, der Grund ist, dass es in QueuedThreadPool keinen Platz gibt, der Einstellungen von außen akzeptiert, aber ich werde es beschreiben, sobald ich nachforsche. Ich denke jedoch, dass maximal 200 ausreichen, so dass es möglicherweise nicht notwendig ist, es einzustellen. | 200 | server.jetty.max-threads |
Mindestanzahl von Threads im Thread-Pool | Wie bei der maximalen Anzahl von Threads wurde die Einstellung nicht wirksam. Ich werde ermitteln. | 8 | server.jetty.min-threads |
Anzahl der Akzeptor-Threads | Der Akzeptor-Thread akzeptiert Anforderungen von Clients und überlässt die Verarbeitung dem Selektor-Thread. Die Akzeptor-Threads selbst machen nicht viel, daher kann diese Anzahl von Threads klein sein. Ich denke, es gibt fast keine Notwendigkeit, von der Standardeinstellung zu wechseln. Der Akzeptor-Thread ist auch ein Thread im Thread-Pool. | -1 (Abgeleitet von der Betriebsumgebung. Die Ableitungslogik finden Sie auf der Referenzseite.) | server.jetty.acceptors |
Anzahl der Auswahlgewinde | セレクターとは、ノンブロッキングIOでクライアントとの通信チャンネルを管理するコンポーネントです。従来のブロッキングIOでは、クライアントとの通信が開始してから完了するまで、スレッドがブロックされていました。Jettyで採用されているノンブロッキングIOでは、ちょっとした待ち時間ではスレッドはブロックされず、その間に別の処理を実行することができ、効率性が向上しています。このためには、通信するチャンネルを覚えておく必要があり、その役割を担うのがセレクターです。セレクターは、後続のJava処理を呼び出したりするので、Anzahl der Auswahlgewindeは性能に大きな影響を与えます。なお、セレクタースレッドもスレッドプールのスレッドです。 | -1 (Abgeleitet von der Betriebsumgebung. Die Ableitungslogik finden Sie auf der Referenzseite.) | jetty.server.selectors |
Wenn Sie es in application.properties festlegen, sieht es wie folgt aus.
application.properties
server.jetty.acceptors=2
server.jetty.selectors=3
So überprüfen Sie auf dem Mac. (Es sollte möglich sein, es in anderen Umgebungen zu bestätigen, aber es wurde nicht bestätigt.)
Geben Sie "jconsole" in das Terminal ein, um es auszuführen. jconsole ist ein im JDK enthaltenes GUI-Tool, das JMX verwendet, um den Status von MBeans zu visualisieren.
Wenn Sie es starten, wird der folgende Bildschirm angezeigt. Wählen Sie die Spring Boot-Anwendung aus und versuchen Sie, eine Verbindung herzustellen.
Wenn Sie den Thread-Status überprüfen, lautet dieser wie folgt und Sie können bestätigen, dass die Einstellung wirksam ist.
Hier werden, wie oben erwähnt, "server.jetty.acceptors = 2" und "server.jetty.selectors = 3" gesetzt.
Übrigens gibt es 8 Threads, die mit "qtp" beginnen, da der Standardwert für die Mindestgröße (Anzahl der Threads) des Thread-Pools 8 ist.
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 wird in Spring Boot häufig als Hochgeschwindigkeitsverbindungspool verwendet. Dies hängt von Spring-Boot-Starter-JDBC-> HikariCP ab. Wenn Sie Spring-Boot-Starter-JDBC verwenden, wird standardmäßig HikariCP verwendet.
Legen Sie in HikariCP die Anzahl der Verbindungen fest, die im Verbindungspool verwaltet werden sollen.
Elemente einstellen | Bedeutung | Standardwert | application.Elementname der Eigenschaften |
---|---|---|---|
connectionTimeout | Die maximale Wartezeit, bis ein Client eine Verbindung aus dem Verbindungspool erhält. | 30000(30 Sekunden) | spring.datasource.hikari.connection-timeout |
idleTimeout | Wenn eine Verbindung im Verbindungspool für diese Zeit nicht verwendet wird, wird sie aus dem Verbindungspool freigegeben. Diese Einstellung gilt nur, wenn MinimumIdle als kleiner als MaximumPoolSize definiert ist. Selbst wenn es viele Leerlaufverbindungen gibt, bleibt die minimale Leerlaufanzahl von Verbindungen unveröffentlicht. Die Beurteilung, ob die Verbindung freigegeben ist oder nicht, bedeutet nicht, dass dieser Sollwert selbst zum Schwellenwert wird, und es gibt Abweichungen ab diesem Sollwert (Sollwert).+Durchschnittlich 15 Sekunden+Bis zu 30 Sekunden Variation). Ein Wert von 0 bedeutet, dass inaktive Verbindungen nicht aus dem Pool freigegeben werden. Der zulässige Mindestwert beträgt 10000 ms (10 Sekunden). | 600000(10 Minuten) | spring.datasource.hikari.idle-timeout |
maxLifetime | Verbindungen, die für diese Zeit gepoolt wurden, werden aus dem Verbindungspool freigegeben. Die verwendete Verbindung wird gelöscht, nachdem darauf gewartet wurde, dass die Verbindung geschlossen wird. Es ist jedoch schlecht, dass eine große Anzahl von Verbindungen gleichzeitig freigegeben wird, sodass sie so gesteuert werden, dass dies nicht geschieht. | 1800000 (30 Minuten) | spring.datasource.hikari.max-lifetime |
minimumIdle | Die Anzahl der inaktiven Verbindungen, die HikariCP im Pool halten möchte, ist minimal. Mit anderen Worten, es gibt keine Garantie dafür, dass diese Zahl nicht unterschritten wird. Wenn es darunter fällt, generiert Hikarri CP im besten Fall standardmäßig so viele Leerlaufverbindungen. Um jedoch die beste Leistung zu erzielen und plötzliche Verarbeitungsanforderungen zu verarbeiten, wird empfohlen, dass HicariCP diese Einstellung überhaupt nicht verwendet und den Standardwert (wie bei MaximumPoolSize) beibehält. | Gleich wie MaximumPoolSize. | spring.datasource.hikari.minimum-idle |
maximumPoolSize | Die maximale Anzahl von Verbindungen (sowohl in Gebrauch als auch inaktiv), die im Pool verwaltet werden sollen. GetConnection, wenn alle Verbindungen im Pool verwendet werden()Dann wird nur connectionTimeout blockiert. | 10 | spring.datasource.hikari.maximum-pool-size |
Wenn Sie es in application.properties festlegen, sieht es wie folgt aus.
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
So überprüfen Sie auf dem Mac. (Es sollte möglich sein, es in anderen Umgebungen zu bestätigen, aber es wurde nicht bestätigt.)
Fügen Sie die folgenden Einstellungen hinzu.
application.properties
spring.datasource.hikari.register-mbeans=true
Das HikariCP-Objekt ist jetzt als MBean registriert und kann extern mit JMX überwacht werden.
Geben Sie "jconsole" in das Terminal ein, um es auszuführen. jconsole ist ein im JDK enthaltenes GUI-Tool, das JMX verwendet, um den Status von MBeans zu visualisieren.
Wenn Sie es starten, wird der folgende Bildschirm angezeigt. Wählen Sie die Spring Boot-Anwendung aus und versuchen Sie, eine Verbindung herzustellen.
Sie können den Status von aktiven Verbindungen und Leerlaufverbindungen wie folgt überprüfen.
Sie können die angewendeten Einstellungen wie folgt überprüfen.
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