WASM 与容器冷启动：运行时所说的

该英文文本是根据法文原文自动生成的，尚未经过审查。

该页面已自动翻译。英文版具有权威性。

This article brings together what identifiable third-party sources publish about WebAssembly's cold start compared to containers: a paper presented at USENIX NSDI, official documentation from Fastly, WasmEdge and Wasmer, and an academic research project on serverless isolation. No Aurabase figures are included. Our edge functions run well on Wasmtime, verified in the repository, but no cold start benchmark specific to our infrastructure has been published to date, a distinction detailed below. For the general benchmarking method applied elsewhere on this blog, see our pillar article onbenchmarking methodology.

要点

AWS Firecracker 论文（Agache 等人，USENIX NSDI 2020）记录了 microVM 启动时间低于 125 毫秒，内存开销低于 5 MiB：本文中最精确量化的参考。
2019 年，快速记录了其 AOT Lucet 运行时的 WASM 实例化时间低于毫秒（其优化随后合并到 Wasmtime）。这是供应商发布的数字，从未在此处参考的来源中独立复制。
WasmEdge 是 CNCF 治理下的一个项目，在其官方文档中声称其启动和内存占用量明显低于同等的 Docker 容器，但本文中没有引用独立的对策。
Wasmtime、Wasmer 和 WasmEdge 不以相同的方式编译（您选择的 Cranelift、Singlepass/Cranelift/LLVM、自己的 AOT 编译器）：这种后端选择解释了它们发布的数据之间的很大一部分差距，而不仅仅是运行时本身。
Aurabase 在生产中使用 Wasmtime 来实现其边缘功能，并在 aura-functions/Cargo.toml中进行了验证，但迄今为止尚未发布在其自己的基础设施上测量的任何冷启动数据。

方法来源注释

下面引用的第三方来源可通过其标题、作者或出版商以及出版日期来识别。这项研究依赖于 WebAssembly 和无服务器生态系统中公认且广泛记录的出版物，而不是在撰写本文时对其页面的实时查询。在无法足够确定地确认精确数字的情况下，本文使用数量级而不是精确值，并明确说明这一点。

取景

为什么 WASM 冷启动在无服务器争论中占据如此大的篇幅

冷启动是指当执行环境必须在应用程序代码运行之前初始化时，请求所付出的额外延迟。在经典的边缘或无服务器功能上，这远非边缘案例：在两个流量峰值之间降至零实例的平台，或者将其执行分布在数十个地理上分散的边缘节点上的平台，会永久支付此成本，而不仅仅是在第一次部署时。

自从 Docker 联合创始人 Solomon Hykes 于 2019 年 3 月在 Twitter 上发表一句话以来，这个主题在 WASM 生态系统中几乎具有象征意义：“如果 WASM+WASI 存在于 2008 年，我们就不需要创建 Docker。这就是它的重要性。服务器上的 WebAssembly 是计算的未来。”这是公认从业者的观点，而不是衡量标准。它解释了这个主题为何令人着迷，它不取代来源图。

Aurabase 为其边缘函数提供了两种路径：Studio 编辑器，它在 Deno 运行时中运行代码，如我们的 Supabase 迁移指南中所述，以及 aura functions deployCLI，其目标是为用 Rust 编写并在 Wasmtime 上编译为 WASM 的函数提供单独的路径。本文阐明的正是第二条路径，但没有给出尚不存在的冷启动图。

建筑

为什么 WASM 模块在结构上启动速度比容器快

从绝对意义上讲，差异并非来自更快的运行时：而是来自查询和应用程序代码之间更短的步骤堆栈。

启动容器会调动主机内核：创建一个新进程，设置隔离它的 cgroup 和命名空间，安装镜像各层，然后在内部启动应用程序运行时（例如，Node.js 及其 V8 引擎本身就有初始化成本）。每个步骤都会添加系统调用，对于本地从未见过的图像，还会在开始之前进行网络下载。

WebAssembly 模块在虚拟机语言级别隔离，而不是在操作系统级别隔离。实例化模块意味着分配其线性内存，绑定其导入，然后跳转到其入口点，所有这些都在主机运行时已启动的进程内进行。没有新进程，没有图像层，没有安装默认文件系统。

编译模式的选择增加了一个额外的变量。当模块加载时，Wasmtime 通过其 Cranelift 后端编译为 JIT，或者可以使用 wasmtime compile提前预编译它，这会生成一个已转换为本机机器代码的 .cwasm 文件。早期编译（AOT）从请求的关键路径中删除了编译步骤：这正是对冷启动敏感的边缘架构必须激活的杠杆。

Cargo.tomltoml

# Aurabase 存储库的实际摘录
# WASM 运行时
wasmtime = { version = "43", features = ["async", "cranelift"] }

这是生产依赖项，而不是开发依赖项：它确认 Wasmtime 实际上在 Aurabase 边缘功能的 CLI 路径上运行。然而，它没有确认任何延迟数据，只要没有发布过时的基准测试，该数据就仍然正确。

公布的数字

容器和 microVM：最精确的量化参考

在这个领域，最有力的来源是行业研究论文，而不是营销博客文章。 Firecracker 是 AWS 开发的轻量级 microVM 技术，主要用于 Lambda 和 Fargate，由 Agache 等人在 USENIX NSDI 2020 会议上展示。在文章“Firecracker：无服务器应用程序的轻量级虚拟化”中。

本文记录了每个 microVM 的启动时间小于 125 毫秒，内存开销小于 5 MiB，并且能够在同一台物理机上运行数千个 microVM。这是一个过时的数字（2020 年），来自同行评审的学术出版物，自那时起在有关无服务器隔离的文献中被广泛引用。

标准 Docker 容器通常会更高：从几百毫秒到几秒，具体取决于映像的大小、下载的需要以及嵌入式应用程序运行时的启动时间。与 Firecracker 不同，这里没有普遍引用的单一数字：结果过于依赖于针对单一值进行测试的图像来达成共识。

公布的数字

WebAssembly：什么Fastly、WasmEdge和学术研究文档

三个来源，三种不同的状态：历史供应商、基金会治理下的项目和研究论文。

Fastly 于 2019 年在 Lucet 上推出了 Compute@Edge，这是其自己的预编译 WASM 编译器和运行时。在这次发布中，该公司记录了 WASM 实例化时间低于毫秒，这个数量级对业界的 WASM 冷启动讨论产生了持久影响。 2021 年，Fastly 停止了 Lucet 的自主开发，并将精力转向 Wasmtime，其 Cranelift 编译后端继承了部分这些优化：这也是 Wasmtime 至今仍然是此类负载的参考的原因之一。

WasmEdge 是 CNCF 治理下的 WASM 运行时（最初是 SSVM，由 Second State 支持），在其官方文档中声称其启动和内存占用量明显低于同等的 Docker 容器，并且明确定位于边缘和 IoT 负载。这是项目发布者自己发布的数据，应理解为：产品声明，而不是独立审计。

在学术研究方面，Faasm（Shillaker & Pietzuch，USENIX ATC 2020，也可在预发表中）构建了一个依赖于 WebAssembly 隔离（通过 WAVM，而不是 Wasmtime）的有状态无服务器平台，正是因为它允许以比容器或 VM 隔离低得多的成本实例化函数。这篇论文并不是专门针对 Wasmtime，但它为上一节中的结构性论证提供了独立的学术验证。

运行时

Wasmtime vs Wasmer vs WasmEdge：为什么公布的数字不一致

仅通过名称比较这三个运行时隐藏了真正的变量：所选择的编译后端，它从根本上改变了启动速度和执行性能之间的平衡。

瓦斯姆时代	Cranelift（默认为 JIT）+ 通过 wasmtime 编译的 AOT	字节码联盟·开放治理，由 Fastly、Shopify、Aurabase 使用
瓦斯默	您选择的 Singlepass、Cranelift 或 LLVM	Singlepass 最大限度地减少编译时间； LLVM 最大化执行性能
瓦斯姆边缘	项目特定的 AOT 编译器	CNCF·定位边缘/物联网和云原生

Singlepass 是 Wasmer 最快的编译后端，其存在正是因为其团队将冷启动视为稳态执行性能的一个独特轴：与在 LLVM 中编译的相同模块相比，在 Singlepass 中编译的模块启动速度更快，但在峰值负载期间运行速度更慢。这是一个公认的妥协，而不是一个隐藏的缺陷。

运行时供应商发布的数据并非独立审计

Wasmer 发布了自己与 Wasmtime 的性能比较，这种做法在 WASM 社区中引发了关于所使用的方法和测试场景的可比性的争论。这并不是对恶意的指控：这是一个结构性的提醒。运行时编辑器对发布其获胜的场景有着既得利益，这使得在决定单个数字的架构选择之前进行独立验证变得更加有用。

总结

比较表：每个源记录了什么，没有记录什么

<125毫秒

启动鞭炮

Agache 等人，NSDI 2020

WASM 运行时间比较

Wasmtime、Wasmer、WasmEdge

基准冷启动 AURABASE

Wasmtime 在生产中进行检查，未发布测量结果

鞭炮 (AWS)	< 125 毫秒启动时间，< 5 MiB 开销经过同行评审的研究论文	Agache 等人，USENIX NSDI 2020
Lucet → Wasmtime（快速）	毫秒下的实例化（2019）供应商图，此处不再转载	快速推出 Compute@Edge
瓦斯姆边缘	与 DockerPublisher 产品声称相比，启动和内存占用更小	WasmEdge 官方文档 (CNCF)
法斯姆（搜索）	WASM 隔离的实例化成本明显低于容器使用 WAVM，而不是 Wasmtime	Shillaker & Pietzuch，USENIX ATC 2020
标准 Docker 容器	数百毫秒到几秒没有单一的共识数	广泛记录的行为

这五行并不是一个单一的分类：它们来自不同的方法、日期和运行时生成。为了对此类 WASM 基准的可靠性进行更深入的方法论批判，我们关于 WebAssembly 基准的限制的文章比目前的比较更进一步，该比较仍然关注每个来源具体主张的内容。

实际意义

对于边缘架构的选择来说，这种差距真正会带来什么变化

WASM 的冷启动优势主要依赖于对第一个请求的延迟最敏感的负载，而不是平等地依赖于所有负载。

它特别影响非常不规则的边缘流量（爆发后沉默），每个请求的隔离而不是多个请求之间共享的每个容器，以及实际上在两个峰值之间下降到零实例而不是永久保持热池的基础设施。在稳定且可预测的负载下，实例无论如何都保持热状态，冷启动间隙在结构上不太重要。

WebAssembly 还保持着与冷启动不同的约束：对文件系统或网络的访问通过 WASI，该接口仍在根据运行时及其版本而演变，并且编译为快速启动的模块（例如 Wasmer 端的 Singlepass）一旦在重负载下建立，不一定是最快的。冷启动和峰值执行性能仍然是两个不同的轴，很少在同一编译配置文件上同时实现最佳性能。

为了根据这个标准评估边缘架构的选择，需要向任何供应商询问三个具体问题，Aurabase 包括：使用哪个确切的运行时、哪个编译后端（JIT 或 AOT）以及高级冷启动数据是否由独立第三方测量或仅由运行时发布者本身测量。

常见问题解答

常见问题解答

WebAssembly 冷启动仍然比 Docker 容器更快吗？+

从数量级来看，本文引用的来源是这样的：WASM 模块的实例化需要几微秒到几毫秒，而经典容器的实例化需要数百毫秒到几秒。但这些数字都不是来自这两个技术系列在不同日期和不同版本上通用的测量协议。被视为广泛记录的趋势，而不是对任何负载有效的数值保证。

为什么 Wasmtime、Wasmer 和 WasmEdge 宣布不同的起始数字？+

因为它们的编译方式不同。 Wasmtime 使用 Cranelift 作为默认后端，并通过 wasmtime 编译提供早期构建（AOT）。 Wasmer 允许您在 Singlepass（最快编译）、Cranelift 或 LLVM（最高运行时性能，较慢编译）之间进行选择。 WasmEdge 包含自己的 AOT 编译器，专为边缘和物联网而设计。后端的选择很大程度上解释了每个项目发布的数据之间的差距。

AOT（提前）编译对于冷启动实际上会改变什么？+

AOT 编译从请求的关键路径中删除了编译步骤：WASM 模块在调用之前已经转换为机器代码，剩下的就是加载和实例化它。这就是 wasmtime 在 Wasmtime 端和 WasmEdge 自己的编译器上进行编译的原理。 JIT 编译会为每个新的冷实例支付部分成本，除非运行时缓存结果。

Aurabase 是否发布了其边缘 WASM 功能的冷启动基准？+

不会。Aurabase 在生产中使用 Wasmtime 作为其边缘功能的 CLI 路径，在 aura-functions/Cargo.toml（版本 43，异步和 Cranelift 功能）中验证了依赖性，但迄今为止尚未发布在此基础设施上测量的冷启动数据。我们对任何未来绩效数据的方法承诺均在我们的基准方法文章中详细说明。

WASM 运行时的冷启动和无服务器 Postgres 数据库的冷启动有什么区别？+

这是堆栈的两个不同层。这里描述的冷启动涉及代码执行环境，即 WASM 运行时本身。当恢复挂起的实例或建立新的加密连接时，无服务器 Postgres 数据库会增加自己的启动延迟，该延迟与连接池相关。我们关于无服务器 Postgres 冷启动的文章专门讨论了第二层。

我们可以相信 WASM 运行时编辑者自己发布的冷启动基准吗？+

谨慎行事。运行时发布者发布的图表描述了其自己的测试条件，很少独立复制，并且 WASM 社区已经在运行时之间的性能比较方法上遇到了公众分歧。我们专门讨论 WebAssembly 基准测试局限性的文章更深入地详细介绍了这些方法问题。

对于同样问题的数据库层，请参阅我们关于无服务器 Postgres 冷启动的文章。