问提供的并发对Lambda函数的响应时间影响很小。

EN

我相信原因是5的配置并发是不够的，而且您仍然会遇到Lambda函数的冷启动。这意味着如果外部服务正在调用您的API端点(即API网关后面的Lambda函数)，则您的Lambda函数具有5个实例。如果我们假设Lambda函数可以每秒处理2个请求(每次调用500 10 )，那么您可以使用Lambda函数每秒处理10个请求。如果外部服务每秒发出20个请求，AWS Lambda会尝试旋转新实例，因为现有实例正忙于处理请求。这会导致外部服务由于功能的冷启动而经历较高的响应时间。

另外，考虑到Lambda函数的实例不是“永远”存在的，而是在某个点之后被清理干净的。也就是说，如果您在交通模式中经历了许多尖峰，那么这可能意味着在一个高峰之后，实例活了15分钟，然后AWS Lambda关闭它们，只保留5个供应的实例，如果又出现了另一个高峰，您将看到与前面相同的问题。

请注意：，这是对幕后发生的事情的一个非常简单的解释--更好的猜测是基于您的描述。如果您提供一些示例数字(例如init持续时间、执行持续时间、响应时间)，或者提供一些示例代码，说明您在Lambda函数中所做的事情，这将有所帮助。另外:您使用的是哪个运行时？你的交通模式怎么样？

潜在解

• 减少Lambda函数的冷启动时间->对于API网关后面的Lambda函数来说一直是个好主意
• 提供更多的实例->只能达到一定的(软)限制

=====服务流=====

API⮕Lambda函数(提供)

=====查询=====

您希望了解为什么在处理从API到Lambda函数的请求时存在延迟。

===== -CW =====时间戳

021-02-15T11:51:36.621+05:30 2021-02-15T11:51:38.535+05:3 Lambda持续时间: 1331.38 ms记帐时间: 1332 ms内存大小: 256 MB使用的最大内存: 130 MB Init持续时间: 1174.18 ms

=====后续问题=====

虽然请求是通过API到Lambda函数处理的，但是执行env占用了1174.18 ms(1.1s)部分来激活&在剩下的0.3s中执行您的代码，这使得它总共有1.4秒的时间。

问:您使用的处理器类型是什么？API的类型&端点类型？

===== K.C =====

1. 您应该阅读AWS来优化Lambda函数代码.优化静态初始化
2. Lambda不会向您收取初始化代码(例如导入代码)所需的时间，只要它在大约X秒内完成。

=====复制观测=====

没有提供的并发性。

1. API GW执行时间- 286 ms
2. 初始化-195
3. 调用-11
4. 间接费用- 0ms

有准备的并发。

1. API GW执行时间-1.103 GW
2. 初始化-97
3. 调用- 1ms
4. 间接费用- 0ms

我在美国西部2号区域，从离该地区12,575公里处打电话请求。我有一个REST，它被配置为'Regional‘端点类型。Lambda函数运行在基于x86处理器的x86_64 -64位x86体系结构上.

-检查是否优化了Lambda函数代码-为了降低延迟，您可以使用“边缘”优化的Rest API.An边缘端点-优化的API端点对地理分布的客户端是最好的。API请求被路由到最近的CloudFront存在点(POP)。--选择最接近交通发达地区的地区。

-参考资料：

new-provisioned-concurrency-for-lambda-functions provisioned-concurrency.html#optimizing-latency