介紹
在第 8 部分中，我們介紹了 Spring Cloud 函數背後的概念，在第 9 部分中，我們示範如何使用 Java 21 和 Spring Boot 3.2 透過 Spring Cloud Function 開發 AWS Lambda。在本系列的這篇文章中，我們將測量冷啟動和熱啟動時間，包括在Lambda 函數上啟用SnapStart，同時應用各種啟動技術，例如啟動DynamoDB 呼叫和啟動（代理）整個API 網關請求，而無需透過網路。我們將使用 Spring Boot 3.2 範例應用程式進行測量，並對所有 Lambda 函數使用 JAVA_TOOL_OPTIONS：“-XX:+TieredCompilation -XX:TieredStopAtLevel=1”，並為它們提供 Lambda 1024 MB 記憶體。
使用 Spring Cloud Function 並使用 Java 21 和 Spring Boot 3.2 測量冷啟動和熱時間
我們首先解釋如何在 Lambda 函數上啟用 AWS SnapStart，因為它（頂部啟動）提供了最大的 Lambda 效能（尤其是冷啟動時間）最佳化潛力。這只是一個設定問題：
SnapStart:
ApplyOn: PublishedVersions
登入後複製
應用於 Lambda 函數屬性或 SAM 範本的全域函數部分。我想更深入地了解如何在 SnpaStart 之上為我們的用例使用各種啟動技術。我在文章 AWS Lambda SnapStart - 測量啟動、端到端延遲和部署時間中解釋了啟動背後的想法
1) 啟動 DynamoDB 請求的程式碼可以在此處找到。
此類別也實作了 CraC 專案的 import org.crac.Resource 介面。
透過這個呼叫
Core.getGlobalContext().register(this);
登入後複製
GetProductByIdWithDynamoDBRequestPrimingHandler 類別將自身註冊為 CRaC 資源。
我們也透過從 CRaC API 實作 beforeCheckpoint 方法來啟動 DynamoDB 呼叫。
@Override
public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {
productDao.getProduct("0");
}
登入後複製
我們將在 Lambda funtiom 的部署階段以及拍攝 Firecracker microVM 快照之前呼叫它。
2) 啟動整個 API Gateway 請求的程式碼可以在這裡找到。
此類也額外實現了 import org.crac.Resource 接口，如上例所示。
我們將重新使用我在文章 AWS Lambda SnapStart - 第 6 部分啟動 Java 11 和 Micronaut、Quarkus 和 Spring Boot 框架的請求呼叫 中描述的醜陋技術。我不建議在生產中使用這種技術，但它展示了透過預先載入Spring Boot 和Spring Cloud Function 模型以及執行DynamoDB 的Lambda 模型之間的對應來啟動整個API Gateway 請求來減少冷啟動的進一步潛力呼叫啟動。
id 等於 0 的 /products/{id} 的 API Gateway 請求建構 API Gateway JSON 請求如下：
private static String getAPIGatewayRequestMultiLine () {
return """
{
"resource": "/products/{id}",
"path": "/products/0",
"httpMethod": "GET",
"pathParameters": {
"id": "0"
},
"requestContext": {
"identity": {
"apiKey": "blabla"
}
}
}
""";
}
登入後複製
beforeCheckpoint 使用Spring Cloud Function 啟動（代理）整個API 網關請求，無需透過網路FunctionInvoker 類，透過傳遞API 的輸入流來呼叫其handleRequest 方法上面建立的網關JSON 請求如下所示：
@Override
public void beforeCheckpoint(org.crac.Context<? extends Resource> context) throws Exception {
new FunctionInvoker().handleRequest(
new ByteArrayInputStream(getAPIGatewayRequestMultiLine().
getBytes(StandardCharsets.UTF_8)),
new ByteArrayOutputStream(), new MockLambdaContext());
}
登入後複製
下面的實驗結果是基於使用 Lambda 函數在 1024 MB 記憶體設定下重現超過 100 次冷啟動和大約 100.000 次熱啟動，持續時間為 1 小時。為此，我使用了負載測試工具，但是您可以使用任何您想要的工具，例如 Serverless-artillery 或 Postman。
我用 4 種不同的場景進行了所有這些實驗：
1) 未啟用 SnapStart
在 template.yaml 中使用以下配置：
Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
#SnapStart:
#ApplyOn: PublishedVersions
登入後複製
我們需要呼叫名為 GetProductByIdWithSpringBoot32SCF 的 Lambda 函數，該函數會對應到 GetProductByIdHandler Lambda Handler Java 類別。
2) SnapStart 已啟用，但未套用啟動
在 template.yaml 中使用以下配置：
Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
SnapStart:
ApplyOn: PublishedVersions
登入後複製
我們需要呼叫名稱為 GetProductByIdWithSpringBoot32SCF 的相同 Lambda 函數，該函數會對應到 GetProductByIdHandler Lambda Handler Java 類別。
3) 透過 DynamoDB 呼叫啟動啟用 SnapStart
在 template.yaml 中使用以下配置：
Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
SnapStart:
ApplyOn: PublishedVersions
登入後複製
我們需要呼叫名為 GetProductByIdWithSpringBoot32SCFAndDynamoDBRequestPriming 的 Lambda 函數，該函數會對應到 GetProductByIdWithDynamoDBRequestPrimingHandler Lambda Handler Java 類別。
4) SnapStart 透過 API 閘道請求呼叫啟動/代理啟用
在 template.yaml 中使用以下配置：
Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
SnapStart:
ApplyOn: PublishedVersions
登入後複製
and we need to invoke Lambda function with name
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming which is mapped to the GetProductByIdWithWebRequestPrimingHandler Lambda Handler Java class.
Abbreviation c is for the cold start and w is for the warm start.
Cold (c) and warm (w) start time in ms:
| Scenario Number |
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 |
| No SnapStart enabled |
4768.34 |
4850.11 |
4967.86 |
5248.61 |
5811.92 |
5813.31 |
7.16 |
8.13 |
9.53 |
21.75 |
62.00 |
1367.52 |
| SnapStart enabled but no priming applied |
2006.60 |
2065.61 |
2180.17 |
2604.69 |
2662.60 |
2663.54 |
7.45 |
8.40 |
9.92 |
23.09 |
1354.50 |
1496.46 |
| SnapStart enabled with DynamoDB invocation priming |
1181.40 |
1263.23 |
1384.90 |
1533.54 |
1661.20 |
1662.17 |
7.57 |
8.73 |
10.83 |
23.83 |
492.37 |
646.18 |
| SnapStart enabled with API Gateway request invocation priming |
855.45 |
953.91 |
1107.10 |
1339.97 |
1354.78 |
1355.21 |
8.00 |
9.53 |
12.09 |
26.31 |
163.26 |
547.28 |
Conclusion
By enabling SnapStart on the Lambda function alone, it reduces the cold start time of the Lambda function significantly. By additionally using DynamoDB invocation priming we are be able to achieve cold starts only slightly higher than cold starts described in my article AWS SnapStart -Measuring cold and warm starts with Java 21 using different memory settings where we measured cold and warm starts for the pure Lambda function without the usage of any frameworks including 1024MB memory setting like in our scenario.
Comparing the cold and warm start times we measured with AWS Serverless Java Container in the article Measuring cold and warm starts with AWS Serverless Java Container and Measuring cold and warm starts with AWS Lambda Web Adapter we observe that Spring Cloud Function offers higher cold start times than AWS Lambda Web Adapter but quite comparable cold start times to AWS Serverless Java Container (results vary slightly depending on the percentiles). In terms of warm start/execution times all 3 approaches have quite comparable results when especially looking into the percentiles below 99.9.
以上是AWS Lambda 上的 Spring Boot 應用程式 - 使用 Spring Cloud Function 測量冷啟動和熱啟動部分的詳細內容。更多資訊請關注PHP中文網其他相關文章！
