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 把每一次主动退出都记录为运行时失败。

这不是我们想在生产环境中依赖的做法。

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

这让我们能够控制调度和资源分配。我们可以在多个应用之间共享容量，而不必为每个空闲环境向 AWS 付费，并且在需求需要时扩展到自建基础设施之外。

我们的第一台自运营计算主机于 11 月 2 日在 US East 上线，为包括 Easel 自家网站在内的应用提供服务。

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

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

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

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

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

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

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

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

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

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

但这也给了我们优化整个执行路径的自由，而不是围着另一个平台的限制打转。

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

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

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