Beim Starten von Spring Boot-Anwendungen verwenden wir normalerweise die von Startern bereitgestellten Standardeinstellungen, was für die meisten Fälle ausreichend ist. Wenn wir jedoch Leistung benötigen, können wir spezifische Anpassungen vornehmen, wie im ersten Teil dieses Artikels gezeigt wird.

Ersetzen von Tomcat durch einen anderen Servlet-Container

Anwendungen web, RESTFul, die Spring MVC verwenden, fügen im Allgemeinen die Spring-Boot-Starter-Web-Abhängigkeit hinzu, die standardmäßig Tomcat als Server verwendet web. Es gibt jedoch interessantere Alternativen, wie zum Beispiel Undertow, einen leistungsstarken Web-Server mit einer asynchronen und nicht blockierenden Architektur, der es ihm ermöglicht, eine große Anzahl zu verarbeiten von gleichzeitigen Verbindungen effizient, wodurch es für Hochleistungsanwendungen geeignet ist. Wir sagen nicht, dass Tomcat schlecht ist, aber wir können Undertow.

Hinzufügen von Undertow zu Spring

Damit wir Undertow als Web-Server verwenden können, müssen wir die Spring-Boot-Starter-Tomcat-Abhängigkeit ignorieren, die Spring-Boot-Starter-Web bereits hinzufügt und dann den Spring-Boot-Starter-Undertow hinzufügen.

Pom.xml verwenden:

org.springframework.bootspring-boot-starter-weborg.springframework.bootspring-boot-starter-tomcatorg.springframework.bootspring-boot-starter-undertow

Build.gradle verwenden:

dependencies {
    implementation('org.springframework.boot:spring-boot-starter-web') {
        exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
    }
    implementation 'org.springframework.boot:spring-boot-starter-undertow'
}

Sog konfigurieren

Über application.properties oder application.yml können wir konfigurieren, wie viele IO-Threads und wie viele Worker-Threads der Server verwenden soll.

Anwendung.yml verwenden

server:
  undertow:
    threads:
      io: 4
      worker: 64

Anwendung.properties verwenden

server.undertow.threads.io=4
server.undertow.threads.worker=64

E/A-Threads führen nicht blockierende Vorgänge aus und sollten niemals blockierende Vorgänge ausführen, da sie dafür verantwortlich sind, bei der Anwendung ankommende Verbindungen abzuhören und sie dann an eine Verarbeitungswarteschlange zu senden. Ein üblicher Wert sind zwei I/O-Threads pro CPU-Kern.

Arbeitsthreads führen blockierende Vorgänge aus, z. B. Servlet-Anfragen, die von E/A-Threads an die Verarbeitungswarteschlange gesendet wurden. Der ideale Wert hängt von der Arbeitslast ab, es wird jedoch generell empfohlen, etwa 10 Threads pro CPU-Kern zu konfigurieren.

Ausführlichere Informationen und weitere Optionen, die erkundet werden können, finden Sie in der Dokumentation zu Undertow.

Komprimieren von HTTP-Antworten

Datenkomprimierung ist eine Funktion, die darauf abzielt, die Körpergröße von HTTP-Antworten zu reduzieren, was wiederum die Leistung unserer Anwendung verbessern kann, indem die über das Netzwerk übertragene Datenmenge reduziert wird.

Das Konfigurieren der Datenkomprimierung in Spring Boot ist eine triviale Aufgabe, da es diese Funktionalität unterstützt.

Anwendung.yml verwenden

server:
  compression:
    enabled: true
    mime-types: text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json
    min-response-size: 1024

Anwendung.properties verwenden

server.compression.enabled=true
server.compression.mime-types=text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json
server.compression.min-response-size=1024

server.compression.enabled: Aktiviert/deaktiviert die Komprimierung.
server.compression.mime-types: Liste der MIME-Typen, die komprimiert werden sollen.
server.compression.min-response-size: Mindestgröße von „Content-Length“, die für die Durchführung der Komprimierung erforderlich ist.

Damit schließen wir den ersten Teil des Artikels. Im nächsten Teil erfahren wir mehr über Hikari, JPA und Hibernate und erfahren, wie man diese konfiguriert, um die Leistung von Spring Boot-Anwendungen weiter zu verbessern.