Wie schnell lässt sich ein statischer Dateiserver mit dem virtuellen Spring Boot 3.2-Thread erstellen?

[Vorschau der Live-Übertragung] 99 Yuan virtuelle Cloud-Maschine × 9 Yuan native Cloud-Architektur √

Spring Boot 3.2 wurde im November 2023 unter großem Getöse veröffentlicht und markierte einen entscheidenden Moment in der Welt der Java-Entwicklung. Diese bahnbrechende Version führt eine Vielzahl revolutionärer Funktionen ein, darunter:

Virtuelle Threads: Entfesseln Sie die Skalierbarkeit mit den virtuellen Threads von Project Loom, reduzieren Sie den Ressourcenverbrauch und verbessern Sie die Parallelität.
Native Image-Unterstützung: Erstellen Sie extrem schnelle Anwendungen mit Native Image-Kompilierung, wodurch die Startzeit verkürzt und die Ressourcennutzung optimiert wird.
JVM-Prüfpunkte: Nutzen Sie den JVM-Prüfpunktmechanismus des CRaC-Projekts, um einen schnellen Neustart von Anwendungen ohne langwierige Neuinitialisierung zu ermöglichen.
RestClient: Nutzen Sie die funktionalen Methoden der neuen RestClient- Schnittstelle, um HTTP-Interaktionen zu vereinfachen und Code zu vereinfachen.
Spring für Apache Pulsar: Nutzen Sie die Leistung von Apache Pulsar für leistungsstarke Messaging-Funktionen, die nahtlos in Ihre Spring Boot-Anwendungen integriert sind.

Unter diesen sind virtuelle Threads eine der transformativsten Funktionen, die in neueren Java-Versionen eingeführt wurden. In der offiziellen Dokumentation heißt es: Virtuelle Threads sind leichtgewichtige Threads, die den Aufwand für das Schreiben, Warten und Debuggen gleichzeitiger Anwendungen mit hohem Durchsatz reduzieren. Ein Thread ist die kleinste Verarbeitungseinheit, die geplant werden kann. Es arbeitet parallel zu und weitgehend unabhängig von anderen derartigen Einheiten. Es ist eine Instanz von java.lang.Thread. Es gibt zwei Arten von Threads: Plattform-Threads und virtuelle Threads. Plattform-Threads werden als Thin Wrapper für Betriebssystem-Threads implementiert. Plattform-Threads führen Java-Code auf ihren zugrunde liegenden Betriebssystem-Threads aus, und Plattform-Threads erfassen den Betriebssystem-Thread des Plattform-Threads während seiner gesamten Lebensdauer. Daher ist die Anzahl der verfügbaren Plattform-Threads auf die Anzahl der Betriebssystem-Threads begrenzt. Virtuelle Threads sind wie Plattform-Threads Instanzen von java.lang.Thread. Virtuelle Threads sind jedoch nicht an bestimmte Betriebssystem-Threads gebunden. Virtuelle Threads führen weiterhin Code auf Betriebssystem-Threads aus. Wenn jedoch in einem virtuellen Thread ausgeführter Code einen blockierenden E/A-Vorgang aufruft, hält die Java-Laufzeit den virtuellen Thread an, bis er wieder aufgenommen werden kann. Der Betriebssystem-Thread, der dem angehaltenen virtuellen Thread zugeordnet ist, kann nun Vorgänge für andere virtuelle Threads ausführen. Virtuelle Threads eignen sich zum Ausführen von Aufgaben, die die meiste Zeit blockiert sind und normalerweise auf den Abschluss von E/A-Vorgängen warten. Sie eignen sich jedoch nicht für lang andauernde, CPU-intensive Vorgänge.

Während allgemein davon ausgegangen wird, dass virtuelle Threads in I/O-intensiven Szenarien eine gute Leistung erbringen, bleibt ihre Leistung bei CPU-intensiven Aufgaben fraglich. Diese Artikelserie befasst sich eingehend mit den potenziellen Vorteilen virtueller Threads in einer Vielzahl von Anwendungsfällen, von der einfachen „Hallo Welt“ bis hin zur statischen Dateibereitstellung (E/A-intensiv), der QR-Code-Generierung (CPU-intensiv) und mehrteiligen/ Bilden Sie Daten in realen Anwendungen wie der Verarbeitung (gemischte Arbeitslasten).

Im Eröffnungsartikel dieser Serie haben wir die Leistung virtueller Threads im Vergleich zu physischen Threads im einfachsten (und unpraktischen) Hallo-Welt-Fall untersucht. Es gibt praktisch keinen Unterschied in der Leistung oder Ressourcennutzung zwischen physischen Threads und virtuellen Threads. In diesem Artikel gehen wir eher „praktisch“ vor und vergleichen die Situation mit statischen Dateiservern. Dies ist definitiv ein häufiger und „realer“ Fall. Mal sehen, was wir dieses Mal gefunden haben.

Wenn Sie ein Upgrade von Spring Boot 2.3 auf Spring 3.2 durchführen, finden Sie hier die Upgrade-Anleitung von Spring Boot 2.x auf 3.2 .

Test Umgebung

Alle Tests wurden auf einem MacBook Pro M2 durchgeführt, das mit 16 GB RAM, 8 physischen Kernen und 4 Effizienzkernen ausgestattet ist. Das Testtool ist Bombardier, einer der schnelleren HTTP-Lasttester (geschrieben in Go).

Die Softwareversion ist:

Java v21.0.1
Spring Boot 3.2.1

Programmkonfiguration

Es ist nicht erforderlich, andere Java-Dateien als die Haupt-Java-Klasse zu schreiben. Der statische Dateiserver kann nur durch Konfiguration funktionieren.

application.propertiesDie Dateien lauten wie folgt:

server.port=3000
spring.mvc.static-path-pattern=/static/**
spring.web.resources.static-locations=file:/Users/mayankc/Work/source/perfComparisons/static/

Wenn Sie virtuelle Threads verwenden, aktivieren wir diese, indem wir die folgenden Zeilen hinzufügen:

spring.threads.virtual.enabled=true

pom.xmlInhalt:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.2.1</version>
    <relativePath/>
 </parent>
 <groupId>com.example</groupId>
 <artifactId>demo</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <name>demo</name>
 <description>Demo project for Spring Boot</description>
 <properties>
   <java.version>21</java.version>
 </properties>
 <dependencies>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
   </dependency>

  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
  </dependency>
 </dependencies>

Testdaten

100.000 Dateien mit genau derselben Größe, aber unterschiedlichen Daten werden im statischen Ressourcenverzeichnis abgelegt. Jede Dateigröße beträgt genau 102400 Bytes.

Dateien können im Bereich von 1 bis 100.000 benannt werden.

Verwenden Sie eine modifizierte Version von Bombardier, um für jeden Lauf eine zufällige Anforderungs-URL zu generieren:http://localhost:3000/static/<file-name>

Anwendungsszenarien

Um konsistente Ergebnisse zu gewährleisten, durchläuft jeder Test eine 5K-Aufwärmphase, bevor mit der Datenerfassung begonnen wird.

Anschließend wurden die Messungen sorgfältig über verschiedene Bereiche gleichzeitiger Verbindungsebenen (50, 100 und 300) aufgezeichnet, die jeweils einer Arbeitslast von 5 Millionen Anfragen unterworfen waren.

Ergebnisbewertung

Zusätzlich zur einfachen Verfolgung der Rohgeschwindigkeit werden wir ein detailliertes Metrik-Framework verwenden, um die Latenzverteilung (Minimum, Perzentil, Maximum) und den Durchsatz (Anfragen pro Sekunde) zu erfassen.

Die Überwachung der Ressourcennutzung von CPU und Speicher ergänzt diese Analyse und liefert ein umfassendes Verständnis der Systemleistung unter verschiedenen Arbeitslasten.

Testergebnisse

Die Ergebnisse werden in Diagrammform wie folgt dargestellt:

Zusammenfassen

Die Analyse der statischen Dateibereitstellung ergab, dass physische Threads im Hinblick auf Leistung und Ressourceneffizienz etwas besser waren (entgegen unseren Erwartungen).

Allerdings ist dieses I/O-gebundene Szenario möglicherweise nicht der ideale Ort, um das volle Potenzial virtueller Threads auszuschöpfen. Aufgaben mit Datenbankinteraktion können überzeugendere Vorteile bieten. Möglicherweise reicht die Last nicht aus, damit die virtuellen Threads ihre beste Arbeit leisten können. Um das herauszufinden, behandeln wir in den folgenden Artikeln die URL-Verkürzung (datenbankgesteuert), die QR-Code-Generierung (CPU-gebunden) und gemischte Workload-Szenarien (wie die Verarbeitung von Formulardaten), um aufzuzeigen, wo virtuelle Threads wirklich glänzen.

Willkommen, um meinem öffentlichen Konto zu folgen: Programmierer DD. Seien Sie der Erste, der aktuelle Branchennachrichten versteht, ausführliche technische Informationen weitergibt und hochwertige Lernressourcen erhält