介绍
在第 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中文网其他相关文章！
