在博客文章如何为 Java 21 Lambda 函数创建、发布和使用层中,我们发布了第一个使用 Java 21 的 Lambda 层。在本文中,我们将使用此 Lambda 层创建应用程序,然后测量冷启动和热启动未启用 SnapStart 的时间、启用 SnapStart 并应用 DynamoDB 调用启动优化的时间。我们还将结果与我们的测量结果进行比较,而不使用 Lambda 层并在 POM 文件中提供所有依赖项,正如我们在使用不同 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中文网其他相关文章!