介绍

在博客文章如何为 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 层摘自《使用不同 Lambda 内存设置通过 Java 21 测量冷启动和热启动》一文，以直接对两者进行比较。
缩写 c 表示冷启动，w 表示热启动。

不使用 SnapStart 的冷 (c) 和热 (w) 启动时间（以毫秒为单位）：

没有启动的 SnapStart 的冷 (c) 和热 (w) 启动时间（以毫秒为单位）：

SnapStart 和 DynamoDB 调用的冷 (c) 和热 (w) 启动时间（毫秒）：

结论

在本文中，我们使用具有常见依赖项的 Lambda 层创建了应用程序，然后在未启用 SnapStart 的情况下测量了冷启动和热启动时间，在启用 SnapStart 的情况下还应用了 DynamoDB 调用启动优化，并将结果与​​我们在不使用 Lambda 的情况下的测量结果进行了比较层并提供 POM 文件中的所有依赖项，正如我们在使用不同 Lambda 内存设置从 Java 21 测量冷热启动一文中所做的那样。

我已经使用常见的 Lambda 层进行了多次测量，以真正确认我的实验结果。即使我在这些测量之间的结果存在一些偏差，趋势始终是相同的：当未启用 SnapStart 或启用它但不使用 DynamoDB 调用的启动时，冷启动并使用常见的 Lambda与仅将所有依赖项打包在 POM 文件中相比，分层的时间要快几百毫秒。仅当为 Lambda 函数启用 SnapStart 并应用 DynamoDB 调用启动时，两种方法的冷启动非常接近，可能是因为所有内容都已在创建的快照中。

Lambda 函数的热启动 对于几乎所有百分位的两个用例（使用和不使用 Lambda 层）和所有实验（启用和不启用 SnapStart）都非常接近，但通过使用通用 Lambda 层，我总是能获得更高的最大值结果。

在下一篇文章中，我将继续使用 Lambda 层进行实验。这次，我将创建、发布和使用 Lambda 层，该层不仅包含常见依赖项（如本文中所示），还包含运行此应用程序所需的所有依赖项，然后比较两个实验的结果。