使用適用於 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中文網其他相關文章！