介紹
在本系列的前幾部分中，我們在未啟用SnapStart 的情況下使用Java 21 運行時測量了Lambda 函數的冷啟動，在啟用SnapStart 的情況下，還使用不同的Lambda 內存設定、Lambda 部署工件大小、Java 應用了DynamoDB 呼叫啟動最佳化編譯選項、(a)同步HTTP 用戶端以及不同Lambda 層的使用。 對於所有這些測量，我們使用預設的垃圾收集演算法 G1。
在本文中，我們將探討 Java 垃圾收集演算法對 Java 21 執行時期的 Lambda 函數效能的影響。我們還將重新測量 G1 的所有內容，以便與所有垃圾收集演算法使用的相同次要 Java 21 版本獲得可比較的結果。
Java 垃圾回收演算法
對於我們的測量，我們將使用以下 Java 集合演算法及其預設設定（請參閱連結文件以取得有關每種演算法的更多詳細資訊）：
-
垃圾優先 (G1) 垃圾收集器。這是預設使用的垃圾收集演算法。您可以透過將 -XX:+UseG1GC 新增至 JAVA_TOOL_OPTIONS 環境變數來在 AWS SAM 範本中明確設定它。
-
並行收集器。您可以透過將 -XX:+UseParallelGC 新增至 JAVA_TOOL_OPTIONS 環境變數來在 AWS SAM 範本中明確設定它。
-
謝南多厄GC。 Oracle JDK 不提供它，但 Amazon Corretto 21 JDK 提供。您可以透過將 -XX:+UseShenandoahGC 新增至 JAVA_TOOL_OPTIONS 環境變數來在 AWS SAM 範本中明確設定它。
-
Z 垃圾收集器。有 2 種不同的 ZGC 演算法：預設演算法和較新的一代演算法。您可以透過將 -XX:+UseZGC 或 -XX:+UseZGC -XX:+ZGenerational 新增至 JAVA_TOOL_OPTIONS 環境變量，在 AWS SAM 範本中明確設定它。
使用不同的垃圾收集演算法測量 Java 21 的冷啟動和熱啟動
在我們的實驗中，我們將使用第 9 部分中介紹的稍作修改的應用程式。您可以在此處找到應用程式代碼。基本上有 2 個 Lambda 函數，它們既回應 API 閘道請求，又透過 DynamoDB 從 API 閘道收到的 ID 檢索產品。第一個 Lambda 函數 GetProductByIdWithPureJava21LambdaWithGCAlg 可以在有或沒有 SnapStart 的情況下使用，第二個 GetProductByIdWithPureJava21LambdaAndPrimingWithGCAlg 使用 SnapStart 和 DynamoDB 要求呼叫啟動。
以下實驗的結果是基於重現超過 100 次冷啟動和大約 100,000 次熱啟動，實驗運行時間約為 1 小時。為此（以及我上一篇文章中的實驗），我使用了負載測試工具嘿，但您可以使用任何您想要的工具，例如 Serverless-artillery 或 Postman。我們透過為Lambda 函數提供1024 MB 記憶體並使用JAVA_TOOL_OPTIONS 來運行實驗：「-XX:+TieredCompilation -XX:TieredStopAtLevel=1」（不進行分析的Java 用戶端編譯），這在冷啟動時間和熱啟動時間之間具有非常好的權衡。
不幸的是，我無法使 Lambda 函數啟動，Z 垃圾收集器（預設的和一代的）都會遇到錯誤：
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.
登入後複製
它嘗試了更大的記憶體設置，例如 1024、2048 MB 甚至更多 MB，但仍然出現相同的錯誤。
讓我們來看看其他 3 種垃圾收集演算法的測量結果。
縮寫c表示冷啟動，w表示熱啟動。
未啟用 SnapStart 的冷 (c) 和熱 (w) 啟動時間（以毫秒為單位）：
| 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 |
啟用 SnapStart 且未啟動的冷 (c) 和熱 (w) 啟動時間（以毫秒為單位）：
| 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 |
啟用 SnapStart 和 DynamoDB 呼叫啟動的冷 (c) 和熱 (w) 啟動時間（以毫秒為單位）：
| 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 |
結論
在本文中，我們探討了 Java 垃圾收集演算法（G1、Parallel Collector 和 Shenandoah）對 Java 21 執行時期的 Lambda 函數效能的影響。我們發現這些演算法的效能有很大差異。使用 G1 的預設設定（預設設定），我們會經歷（有時是迄今為止）最低的冷啟動和熱啟動時間。透過使用 SnapStart 啟動 DynamoDB 請求，效能結果與預期更加接近。
請參閱每種垃圾收集演算法的文件來調整混合和最大記憶體等設置，這可以顯著提高效能並進行您自己的測量。
以上是AWS SnapStart - 使用不同的垃圾收集演算法透過 Java 測量冷啟動和熱啟動的部分的詳細內容。更多資訊請關注PHP中文網其他相關文章！
