amazon-web-services - API Gateway + Lambda 响应时间极慢

Question

我正在使用带有 Lambda 函数的 API 网关创建应用程序的后端，但我遇到了请求响应时间问题。

众所周知，Lambda 函数有臭名昭著的“冷启动”，好吧，我们已经接受了。但我遇到的问题似乎是一个新的冷启动，这次是通过 API Gateway。而且不是少数ms待机时间为seconds (大约 12-15 秒)。天哪，这是个大问题……

这种响应延迟在第一次请求时会出现 12-15 秒，并且会在一些不活动之后(大约 1 小时)发生。

我的问题是:什么可能导致这种延迟以及如何解决它？

更多信息:
我的 lambda 函数配置为在 VPC 上运行。

来自 API Gateway 的 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容器的数量温暖。

有关如何简化此操作的示例，您可以查看 this - 它是无服务器框架的插件，完全符合您的要求。

本质上，您需要一个功能，该功能将在每个端点发出 X 个并发请求 - 请注意，尽管您可以像这样以每月不到 30 美元的价格保持相当不错的微服务预热，但这是有成本的。

就我个人而言，我认为冷启动是多余的——当然客户有时会遭受缓慢的响应，但如果你的 API 有相对稳定的流量，那么我真的不担心你的客户会保持正确数量的 Lambda 温暖，如果它容易出现峰值那么值得热身。

想一想，我处理的 API 的平均请求时间是 < 400 毫秒 - 所以我需要每秒 2 个请求，每分钟 120 个，每小时 7200 个甚至开始需要两个容器 - 如果你有类似应用程序的东西人们登录的地方，然后调用主屏幕的 api 端点，您可以做一些简单的事情，例如 Login->SNS 将预热事件触发到下一个端点。

基本上，如果您知道您的消费者将调用 api 的流程，您可以根据前一个调用的端点主动预热端点。