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

如果您的工作負載似乎發生高延遲，您可以分析 CloudWatch SuccessfulRequestLatency 指標，並透過百分位數指標 (p50) 檢查平均延遲和中位延遲，以查看是否與 DynamoDB 相關。報告的一些變化SuccessfulRequestLatency是正常的，偶爾會出現峰值 （特別是在Maximum統計資料和高百分位數中） 不應引起關注。不過，如果統計資料或 p50 Average （中位數） 顯示急劇增加並持續，您應該檢查 AWS 服務運作狀態儀表板和您的個人運作狀態儀表板，以取得詳細資訊。有些可能的原因包括資料表中的項目大小 (1 KB 項目和 400 KB 項目的延遲會有所不同） 或查詢的大小 (10 個項目與 100 個項目）。

百分位數指標 (p99、p90 等） 可協助您進一步了解延遲分佈。例如：

• p50 （中位數） 顯示工作負載的一般延遲。

• p90 顯示 90% 的請求比此值更快。

• p99 有助於識別影響 1% 請求的最壞情況延遲。

具有正常 p50 值的高 p99 值可能表示零星問題影響一小部分的請求，而持續提高 p50 值可能表示效能降低。

注意

若要分析自訂百分位數值 （例如 p99.9)，您可以在 CloudWatch 指標統計資料欄位中輸入所需的百分位數 （例如 p99.9)。這可讓您評估超出下拉式清單中所列預設百分位數的延遲分佈。

延遲指標有一些變化，特別是在較高的百分位數中，預期會發生，並且可見於 DynamoDB 驅動的背景操作，這些操作有助於為存放在 DynamoDB 資料表中的資料或暫時性基礎設施問題維持高可用性和耐用性。

如有必要，請考慮使用 開啟支援案例 AWS 支援，並根據 Runbook 繼續評估應用程式的任何可用備用選項 （例如，如果您有多區域架構，則疏散區域）。您應該記錄慢速請求IDs，以便在您開啟支援案例 AWS 支援 時將這些 IDs 提供給 。

SuccessfulRequestLatency 指標只會測量 DynamoDB 服務內部的延遲，不包含用戶端活動和網路觸發時間。若要進一步了解從用戶端到 DynamoDB 服務之呼叫的整體延遲，您可以在 AWS SDK 中啟用延遲指標記錄。

注意

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

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

• 重複使用連線：根據預設，DynamoDB 請求會透過通過 HTTPS 驗證的工作階段提出。啟動連線需要多次往返，且需要一些時間，因此第一個請求的延遲高於下列重複使用連線的請求。經由已啟動連線的請求，可以提供 DynamoDB 一致的低延遲。為了避免建立新連線的延遲額外負荷，如果沒有發出其他GetItem請求，建議您每 30 秒傳送一次請求，以實作「保持連線」機制。

• 使用最終一致讀取：如果您的應用程式不需要高度一致性讀取，請考慮使用預設的最終一致讀取。最終一致性讀取的成本較低，並且可能來自多個可用區域，允許選擇與請求者共置的可用區域，以減少延遲。如需詳細資訊，請參閱DynamoDB 讀取一致性。

• 實作請求對沖：對於極低的 p99 延遲需求，請考慮實作請求對沖。使用請求對沖時，如果初始請求的回應速度不夠快，請傳送第二個對等請求，並讓它們競爭，則第一個回應會獲勝。這可改善尾部延遲，而成本為一些額外的請求。您可以決定在傳送第二個請求之前要等待多久。對沖更容易讀取。對於寫入，請使用以時間戳記為基礎的排序，以確保在第一次嘗試時將對沖請求視為發生，以防止out-of-order更新。此方法已在 Amazon DynamoDB 中針對寫入對沖的時間戳記寫入中討論。

• 調整請求逾時和重試行為：從用戶端到 DynamoDB 的路徑會周遊許多元件，每個元件都以備援為考量。請考慮下列層面：

  • 網路彈性

  • TCP 封包逾時

  • DynamoDB 的分散式架構

  預設 SDK 行為已針對大多數應用程式最佳化。不過，您可以實作快速失敗的策略並調整逾時設定。花費比正常時間更長的請求最終不太可能成功。透過快速失敗並重試，您可能會透過不同的路徑快速成功。這類似於請求對沖，但會結束第一個請求，而不是允許它繼續。

  避免設定逾時值過低。超低的逾時可能會導致用戶端引發的可用性問題。例如，50 毫秒通訊端逾時可能會在網路延遲尖峰期間造成連線錯誤，例如在單一流量流量接近 Amazon EC2 執行個體頻寬限制時。仔細權衡降低逾時對應用程式可用性潛在風險的效益，並偏好對沖至短逾時。

  如需本主題的實用討論，請參閱調整延遲感知 Amazon DynamoDB 應用程式的 AWS Java SDK HTTP 請求設定。

• 減少用戶端與 DynamoDB 端點之間的距離：如果您的使用者遍布全球，請考慮使用 全域資料表 - 多主動、多區域複寫。使用全域資料表，您可以將資料表複寫到您希望資料表可用的指定 AWS 區域。您可以將資料副本放在更接近最終使用者的位置，以減少讀取和寫入操作期間的網路延遲。如需有關有效使用 DynamoDB 全域資料表的詳細資訊，請參閱 AWS 規範指引中的使用 Amazon DynamoDB 全域資料表。

• 使用快取：如果您的流量讀取量很大，請考慮使用下列其中一個快取服務：

  • DynamoDB Accelerator (DAX)：DynamoDB 的全受管、高可用性、記憶體內快取，可提供高達 10 倍的效能改善，從毫秒到微秒，甚至每秒數百萬個請求。如需 DAX 的詳細資訊，請參閱使用 DynamoDB Accelerator (DAX) 的記憶體內加速：

  • Amazon ElastiCache：完全受管的記憶體內快取服務，可與 DynamoDB 整合，以使用快取並行模式改善讀取效能。如需詳細資訊，請參閱 AWS 方案指引中的使用讀取快取整合 Amazon DynamoDB 和 Amazon ElastiCache。