AWS Lambda 与 Java xvs arm 的性能 - 部分初始测量

介绍

到目前为止，我还没有针对 arm64 架构的某些用例（例如发出 DynamoDB 请求）使用 Java 21 运行时测量 Lambda 函数的性能（热启动时间和冷启动时间），因为它不支持 SnapStart。具有启用 SnapStart 的 x86_64 架构的 Java 21 运行时的 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) 开始时间（以毫秒为单位）：

Approach	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
x86_64, no SnapStart enabled	3554.30	3615.21	3666.15	3800.47	4108.61	4111.78	5.42	6.01	6.88	14.09	40.98	1654.59
arm64, no SnapStart enabled	3834.81	3904.42	3983.26	4047.47	4332.13	4335.74	5.96	6.66	7.69	16.01	43.68	1844.54
x86_64, SnapStart enabled without priming	1794.09	1846.86	2090.54	2204.27	2239.80	2240.08	5.37	5.96	6.93	15.88	51.64	1578.34
arm64, SnapStart enabled without priming	1845.01	1953.18	2591.70	2762.91	2793.45	2795.8	5.91	6.56	7.63	16.75	63.52	1779.14
x86_64, SnapStart enabled with DynamoDB request priming	803.18	870.18	1103.78	1258.19	1439.95	1440.67	5.55	6.25	7.45	15.50	63.52	448.85
arm64, SnapStart enabled with DynamoDB request priming	910.14	1001.79	1376.62	1623.44	1684.60	1686.19	6.05	6.72	7.81	16.66	74.68	550.59

结论

在本文中，我们比较了 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 之间的不同值，并比较结果。

以上是AWS Lambda 与 Java xvs arm 的性能 - 部分初始测量的详细内容。更多信息请关注PHP中文网其他相关文章！