Einführung
In den vorherigen Teilen unserer Serie haben wir die Kaltstarts der Lambda-Funktion mit Java 21-Laufzeit ohne aktiviertem SnapStart gemessen, mit aktiviertem SnapStart und außerdem die DynamoDB-Aufruf-Priming-Optimierung mit unterschiedlichen Lambda-Speichereinstellungen, Lambda-Bereitstellungsartefaktgrößen und Java angewendet Kompilierungsoptionen, (a)synchrone HTTP-Clients und die Verwendung verschiedener Lambda-Schichten. Für alle diese Messungen haben wir den Standard-Garbage-Collection-Algorithmus G1 verwendet.
In diesem Artikel möchten wir die Auswirkungen von Java-Garbage-Collection-Algorithmen auf die Leistung der Lambda-Funktion mit Java 21-Laufzeit untersuchen. Wir werden auch alles neu messen, damit der G1 vergleichbare Ergebnisse mit derselben Nebenversion von Java 21 erzielt, die für alle Garbage-Collection-Algorithmen verwendet wird.
Java-Garbage-Collection-Algorithmen
Für unsere Messungen verwenden wir die folgenden Java-Erfassungsalgorithmen mit ihrer Standardeinstellung (weitere Informationen zu den einzelnen Algorithmen finden Sie in der verlinkten Dokumentation):
-
Garbage-First (G1) Garbage Collector. Dies ist der standardmäßig verwendete Garbage-Collection-Algorithmus. Sie können es explizit in der AWS SAM-Vorlage festlegen, indem Sie -XX:+UseG1GC zur Umgebungsvariablen JAVA_TOOL_OPTIONS hinzufügen.
-
Der Parallelkollektor. Sie können es explizit in der AWS SAM-Vorlage festlegen, indem Sie -XX:+UseParallelGC zur Umgebungsvariablen JAVA_TOOL_OPTIONS hinzufügen.
-
Shenandoah GC. Oracle JDK bietet es nicht, Amazon Corretto 21 JDK jedoch schon. Sie können es explizit in der AWS SAM-Vorlage festlegen, indem Sie -XX:+UseShenandoahGC zur Umgebungsvariablen JAVA_TOOL_OPTIONS hinzufügen.
-
Der Z Garbage Collector. Es gibt zwei verschiedene ZGC-Algorithmen: den Standardalgorithmus und den neueren Ein-Generationen-Algorithmus. Sie können es explizit in der AWS SAM-Vorlage festlegen, indem Sie -XX:+UseZGC oder -XX:+UseZGC -XX:+ZGenerational zur Umgebungsvariablen JAVA_TOOL_OPTIONS hinzufügen.
Die Messung von Kälte und Wärme beginnt mit Java 21 und verwendet verschiedene Garbage-Collection-Algorithmen
In unserem Experiment verwenden wir die in Teil 9 eingeführte leicht modifizierte Anwendung. Den Anwendungscode finden Sie hier. Grundsätzlich gibt es zwei Lambda-Funktionen, die beide auf die API-Gateway-Anfragen reagieren und Produkte anhand der vom API-Gateway empfangenen ID von DynamoDB abrufen. Eine Lambda-Funktion, GetProductByIdWithPureJava21LambdaWithGCAlg, kann mit und ohne SnapStart verwendet werden, und die zweite, GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg, verwendet SnapStart und DynamoDB-Anforderungsaufruf-Priming.
Die Ergebnisse des folgenden Experiments basierten auf der Reproduktion von mehr als 100 Kalt- und etwa 100.000 Warmstarts mit einem Experiment, das etwa eine Stunde dauerte. Dafür (und Experimente aus meinem vorherigen Artikel) habe ich das Lasttest-Tool verwendet, aber Sie können jedes beliebige Tool verwenden, z. B. Serverless-Artillery oder Postman. Wir führen Experimente durch, indem wir Lambda-Funktionen 1024 MB Speicher zur Verfügung stellen und JAVA_TOOL_OPTIONS: „-XX:+TieredCompilation -XX:TieredStopAtLevel=1“ (Java-Client-Kompilierung ohne Profilierung) verwenden, was einen sehr guten Kompromiss zwischen Kalt- und Warmstartzeiten bietet.
Leider konnte ich die Lambda-Funktion nicht starten, als beim Z Garbage Collector (sowohl Standard- als auch Generations-Collector) der Fehler auftrat:
Failed to commit memory (Operation not permitted)
[error][gc] Forced to lower max Java heap size from 872M(100%) to 0M(0%)
[error][gc] Failed to allocate initial Java heap (512M)
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Nach dem Login kopieren
Es wurden größere Speichereinstellungen wie 1024, 2048 MB und noch mehr MB ausprobiert, aber der gleiche Fehler trat immer noch auf.
Sehen wir uns die Ergebnisse unserer Messungen mit anderen 3 Garbage-Collection-Algorithmen an.
Abkürzung c steht für den Kaltstart und w für den Warmstart.
Kaltstartzeit (c) und Warmstartzeit (w) ohne aktiviertes SnapStart in ms:
| GC Algorithm |
c p50 |
c p75 |
c p90 |
c p99 |
c p99.9 |
c max |
w p50 |
w p75 |
w p90 |
w p99 |
w p99.9 |
w max |
| G1 |
3655.17 |
3725.25 |
3811.88 |
4019.25 |
4027.30 |
4027.83 |
5.46 |
6.10 |
7.10 |
16.79 |
48.06 |
1929.79 |
| Parallel Collector |
3714.10 |
3789.09 |
3857.87 |
3959.44 |
4075.89 |
4078.25 |
5.55 |
6.20 |
7.10 |
15.38 |
130.13 |
2017.92 |
| Shenandoah |
3963.40 |
4019.25 |
4096.30 |
4221.00 |
4388.78 |
4390.76 |
5.82 |
6.45 |
7.39 |
17.06 |
71.02 |
2159.21 |
Kaltstartzeit (c) und Warmstartzeit (w) mit aktiviertem SnapStart ohne Vorbereiten in ms:
| GC Algorithm |
c p50 |
c p75 |
c p90 |
c p99 |
c p99.9 |
c max |
w p50 |
w p75 |
w p90 |
w p99 |
w p99.9 |
w max |
| G1 |
1867.27 |
1935.68 |
2152.02 |
2416.57 |
2426.25 |
2427.35 |
5.47 |
6.11 |
7.05 |
17.41 |
51.24 |
1522.04 |
| Parallel Collector |
1990.62 |
2047.12 |
2202.07 |
2402.12 |
2418.99 |
2419.32 |
5.68 |
6.35 |
7.45 |
18.04 |
147.83 |
1577.21 |
| Shenandoah |
2195.47 |
2301.07 |
2563.37 |
3004.89 |
3029.01 |
3030.36 |
5.73 |
6.41 |
7.51 |
17.97 |
75.00 |
1843.34 |
Kalte (c) und warme (w) Startzeit mit aktiviertem SnapStart und mit DynamoDB-Aufrufvorbereitung in ms:
| GC Algorithm |
c p50 |
c p75 |
c p90 |
c p99 |
c p99.9 |
c max |
w p50 |
w p75 |
w p90 |
w p99 |
w p99.9 |
w max |
| G1 |
833.50 |
875.34 |
1089.53 |
1205.26 |
1269.56 |
1269.8 |
5.46 |
6.10 |
7.16 |
16.39 |
46.19 |
499.13 |
| Parallel Collector |
900.18 |
975.12 |
1058.41 |
1141.94 |
1253.17 |
1253.99 |
5.82 |
6.61 |
7.75 |
16.87 |
49.64 |
487.73 |
| Shenandoah |
1065.84 |
1131.71 |
1331.96 |
1473.44 |
1553.59 |
1554.95 |
5.77 |
6.40 |
7.39 |
17.20 |
65.06 |
500.48 |
Abschluss
In diesem Artikel haben wir die Auswirkungen von Java-Garbage-Collection-Algorithmen (G1, Parallel Collector und Shenandoah) auf die Leistung der Lambda-Funktion mit Java 21-Laufzeit untersucht. Wir haben einen erheblichen Unterschied in der Leistung dieser Algorithmen festgestellt. Wenn wir die Standardeinstellungen mit G1 (Standardeinstellung) verwenden, erleben wir (manchmal bei weitem) die niedrigsten Kalt- und Warmstartzeiten. Durch die Verwendung von SnapStart mit Priming der DynamoDB-Anfrage liegen die Leistungsergebnisse erwartungsgemäß viel näher beieinander.
Bitte lesen Sie in der Dokumentation jedes Garbage-Collection-Algorithmus nach, um Einstellungen wie Mischung und maximalen Speicher zu optimieren, die zu einer deutlichen Leistungsverbesserung führen können, und führen Sie Ihre eigenen Messungen durch.
Das obige ist der detaillierte Inhalt vonAWS SnapStart – Teil Messung von Kalt- und Warmstarts mit Java unter Verwendung verschiedener Garbage-Collection-Algorithmen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
