AWS Lambda 與 Java xvs arm 的效能 - 部分初始測量

介紹

到目前為止，我還沒有針對 arm64 架構的某些用例（例如發出 DynamoDB 請求）使用 Java 21 運行時測量 Lambda 函數的效能（熱啟動時間和冷啟動時間），因為它不支援 SnapStart。具有 Java 21 運行時（採用 x86_64 架構且啟用了 SnapStart）的 Lambda 將優於採用 arm64 架構的 Lambda（透過額外的啟動最佳化更是如此）。但在 2024 年 7 月 18 日，AWS 宣布 AWS Lambda 現在支援使用 ARM64 架構的 Java 函數的 SnapStart。因此，現在開始測量冷啟動時間和熱啟動時間並考慮 Lambda 函數架構的選擇對我來說是有意義的。據了解，依照目前AWS Lambda的定價記憶體設定和執行時長，arm64架構的Lambda將約為。比 x86_64 架構的 Lambda 便宜 25%。

我決定為其創建單獨的文章系列，而不是將此主題添加到我不斷增長的 AWS Lambda SnapStart 系列中。

測量範例應用的冷啟動和熱啟動

在我們的實驗中，我們將重複使用 AWS Lambda SnapStart - 測量 Java 21 Lambda 冷啟動一文中介紹的應用程式。這是範例應用程式的程式碼。基本上有 2 個主要 Lambda 函數，它們都回應 API Gateway 請求以使用給定 id 建立產品（請參閱 PutProductFunction Lambda 函數）並透過給定 id 檢索產品（請參閱 GetProductByIdFunction Lambda 函數）。您可以在啟用或不啟用 SnapStart 的情況下使用 Lambda 函數。我編寫了一個額外的 Lambda 函數 GetProductByIdWithPrimingFunction，用於獨立測量 DynamoDB 請求啟動對啟用 SnapStart 的 Lambda 函數的影響。您可以在我的文章 AWS Lambda SnapStart - 測量啟動、端對端延遲和部署時間中閱讀更多關於啟動效果的資訊。

要在所有 Lambda 函數上啟用 SnapStart，請在 SAM 範本中取消註解以下內容：

雷雷

如果我只想將 SnapStart 用於單一函數，而不是所有 Lambda 函數，則必須在 Lambda 函數層級而不是全域函數層級套用此 SnapStart 定義。

所有 Lambda 函數都以以下設定為起點：

• 1024 MB記憶體設定
• 預設 HTTP Apache 用戶端用於與 DynamoDB 資料庫通訊
• Java 編譯選項“-XX:+TieredCompilation -XX:TieredStopAtLevel=1”，事實證明可以在冷啟動時間和熱啟動時間之間提供非常好的權衡

在 SAM 範本中，我新增了在全域 Lambda 函數部分中定義 Lambda 架構的可能性，例如：

雷雷

只需取消註解您想要用於 Lambda 函數的架構即可。

即使Java 是“一次編寫，到處運行”，我還是通過之前安裝Amazon Corretto 在帶有Graviton 處理器（基於arm64/aarch64 架構）的t4g AWS EC2 實例上編譯並構建了應用程序jar 文件，用於我的arm64 測量21 適用於Linux aarch64。你可以在這裡找到這個罐子。

我還再次重新測量了 x86_64 架構的所有內容，以便使用相同的 Corretto Java 21 最新運行時版本（在我測量時為Java 21.v17.

）獲得可比較的結果

下面的實驗結果是基於再現超過 100 次冷啟動和大約 100.000 次熱啟動。為此（以及我上一篇文章中的實驗），我使用了負載測試工具嘿，但是您可以使用任何您想要的工具，例如 Serverless-artillery 或 Postman。 同樣重要的是要注意，我在應用程式的新原始程式碼（重新）部署之後立即開始測量。請注意，快照分層快取對冷啟動也有影響，第一次呼叫通常較慢，後續呼叫會變快，直到達到一定數量的呼叫。

現在讓我們將「透過現有 id 取得產品」的所有測量結果（Lambda 函數 GetProductByIdFunction 和 GetProductByIdWithPrimingFunction 用於啟用 SnapStart 並啟動測量）案例放在一起。

冷 (c) 和熱 (m) 開始時間（以毫秒為單位）：

Conclusion

In this article we compared measurements of the cold and warm start times of the Lambda function connecting to DynamoDB database for 3 use cases:

• without SnapStart enabled on the Lambda function
• with SnapStart enabled on the Lambda function but without priming optimization
• with SnapStart enabled on the Lambda function and with priming of the DynamoDB request

We saw that by using the x86_64 architecture all cold and warm start times were lower comparing to arm64 architecture. But asarm64 architecture Lambda pricing is 25% cheaper than x86_64 architecture, it introduces very interesting cost-performance trade off.

For our measurements, for all 3 use cases:

• Lambda cold start times with arm64 architecture were for many percentiles only 10-20% (and only in very rare cases 25-27%) slower compared to x86_64 architecture.
• Lambda warm start times with arm64 architecture were for many percentiles only 5-10% slower compared to x86_64 architecture.

So, the choice of arm64 architecture is quite reasonable for this sample application. As SnapStart support for arm64 architecture has only been introduced recently, I also expect some performance improvements in the future. Please do your own measurements for your use case!

In the next part of the article we'll do the same performance measurements but setting the Lambda memory to different values between 256 and 2048 MBs and compare the results.

以上是AWS Lambda 與 Java xvs arm 的效能 - 部分初始測量的詳細內容。更多資訊請關注PHP中文網其他相關文章！