Easel 称 AWS Lambda Web Functions 末次请求后仍计费内存 5-7 分钟，转而自建计算

Lambda Web Functions 在最后一次请求结束后的 5–7 分钟内仍在计收内存费用，于是我们自建了计算基础设施。在同一个 Next.js 应用上，热请求的响应速度快了 1.5–3 倍，冷启动速度快了约 3.5 倍。

AWS 在 10 月发布 Lambda Web Functions 时，我很兴奋。

在 Easel，我们花了几个月时间搭建基础设施，以便在传统 Lambda 上高效运行 Web 应用。原生 HTTP 服务器、并发请求、活跃 CPU 计费——听起来正是我们一直在寻找的东西。

如果 Web Functions 能按我们期望的方式工作，我们或许可以替换掉相当一部分自建基础设施。

几周后，我们却决定改为运行自己的计算资源。而事实证明，我们自己的基础设施还更快。

最初的实验很有希望。Web Functions 成功处理了 300 个并发请求，没有出现错误，一个新函数在不到九秒内就开始处理请求。

但我们很快遇到了一个对我们不可行的问题。

执行环境在最后一次请求结束后的 5–7 分钟内仍在继续运行，并持续产生内存费用。

Web Functions 只在 CPU 被实际使用时才计费 CPU，但内存费用覆盖执行环境的整个生命周期，即使没有请求在运行也照收不误。

AWS 的文档中写明了这一行为。让我们意外的是这些环境存活的时间之长。

在六个有代表性的环境中，我们观察到空闲时间从 313 秒到 411 秒不等。进程在整个期间保持活跃，而且没有可配置的空闲超时来缩短其生命周期。

对于一个 200ms 的请求，随后是 345 秒的空闲，这意味着按计量内存时间计算，约为请求时长的 1,700 倍。

我们用 CloudWatch 和 AWS Cost Explorer 核对了成本。在整个实验中，按公开列表价格计算，内存约占所计算的计算与请求成本的 88%，尽管我们的应用只用了大约 160–210 MB。

整个实验按列表价格算下来大约两美分。单看这一点并不值得警惕。

但 Easel 需要支撑数千个流量不可预测的应用。有些应用流量持续稳定，另一些可能每天只有几个请求。在这个规模下，让独立计量的环境持续存活所产生的成本就开始变得重要了。

我们甚至尝试过在空闲 10 秒后自行终止环境。这确实将计量的环境时间减少了约 20 倍，但 AWS 把每一次主动退出都记录为运行时失败。

这不是我们想在 production 中依赖的做法。

我们没有采用 Web Functions，而是决定将应用执行迁移到我们自己运营的服务器上，同时保留传统 Lambda 用于应对流量溢出。

这让我们能够控制调度和资源分配。我们可以在多个应用之间共享容量，而不必为每个空闲环境向 AWS 付费；当需求超出自身基础设施能力时，也能进行扩展。

我们的第一台自运营计算主机于 11 月 2 日在美国东部上线，承载的应用包括 Easel 自己的网站。

但接管计算资源又带来了另一个问题：我们的性能与 AWS 相比会如何？

我们将同一个 Next.js 16 应用部署到两个平台，并从弗吉尼亚州阿什伯里的客户端运行了一系列基准测试。

在全部四种工作负载下，我们的主机热请求中位响应时间都快了 1.5–3 倍。

差异并不限于网络或路由开销。运行同样的 20,000 次链式 SHA-256 运算，我们的主机耗时 29.2ms，而 Web Functions 为 43.8ms，约快 1.5 倍。

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

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

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

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

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

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

但这也给了我们优化整个执行路径的自由，而不必围绕另一个平台的限制来做变通。

Web Functions 可能适合流量持续稳定的应用，在这类场景中空闲内存成本的影响较小。对 Easel 而言，运行大量独立应用的经济账把我们引向了另一个方向。

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

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