我们正在构建（主要）服务器较少的架构，该架构以Lambda使用的Kinesis Stream为中心，并且遇到我们不理解并可能阻止我们的延迟行为。
我们在极低的音量下遇到了高延迟，因此我们设置了一个测试用例来测量它：我们的lambda做了一些事情，记录并将消息发回到同一个Kinesis流以触发下一次调用。该测试记录了100-200毫秒的计费时间，但根据Cloud Watch，调用间隔为2-4秒。
我的阅读建议lambda应该在函数完成后200ms进行轮询，所以这似乎很慢。我发现EOY 2014的一些旧帖子讨论了类似的行为，但它似乎在2015年3月修复。这是预期的吗？如果没有，有没有可能导致调用速度慢的问题尽管运行时间很短？
一些说明：
我们正在寻求<1s的整体延迟，因此最佳地＆lt; 1＆gt;由Kinesis贡献的500ms。
我们正在为我们的lambda使用python库，因此没有context.succeed()或context.done()方法，如果那些可能是相关的。
我们经历了更大内存配置，更低超时和不同批量大小的配置，但没有效果。