介紹

在系列的第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) 啟動時間（以毫秒為單位）：

結論

在本文中，我比較了使用 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 以其單位數或兩位數毫秒回應時間而聞名。