API Gateway + Lambda 極慢的響應時間

Question

我正在使用帶有 Lambda 函數的 API 網關創建我的應用程序的后端，但我遇到了請求響應時間的問題。

眾所周知，Lambda 函數具有臭名昭著的“冷啟動”，好吧，我們已經接受了。 但我遇到的問題似乎是一個新的冷啟動，這次是 API 網關。 待機時間不是幾ms ，而是seconds （大約 12-15 秒）。 天哪，這是個大問題……

此響應延遲在第一個請求和一些不活動（大約 1 小時）后發生 12-15 秒。

我的問題是：什么可能導致這種延遲以及如何解決它？

更多信息：
我的 lambda 函數配置為在 VPC 上運行。

來自 API 網關的 CloudWatch 日志：

(01) Extended Request Id: XXXXX=
(02) Verifying Usage Plan for request: XXXXX. API Key: API Stage: XXXXX
(03) API Key authorized because method 'GET /XXXXX' does not require API Key. Request will not contribute to throttle or quota limits
(04) Usage Plan check succeeded for API Key and API Stage XXXXX/v1
(05) Starting execution for request:
(06) HTTP Method: GET, Resource Path:
(07) Method request path:
(08) Method request query string:
(09) Method request headers:
(10) Method request body before transformations:
(11) Endpoint request URI:
(12) Endpoint request headers:
(13) Endpoint request body after transformations:
(14) Sending request to XXXXX
(15) Received response. Integration latency: 14497 ms
(16) Endpoint response body before transformations:
(17) Endpoint response headers:
(18) Method response body after transformations:
(19) Method response headers:
(20) Successfully completed execution
(21) Method completed with status: 200
(22) AWS Integration Endpoint RequestId :
(23) X-ray Tracing ID : 

Answer 1

2019 年 14 月 12 日更新：

AWS 引入了配置的 Lambda： https ://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/

這里要記住的事情很少，當運行 Lambda 的容器有效地“退役”時，就會發生冷啟動——這意味着 AWS 基礎設施已將其從“准備就緒”狀態降至“沒有人真正使用它，讓我們擱置它” .

Lambda 在 VPC 外部的冷啟動時間最多為 6 秒，在 VPC 內部，您可以查看每個容器最多 12 秒的任何地方，所以僅僅因為您有一個 Lambda 實例熱，如果兩個人同時訪問該端點時間然后第二個人將冷啟動。

因此，正如 Dashmug 先生所建議的那樣，有一個預定的函數來預熱你的 lambda 是最簡單的方法，現在要記住的一件事是你的函數可能會預熱 1 個容器，如果你期望每秒有數百個請求，你需要保持 X溫暖的容器數量。

有關如何簡化此操作的示例，您可以查看此- 它是無服務器框架的插件，可以完全滿足您的需求。

從本質上講，您需要一個函數來為每個端點發出 X 數量的並發請求——請注意這是有成本的，盡管您可以像這樣以每月不到 30 美元的價格保持相當不錯的微服務預熱。

就個人而言，我認為冷啟動被誇大了——當然客戶偶爾會遭受緩慢的響應，但如果你的 API 流量相對穩定，那么我真的不擔心你的客戶會保持正確數量的 Lambda 熱，如果它容易出現峰值的話值得熱身。

想一想，我處理的 API 的平均請求時間小於 400 毫秒 - 所以我需要每秒 2 個請求，每分鍾 120 個，每小時 7200 個，甚至開始一直需要兩個容器 - 如果你有類似應用程序的東西在人們登錄的地方，然后調用主屏幕的 api 端點，您可以做一些簡單的事情，例如登錄-> SNS 將預熱事件觸發到下一個端點。

基本上，如果您知道您的消費者將調用 api 的流程，您可以根據前一個調用主動預熱端點。

Answer 2

API 網關沒有冷啟動，AFAIK。

一小時不活動后的延遲仍然是 Lambda 的冷啟動。

為防止出現這種情況，您可以創建一個 CloudWatch 計划事件來持續調用您的 Lambda（例如，每 5 分鍾一次）以避免不活動並減少冷啟動。

一旦您投入生產並且您的流量已經很高，因此不活動的情況就會減少，這就不是什么問題了。