介绍
在系列的第 7 部分：使用适用于 Java 的 AWS 开发工具包的 Amazon Aurora Serverless v2 的数据 API - 数据 API 与 SnapStart 的结合，我们测量了使用 Data API 连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数的冷启动时间和热启动时间3 个用例：
- 未在 Lambda 函数上启用 SnapStart
- 在 Lambda 函数上启用 SnapStart，但没有启动优化
- 在 Lambda 函数上启用 SnapStart 并进行启动优化（在 PostgreSQL 数据库上预热 SQL 语句执行）。
在本文中，我们希望将这些测量值与使用 DynamoDB 而不是 Amazon Aurora Serverless v2 的 Data API 时的测量值进行比较。
比较 Lambda 冷启动和热启动：Amazon Aurora Serverless v2 的数据 API 与 DynamoDB
在我关于 Lambda SnapStart 的文章系列中，我们已经对类似的应用程序进行了此类测量，但在文章中使用不同的 Lambda 内存设置测量 Java 21 的热启动。
Amazon Aurora Serverless v2 和 DynamoDB 的应用程序数据 API 非常相似：
立即学习“Java免费学习笔记（深入）”；
- 它们提供从数据库存储和检索产品的逻辑
- 两个项目的 Lambda 函数都有 1024 MB 内存设置
- 两者的部署工件大小约为 18 MB
- 两个项目中的 Lambda 函数都使用默认的同步 HTTP Apache 客户端与数据库进行通信
- 两个项目的 Lambda 函数都使用 x86_64 架构
现在让我们将所有测量结果放在一起。
冷 (c) 和热 (m) 开始时间（以毫秒为单位）：
| 接近 | c p50 | c p75 | c p90 | c p99 | c p99.9 | c 最大 | wp50 | w p75 | wp90 | wp99 | w p99.9 | w 最大 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 数据 API，未启用 SnapStart | 3154.35 | 3237 | 3284.91 | 3581.49 | 3702.12 | 3764.92 | 104.68 | 173.96 | 271.32 | 572.11 | 1482.89 | 2179.7 |
| DynamoDB，未启用 SnapStart | 3157.6 | 3213.85 | 3270.8 | 3428.2 | 3601.12 | 3725.02 | 5.77 | 6.50 | 7.81 | 20.65 | 90.20 | 1423.63 |
| 数据 API，无需启动即可启用 SnapStart | 1856.11 | 1994.61 | 2467.83 | 3229.11 | 3238.80 | 3241.75 | 61.02 | 113.32 | 185.37 | 639.35 | 1973.30 | 2878.5 |
| 无需启动即可启用 DynamoDB、SnapStart | 1626.69 | 1741.10 | 2040.99 | 2219.75 | 2319.54 | 2321.64 | 5.64 | 6.41 | 7.87 | 21.40 | 99.81 | 1355.09 |
| 数据 API，通过启动启用 SnapStart | 990.84 | 1069.04 | 1634.84 | 2120.00 | 2285.03 | 2286.9 | 60.06 | 106.35 | 185.37 | 581.27 | 1605.37 | 2658.24 |
| DynamoDB、SnapStart 通过启动启用 | 702.55 | 759.52 | 1038.50 | 1169.66 | 1179.05 | 1179.36 | 5.73 | 6.51 | 7.87 | 21.75 | 92.19 | 328.41 |
结论
在本文中，我比较了使用 Data API 连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数与连接到 DynamoDB 数据库的 3 个用例的冷启动时间和热启动时间的测量结果：
- 未在 Lambda 函数上启用 SnapStart
- 在 Lambda 函数上启用 SnapStart，但没有启动优化
- 在 Lambda 函数上启用 SnapStart 并启动数据库请求
我们观察到，在 Lambda 函数上未启用 SnapStart 的情况下，两者的冷启动时间相当相似。 如果启用了 SnapStart（没有启动，尤其是启动启动），Amazon Aurora Serverless v2 的数据 API 的冷启动时间明显更长，特别是对于百分位数 >= 90。我需要更深入地挖掘以了解这种差异，因为我没有预计它会那么大，尤其是在使用底漆的情况下。也许原因是像 DynamoDB 这样的 AWS 原生服务更能感知 SnapStart，我可以更好地处理连接恢复。
与 DynamoDB 相比，Amazon Aurora Serverless v2 的数据 API 的热启动（执行）时间始终要高得多，这也是我所期望的，因为 DynamoDB 以其单位数或两位数毫秒响应时间而闻名。
