AWS SnapStart - 使用 Lambda 層透過 Java 測量冷啟動和熱啟動部分 (1)

介紹

在部落格文章如何為 Java 21 Lambda 函數建立、發布和使用層中，我們發布了第一個使用 Java 21 的 Lambda 層。在本文中，我們將使用此 Lambda 層建立應用程序，然後測量冷啟動和熱啟動未啟用 SnapStart 的時間、啟用 SnapStart 並套用 DynamoDB 呼叫啟動最佳化的時間。我們還將結果與我們的測量結果進行比較，而不使用Lambda 層並在POM 文件中提供所有依賴項，正如我們在使用不同Lambda 內存設置通過Java 21 測量冷啟動和熱啟動一文中所做的那樣。

使用 Lambda 層從 Java 21 測量冷啟動和熱啟動

在我們的實驗中，我們將使用範例應用程式。 AWS SAM 範本中基本上定義了 2 個 Lambda 函數，它們都會回應 API 閘道請求並透過從 DynamoDB 從 API 閘道收到的 ID 擷取產品。第一個 Lambda 函數 GetProductByIdWithPureJava21LambdaWithCommonLayer 可以在有或沒有 SnapStart 的情況下使用，第二個 GetProductByIdWithPureJava21LambdaAndPrimingWithCommonLayer 使用 SnapStart 和 DynamoDB 要求呼叫啟動。

透過 Lambda 層提供的依賴項的範圍在我們應用程式的 pom.xml 檔案中「提供」。

為了附加在如何為AWS SAM 模板中的Lambda 函數創建Java 21 Lambda 函數的發布和使用層一文中創建的Lambda 層，我們必須向Lambda 函數添加Layers 參數，如下所示：

    Type: AWS::Serverless::Function
    Properties:
      FunctionName: GetProductByIdWithPureJava21LambdaWithCommonLayer
      AutoPublishAlias: liveVersion
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:layer:aws-pure-java-21-common-lambda-layer:1
      Handler: software.amazonaws.example.product.handler.GetProductByIdHandler::handleRequest

請將層 ARN（包括版本）替換為您自己的層 ARN，該 ARN 是發布層命令 (aws lambdapublish-layer-version) 的輸出。

以下實驗的結果是基於重現超過 100 次冷啟動和大約 100,000 次熱啟動，實驗運行時間約為 1 小時。為此（以及我上一篇文章中的實驗），我使用了負載測試工具嘿，但您可以使用任何您想要的工具，例如 Serverless-artillery 或 Postman。
我透過為Lambda 函數提供1024 MB 記憶體並透過環境變數傳遞以下編譯選項來運行所有這些實驗： JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1" （無需分析的客戶端編譯），這提供了非常好的冷啟動時間和熱啟動時間之間的良好權衡。

在下表中，我還將提供我們的測量結果，而不使用Lambda 層，該層摘自《使用不同Lambda 內存設置使用Java 21 測量冷啟動和熱啟動》一文，以直接對兩者進行比較。
縮寫 c 表示冷啟動，w 表示熱啟動。

不使用 SnapStart 的冷 (c) 和熱 (w) 啟動時間（以毫秒為單位）：

Experiment	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
with common Lambda Layer	3497.91	3597.18	3695.58	3800.47	3908.33	4011.71	5.82	6.72	8.00	17.97	55.48	1709.13
w/o Lambda Layer	3157.6	3213.85	3270.8	3428.2	3601.12	3725.02	5.77	6.50	7.81	20.65	90.20	1423.63

沒有啟動的 SnapStart 的冷 (c) 和熱 (w) 啟動時間（以毫秒為單位）：

Experiment	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
with common Lambda Layer	2047.12	2124.24	2439.49	2705.52	2735.43	2831.59	5.68	6.40	7.45	17.06	48.45	2139.74
w/o Lambda Layer	1626.69	1741.10	2040.99	2219.75	2319.54	2321.64	5.64	6.41	7.87	21.40	99.81	1355.09

使用 SnapStart 和 DynamoDB 呼叫啟動冷 (c) 和熱 (w) 時間（以毫秒為單位）：

Experiment	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
with common Lambda Layer	713.88	766.38	1141.94	1181.41	1214.94	1215.32	5.59	6.30	7.39	16.39	45.09	574.61
w/o Lambda Layer	702.55	759.52	1038.50	1169.66	1179.05	1179.36	5.73	6.51	7.87	21.75	92.19	328.41

結論

在本文中，我們使用具有常見依賴項的Lambda 層創建了應用程序，然後在未啟用SnapStart 的情況下測量了冷啟動和熱啟動時間，在啟用SnapStart 的情況下還應用了DynamoDB 呼叫啟動優化，並將結果與我們在不使用Lambda 的情況下的測量結果進行了比較層並提供POM 文件中的所有依賴項，正如我們在使用不同Lambda 內存設置從Java 21 測量冷熱啟動一文中所做的那樣。

我已經使用常見的 Lambda 層進行了多次測量，以真正確認我的實驗結果。即使這些測量之間的結果存在一些偏差，趨勢也始終是相同的：當未啟用SnapStart 或啟用它但不使用DynamoDB 呼叫啟動時，冷啟動 使用常見Lambda與僅將所有依賴項打包在POM 檔案中相比，分層的時間快幾百毫秒。只有在為 Lambda 函數啟用 SnapStart 並套用 DynamoDB 呼叫啟動時，兩種方法的冷啟動非常接近，可能是因為所有內容都已在建立的快照中。

Lambda 函數的熱啟動 幾乎所有百分位數的用例（使用和不使用Lambda 層）和所有實驗（啟用和不啟用SnapStart）都非常接近，但透過使用通用Lambda層，我總是能得到更高的最大值結果。

在下一篇文章中，我將繼續使用 Lambda 層進行實驗。這次，我將建立、發布和使用 Lambda 層，該層不僅包含常見依賴項（如本文所示），還包含執行此應用程式所需的所有依賴項，然後比較兩個實驗的結果。

以上是AWS SnapStart - 使用 Lambda 層透過 Java 測量冷啟動和熱啟動部分 (1)的詳細內容。更多資訊請關注PHP中文網其他相關文章！