對 Amazon DynamoDB 中的延遲問題進行疑難排解

如果您的工作負載似乎遇到高延遲，您可以分析 CloudWatchSuccessfulRequestLatency指標，並檢查平均延遲以查看其是否與 DynamoDB 相關。所報告 SuccessfulRequestLatency 中的某些變化是正常的，偶爾的尖峰 (尤其是在 Maximum 統計資料中) 也不用擔心。但是，如果 Average 統計資料顯示急劇增加且持續存在，則應該查看 AWS Service Health 儀表板和您的 Personal Health 儀表板，以取得更多資訊。一些可能的原因包括資料表中項目的大小 (1kb 項目和 400kb 項目的延遲會有所不同) 或查詢的大小 (10 個項目相較於 100 個項目)。

如有必要，請考慮使用 AWS Support 建立支援案例，然後根據您的執行手冊，繼續評估您應用程式的任何可用回復選項 (例如，如果您有多區域架構，則撤離一個區域)。您應該記錄請求 ID，以便在您開啟支援案例AWS Support時提供這些 ID 的緩慢要求。

SuccessfulRequestLatency 指標僅測量 DynamoDB 服務內部的延遲 - 不包括用戶端活動和網路往返時間。若要深入了解用戶端呼叫 DynamoDB 服務的整體延遲，您可以在 AWS SDK 中啟用延遲指標記錄。

注意

對於大部分單一操作 (透過完全指定主索引鍵的值來套用至單一項目的操作)，DynamoDB 提供個位數的毫秒 Average SuccessfulRequestLatency。此值不包括存取 DynamoDB 端點之呼叫者程式碼的傳輸負荷。對於多項目資料操作，延遲會因結果集的大小、傳回資料結構的複雜度，以及套用的任何條件表達式和篩選條件表達式等因素而有所不同。對於具有相同參數之相同資料集的重複多項操作，DynamoDB 提供高度一致的 Average SuccessfulRequestLatency。

請考慮下列一或多種策略來減少延遲：

• 調整請求逾時和重試行為：從用戶端到 DynamoDB 的路徑需周遊許多元件，每個元件在設計時都考慮到備援。想想網路恢復能力範圍、TCP 封包逾時以及 DynamoDB 本身的分散式架構。預設 SDK 行為旨在為大部分應用程式找到適當的平衡點。如果最佳延遲是您的最高優先順序，則應考慮調整 SDK 的預設請求逾時以及重試設定，以密切追蹤用戶端所測量到成功請求的典型延遲。如果一個請求花費的時間明顯比正常時間還要久，最終成功的機率會降低 - 如果能快速檢錯並發出新請求，那麼新請求可能會採取不同的路徑並且快速成功。請記住，在這些設定中過於積極可能會帶來不利影響。您可以在針對延遲感知的 Amazon DynamoDB 應用程式調整 AWS Java SDK HTTP 請求設定中找到此主題的實用討論。

• 減少用戶端與 DynamoDB 端點之間的距離：如果您的使用者遍布全球，請考慮使用 全域資料表：DynamoDB 的多區域複寫。使用全域資料表，您可以指定希望資料表可用的 AWS 區域。從本機全域資料表複本讀取資料，可大幅減少使用者的延遲。此外，請考慮使用 DynamoDB 閘道端點，將用戶端流量保留在 VPC 中。

• 使用快取：如果您的流量需要大量讀取，請考慮使用快取服務，例如 使用 DynamoDB Accelerator (DAX) 的記憶體內加速。DAX 是適用於 DynamoDB 的全受管、高可用性記憶體快取，即使每秒數百萬個請求也能將時間從毫秒縮短到微秒，提供高達 10 倍的效能改進。

• 重複使用連線：DynamoDB 請求是透過預設為 HTTPS 的已驗證工作階段發出。啟動連線需要時間，因此第一個請求的延遲時間會高於一般請求。經由已啟動連線的請求，可以提供 DynamoDB 一致的低延遲。因此，如果沒有發出其他請求，您可能希望每 30 秒發出一次「保持連線」GetItem 請求，以避免建立新連線的延遲。

• 使用最終一致讀取：如果您的應用程式不需要高度一致性讀取，請考慮使用預設的最終一致讀取。最終一致讀取的成本較低，也不太可能發生暫時性延遲增加。如需更多詳細資訊，請參閱 讀取一致性。