使用Lambd的运动控制潜伏期

Question

我们正在构建一个（主要是）无服务器的体系结构，它以Lambda正在消耗的Kinesis流为中心，并且运行到我们不理解并可能阻塞我们的延迟行为。在

我们在极低的容量下遇到了高延迟，因此我们设置了一个测试用例来测量它：我们的lambda做了一些事情，记录并将一条消息发送回同一个Kinesis流以触发下一次调用。这个测试记录了100-200ms的计费时间，但是根据cloudwatch，调用间隔为2-4s。在

我的阅读建议lambda应该在函数完成后200ms进行轮询，所以这看起来非常慢。我发现2014年的一些旧帖子讨论了类似的行为，但似乎在2015年3月被修复了。这是预期的吗？如果没有，有没有什么陷阱可以导致在运行时间很快的情况下进行缓慢的调用？在

注意事项： 我们正在寻找<；1s的总体延迟，因此最佳<；500ms由Kinesis贡献。 我们为lambda使用python库，因此没有context.succeed()或{}方法，如果这些方法可能相关的话。 我们已经体验过配置更大的内存、更低的超时和不同的批处理大小而没有任何效果。在