在第 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 内存。
让我们首先解释如何在 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 Gateway 请求,无需通过网络 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 函数在 1 小时内以 1024 MB 内存设置重现超过 100 次冷启动和大约 100.000 次热启动。为此,我使用了负载测试工具,但是您可以使用任何您想要的工具,例如 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) 通过 API Gateway 请求调用启动/代理启用 SnapStart
在template.yaml中使用以下配置:
Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest SnapStart: ApplyOn: PublishedVersions
并且我们需要调用名称为
的Lambda函数
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming 映射到 GetProductByIdWithWebRequestPrimingHandler Lambda Handler Java 类。
缩写c表示冷启动,w表示热启动。
冷 (c) 和热 (w) 启动时间(以毫秒为单位):
场景编号 | c p50 | c p75 | c p90 | c p99 | c p99.9 | c 最大 | w p50 | w p75 | w p90 | w p99 | w p99.9 | w 最大值 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
未启用 SnapStart | 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 已启用,但未应用启动 | 2006.60 | 2065.61 | 2180.17 | 2604.69 | 2662.60 | 2663.54 | 7.45 | 8.40 | 9.92 | 23.09 | 1354.50 | 1496.46 |
通过 DynamoDB 调用启动启用 SnapStart | 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 通过 API Gateway 请求调用启动启用 | 855.45 | 953.91 | 1107.10 | 1339.97 | 1354.78 | 1355.21 | 8.00 | 9.53 | 12.09 | 26.31 | 163.26 | 547.28 |
通过单独在 Lambda 函数上启用 SnapStart,可以显着减少 Lambda 函数的冷启动时间。通过另外使用 DynamoDB 调用启动,我们能够实现的冷启动仅略高于我的文章 AWS SnapStart -Measuring Cold and Warm Start with Java 21 using different memory settings(我们在其中测量了纯 Lambda 的冷启动和热启动)中描述的冷启动无需使用任何框架(包括 1024MB 内存设置,如我们的场景中)即可运行该功能。
比较我们在使用 AWS Serverless Java Container 测量冷启动和热启动和使用 AWS Lambda Web Adapter 测量冷启动和热启动一文中使用 AWS Serverless Java Container 测量的冷启动时间和热启动时间,我们发现 Spring Cloud Function 提供了更高的冷启动时间启动时间比 AWS Lambda Web Adaptor 短,但冷启动时间与 AWS Serverless Java Container 相当(结果因百分位数而略有不同)。就热启动/执行时间而言,特别是考虑低于 99.9 的百分位数时,所有 3 种方法都具有相当可比的结果。
免責聲明: 提供的所有資源部分來自互聯網,如果有侵犯您的版權或其他權益,請說明詳細緣由並提供版權或權益證明然後發到郵箱:[email protected] 我們會在第一時間內為您處理。
Copyright© 2022 湘ICP备2022001581号-3