介绍

到目前为止，我还没有针对 arm64 架构的某些用例（例如发出 DynamoDB 请求）使用 Java 21 运行时测量 Lambda 函数的性能（热启动时间和冷启动时间），因为它不支持 SnapStart。具有 Java 21 运行时（采用 x86_64 架构且启用了 SnapStart）的 Lambda 将优于采用 arm64 架构的 Lambda（通过额外的启动优化更是如此）。但在 2024 年 7 月 18 日，AWS 宣布 AWS Lambda 现在支持使用 ARM64 架构的 Java 函数的 SnapStart。因此，现在开始测量冷启动时间和热启动时间并考虑 Lambda 函数架构的选择对我来说是有意义的。据了解，按照目前AWS Lambda的定价内存设置和执行时长，arm64架构的Lambda将约为。比 x86_64 架构的 Lambda 便宜 25%。

我决定为其创建单独的文章系列，而不是将此主题添加到我不断增长的 AWS Lambda SnapStart 系列中。

测量示例应用的冷启动和热启动

在我们的实验中，我们将重复使用 AWS Lambda SnapStart - 测量 Java 21 Lambda 冷启动一文中介绍的应用程序。这是示例应用程序的代码。基本上有 2 个主要 Lambda 函数，它们都响应 API Gateway 请求以使用给定 id 创建产品（请参阅 PutProductFunction Lambda 函数）并通过给定 id 检索产品（请参阅 GetProductByIdFunction Lambda 函数）。您可以在启用或不启用 SnapStart 的情况下使用 Lambda 函数。我编写了一个额外的 Lambda 函数 GetProductByIdWithPrimingFunction，用于独立测量 DynamoDB 请求启动对启用 SnapStart 的 Lambda 函数的影响。您可以在我的文章 AWS Lambda SnapStart - 测量启动、端到端延迟和部署时间中阅读有关启动效果的更多信息。

要在所有 Lambda 函数上启用 SnapStart，请取消 SAM 模板中以下内容的注释：

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    SnapStart:
     ApplyOn: PublishedVersions  
   ...

如果我只想将 SnapStart 用于单个函数，而不是所有 Lambda 函数，则必须在 Lambda 函数级别而不是全局函数级别应用此 SnapStart 定义。

所有 Lambda 函数都以以下设置为起点：

• 1024 MB内存设置
• 用于与 DynamoDB 数据库通信的默认 HTTP Apache 客户端
• Java 编译选项“-XX: TieredCompilation -XX:TieredStopAtLevel=1”被证明可以在冷启动时间和热启动时间之间提供非常好的权衡

在 SAM 模板中，我添加了在全局 Lambda 函数部分中定义 Lambda 架构的可能性，例如：

Globals:
  Function:
    CodeUri: target/aws-pure-lambda-snap-start-21-1.0.0-SNAPSHOT.jar
    ...
    Architectures:
      #- arm64
      - x86_64   

只需取消注释您想要用于 Lambda 函数的架构。

即使 Java 是“一次编写，到处运行”，我还是通过预先安装在带有 Graviton 处理器（基于 arm64/aarch64 架构）的 t4g AWS EC2 实例上编译并构建了应用程序 jar 文件，用于我的 arm64 测量适用于 Linux aarch64 的 Amazon Corretto 21。你可以在这里找到这个罐子。

我还再次重新测量了 x86_64 架构的所有内容，以便使用相同的 Corretto Java 21 最新运行时版本（在我测量时为 Java 21.v17 ）获得可比较的结果。

下面的实验结果基于再现超过 100 次冷启动和大约 100.000 次热启动。为此（以及我上一篇文章中的实验），我使用了负载测试工具嘿，但是您可以使用任何您想要的工具，例如 Serverless-artillery 或 Postman。 同样重要的是要注意，我在应用程序的新源代码（重新）部署之后立即开始测量。请注意，快照分层缓存对冷启动也有影响，第一次调用通常较慢，后续调用会变快，直到达到一定数量的调用。

现在，让我们将“通过现有 id 获取产品”的所有测量结果（Lambda 函数 GetProductByIdFunction 和 GetProductByIdWithPrimingFunction 用于启用 SnapStart 和启动测量）情况放在一起。

冷 (c) 和热 (m) 启动时间（以毫秒为单位）：

结论

在本文中，我们针对 3 个用例比较了连接 DynamoDB 数据库的 Lambda 函数的冷启动时间和热启动时间的测量结果：

• 未在 Lambda 函数上启用 SnapStart
• 在 Lambda 函数上启用 SnapStart，但没有启动优化
• 在 Lambda 函数上启用 SnapStart 并启动 DynamoDB 请求

我们发现，通过使用 x86_64 架构，所有冷启动和热启动时间都比arm64 架构要短。但由于 arm64 架构 Lambda 定价比 x86_64 架构便宜 25%，它引入了非常有趣的性价比权衡。

对于我们的测量，对于所有 3 个用例：

• 与 x86_64 架构相比，arm64 架构的 Lambda 冷启动时间在许多百分位上仅慢 10-20%（仅在极少数情况下慢 25-27%）。
• arm64 架构的 Lambda 热启动时间在许多百分位数上仅比 x86_64 架构慢 5-10%。

因此，对于这个示例应用程序来说，选择arm64架构是相当合理的。由于 SnapStart 对 arm64 架构的支持最近才推出，我也预计未来会有一些性能改进。请根据您的用例自行测量！

在本文的下一部分中，我们将进行相同的性能测量，但将 Lambda 内存设置为 256 到 2048 MB 之间的不同值，并比较结果。