我正在使用具有Lambda函数的API网关创建应用程序的后端，而请求的响应时间却遇到问题。
众所周知，Lambda函数具有臭名昭著的“冷启动”，好吧，我们已经接受了。但是我现在遇到的问题似乎是一个新的冷启动，这次是API Gateway。待机时间不是ms，而是seconds（约12-15秒）。哦，天哪，这是个大问题...
此响应延迟在第一个请求上发生12-15秒，并且在一些不活动后（大约1小时）。
我的问题是：造成这种延迟的原因是什么？如何解决？
更多信息：
我的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 :
答案 0 :(得分：1)
API Gateway没有冷启动，AFAIK。
一小时不活动后的延迟仍然是Lambda的冷启动。
为防止这种情况，您可以创建一个CloudWatch Scheduled Event来持续调用Lambda（例如，每5分钟一次），以避免不活动并减少冷启动。
一旦投入生产并且流量已经很高，那么闲置就更少了。
答案 1 :(得分：1)
这里要记住的事情很少，当运行Lambda的容器被有效地“退役”时，就会发生冷启动-这意味着AWS基础设施已将其从“就绪”状态删除为“没有人真正使用此功能，让我们搁置”。
VPC外部的Lambda的冷启动时间可能长达6秒，在VPC内，每个容器最多可以看到12秒的冷启动时间，因此，如果您有一个Lambda实例处于温暖状态，如果有两个人命中该端点同时第二个人将开始冷门。
因此，正如Dashmug先生所建议的那样，有一个预定的函数来预热lambda是简单的方法，现在要记住的一件事是，如果您期望每秒需要数百个请求，则该函数可能会预热1个容器保持X个容器的温度。
有关如何简化此操作的示例，您可以查看this-它是无服务器框架的插件，可以完全满足您的需求。
本质上，您需要一个将使每个端点的并发请求数达到X的功能-请注意，尽管您可以像这样以每月不到30美元的价格保持像样的微服务预热，但这会产生一定的成本。
我个人认为过冷启动是过分的-确保客户偶尔会遇到反应缓慢的问题，但是如果您的API的流量相对稳定，那么我真的不会担心您的客户会保持适当数量的Lambda温暖，如果它很容易发生的话达到峰值，则有必要对其进行加热。
考虑一下，我对API的平均请求时间为<400毫秒-因此，我需要每秒2个请求，每分钟120个，每小时7200个，甚至开始一直需要两个容器-如果您有诸如人们可以登录的应用程序之类的东西，然后调用主屏幕的api端点，您可以做一些简单的事情，例如Login-> SNS向下一端点触发热身事件。
基本上，如果您知道消费者将要调用api的流程，则可以根据上一个被调用的对象主动预热端点。