AWS Lambda Web Functions 在最后一次请求后仍继续计费内存约 7 分钟

AWS Lambda Web Functions 在最后一次请求后仍持续计费内存约 7 分钟

为什么我们选择自建计算，而不是 AWS Lambda Web Functions

Lambda Web Functions 在最后一次请求后 5–7 分钟内持续对内存计费，因此我们构建了自己的计算。在同一个 Next.js 应用上，它响应热请求快 1.5–

冷启动也呈现出类似情况。

在让两个应用都空闲 12 分钟后，我们在每个平台上触发了全新的执行环境。

在两次试验中，Easel 开始处理请求的速度都约快 3.5 倍。

在较短的空闲期之后，我们还看到了一个有趣的差异。在一次五分钟的间隔之后，Web Functions 已经终止了其环境，需要 908ms 才能响应。Easel 恢复了其暂停的环境，仅用 14ms 就响应了。

这些是来自单一区域和一个小型应用的早期结果，并非全面的性能研究。冷启动比较只有两个配对样本，我们尚未对持续吞吐量进行基准测试。

尽管如此，看到我们自己的基础设施在这些初始工作负载上表现优于 AWS，仍然令人鼓舞。

掌控基础设施

运行我们自己的计算资源伴随着额外责任。我们必须管理容量、处理故障，并确保资源在应用之间高效分配。

但这也给了我们优化整个执行路径的自由，而不是绕开另一个平台的限制来工作。

Web Functions 可能适合具有持续流量的应用，在这类应用中，空闲内存成本不那么重要。对 Easel 而言，运行大量独立应用的经济性将我们引向了不同的方向。

而我们的初步基准测试表明，这一决定不必以牺牲性能为代价。

我们承担更多基础设施复杂性，这样使用 Easel 的开发者就不必承担。

• AWS Lambda Web Functions

• Web Functions 环境生命周期

• Web Functions 扩缩容行为

• AWS Lambda 定价