从 lambda 到 s3 的上传时间缓慢的原因

Question

我们在 ec2 上有一个服务，我们需要将 许多 个文件上传到 s3 存储桶，但请求数小于 s3 上配置的最大数量。当我们使用 ec2 实例上传时，它在将近 200 毫秒内上传每个文件。具有相同内容长度的相同文件在 AWS lambda 上花费更多时间。时间增加有什么特别的原因吗？ 我发现某些文件的时间有所增加，而其他文件则没有。对于相同的内容长度，有些文件需要大约 3-4 秒。 ec2 实例是 c5.large，我为 AWS lambda 函数配置了 10 GB。 存储桶与 lambda 函数位于同一区域。此时间是通过测量要上传数据之前和上传完成之后的时间从日志中获得的。这些文件是通过处理应用程序内部数据库调用的数据生成的。

Answer 1

很遗憾，冷启动时间没有好办法。

您可以使用预配置并发，但这意味着要为永远在线的 Lambda 付费，而 Java 的“仅在需要时加载类”设计意味着您需要编写显式代码以在第一次执行环境之前“预热”执行环境请求进来了。

可能有用的一件事是限制并发 Lambda 的数量。如果您向 Lambda 发起请求，请it will spin up as many execution environments as it can 处理这些请求。因此，您将为每个新的调用环境支付冷启动时间。

但是，如果您使用 reserved concurrency，则指定最大并发实例数。您将为每个实例支付冷启动罚款，但随后 Lambda 将尝试重用实例而不是启动新实例。但是，如果没有任何请求，它将关闭环境（因此您无需为它们付费，但会在下一次爆发时产生冷启动时间）。

您还可以使用 SQS 队列来平滑突发：将每个文件添加到队列中，配置具有保留并发的并发 Lambda 的数量，并让它们慢慢地通过队列。

最后，如果您所做的只是上传文件，那么值得考虑使用不同的实现语言，例如 Python。