使用适用于 Java 的 AWS 开发工具包实现 Amazon Aurora Serverless 的数据 API - 冷启动和热启动的部分比较：数据 API 与 DynamoDB

介绍

在系列的第 7 部分中，使用适用于 Java 的 AWS 开发工具包的 Amazon Aurora Serverless v2 的数据 API - 数据 API 与 SnapStart 的结合，我们使用 Data 测量了连接到 Amazon Aurora Serverless v2 PostgreSQL 数据库的 Lambda 函数的冷启动时间和热启动时间3 个用例的 API ：

• 未在 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 非常相似：

• 它们提供从数据库存储和检索产品的逻辑
• 两个项目的 Lambda 函数都有 1024 MB 内存设置
• 两者的部署工件大小约为 18 MB
• 两个项目中的 Lambda 函数都使用默认同步 HTTP Apache 客户端与数据库通信
• 两个项目的 Lambda 函数都使用 x86_64 架构

现在让我们将所有测量值放在一起。

冷 (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
Data API, no SnapStart enabled	3154.35	3237	3284.91	3581.49	3702.12	3764.92	104.68	173.96	271.32	572.11	1482.89	2179.7
DynamoDB, no SnapStart enabled	3157.6	3213.85	3270.8	3428.2	3601.12	3725.02	5.77	6.50	7.81	20.65	90.20	1423.63
Data API, SnapStart enabled without priming	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 enabled without priming	1626.69	1741.10	2040.99	2219.75	2319.54	2321.64	5.64	6.41	7.87	21.40	99.81	1355.09
Data API, SnapStart enabled with priming	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 enabled with priming	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 以其单位数或两位数毫秒响应时间而闻名。

以上是使用适用于 Java 的 AWS 开发工具包实现 Amazon Aurora Serverless 的数据 API - 冷启动和热启动的部分比较：数据 API 与 DynamoDB的详细内容。更多信息请关注PHP中文网其他相关文章！