用戶端傳送請求至 Amazon API Gateway 中的邊緣優化 API 時,我注意到延遲變高。如何找到延遲來源,進行疑難排解?
若要尋找邊緣優化的 API 端點的延遲來源,請判斷連線路徑下列每個部分所需的時間長短:
**重要事項:**這些連線路徑步驟僅適用於邊緣優化的 API 端點,而不適用於區域 API 端點。邊緣優化的 API 透過 Amazon CloudFront 發佈版本存取。區域 API 端點不是透過 CloudFront 存取。
在連線路徑中花費時間最長的部分即是延遲來源。
注意: 您可以使用 AWS X-Ray 在使用者請求行經 Amazon API Gateway REST API 前往基礎服務時,追蹤和分析這些請求。在提供 X-Ray 的 AWS 區域中,API Gateway 支援該區域內所有 API Gateway REST API 端點類型的 X-Ray 追蹤。若要查看提供 X-Ray 的所有區域,請參閱 AWS 區域表格。
若要判斷步驟 1-6 在您 API 連線路徑程序中的持續時間,請在 GitHub 上執行 curl_for_latency Bash 指令碼。
重要事項:請確認您有取代掉 URL、HTTP 方法和參數值,以符合您 API 的資訊。
指令碼會傳回您的 API 完成下列連線路徑步驟所需的一段時間:
識別造成延遲的事件後,請參閱我如何疑難排解並減少 CloudFront 逐漸升高的延遲?
在 CloudWatch 主控台中檢視您 API 的延遲指標。然後,進行1 分鐘間隔和最大值的延遲指標圖設定,以查看一段一分鐘時間內最長的處理時間。
如需說明,請參閱檢視 CloudWatch 主控台中的 API Gateway 指標。
在 CloudWatch 主控台中檢視 IntegrationLatency 指標。然後,進行1 分鐘間隔和最大值的 IntegrationLatency 圖設定,以查看一段一分鐘時間內最長的處理時間。
-或-
如果您的 API 已啟用 CloudWatch 日誌記錄,請檢閱類似下列內容的明細日誌:
Received response. Integration latency: 325 ms
您也可以新增包含存取日誌記錄 (用於額外延遲疑難排解) 的 $context 變數。
如須說明,請參閱如何開啟 CloudWatch 日誌來對 API Gateway REST API 或 WebSocket API 進行疑難排解?
如果您將 AWS Lambda 與 API Gateway 搭配使用,而且看到高 IntegrationLatency 指標,請檢閱 Lambda 函數的 CloudWatch 日誌。如果與 Lambda 函數整合的 API 端點傳送回應給用戶端所需的時間太長,則必須解決高延遲問題。Lambda 函數的冷啟動不會記錄在函數的持續時間指標中,因此 API 的整合延遲可能會超過函數的持續時間。若要檢視具有冷啟動的函數的持續時間,請使用 AWS X-Ray。
如需詳細資訊,請參閱如何疑難排解與 Lambda 整合的 API Gateway 請求中的高延遲?
取 API 的請求與回應的總時間 (「time_total」),然後減去以下時間:
最終可得到 API Gateway 回應 CloudFront 邊緣節點和 CloudFront 回應用戶端需要耗費的時間。
使用 HTTP API 的指標
Amazon API Gateway 維度和指標
使用 CloudWatch 指標監控 WebSocket API 執行
如何使用 Amazon API Gateway 日誌進行疑難排解?