WebAssembly 冷启动：基准测试显示了什么

冷启动再次成为 WebAssembly 运行时之间商业差异化的轴心，而不仅仅是学术研究的主题。 Wasmer 通过名为 Instaboot 的功能将此作为一个明确的卖点，作为冷启动问题的直接答案。

这种反射完全让人想起我们在 后端基准测试方法的文章中记录的动态：几个竞争供应商在自己的产品页面上显示性能数据，而不总是指定生成它们的协议。没有方法的冷启动数据只不过证明了没有方法的延迟数据。

冷启动不是单一操作：它是不同阶段的总和，两个供应商不一定以相同的名称测量相同的阶段。

仅计算已加载并已编译到内存中的模块的实例化的图在机械上看起来比包含网络加载和编译的图更好。两者本身都不是错误的：当我们比较它们而不指定测量两者中的哪一个时，问题就会出现。

近年来在 arXiv 上作为预印本发表的学术工作测量了 WebAssembly 模块在不同运行时的实例化时间。这些作品之间的共同点并不是一个收敛的数字：根据测试的运行时、模块的大小和使用的硬件，这是一个显着的差异。

我们自愿不在本文中包含从这些出版物中获取的任何精确数据。在撰写本文时，如果没有对每篇论文的方法进行彻底的双重检查，重新发布一个孤立的数字将准确地重现本文所记录的问题：一个没有上下文的数字，无法让我们知道它真正测量的是什么。

另一方面，这种方差学到的东西是直接有用的：冷启动很大程度上取决于测量上下文，正如我们的一般方法文章中描述的 环境奇偶校验 规则所回忆的那样（相同的硬件、相同的区域、所有比较的系统的相同缓存状态）。

本次辩论中引用最多的三个独立 WebAssembly 运行时并没有以相同的方式平衡编译速度和执行性能，这在一定程度上解释了为什么它们的冷启动数据不能逐项进行比较。

有关无服务器讨论中最常反对的两个运行时之间的完整架构细节，请参阅我们的专门比较 Wasmtime 与 Wasmer。

根据Wasmer公开传达的产品定位，Instaboot通过快照机制恢复已经初始化的实例，而不是每次请求都重新启动一次完整的启动。这是一个真正的架构选择，与其目标问题一致。

然而，本文并没有重复 Wasmer 产品页面上显示的性能数据。在不知道什么硬件、什么工作负载以及什么测量协议产生这个数字的情况下，重新发布它将会犯上面记录的错误：将营销数字视为独立的基准结果。

Aurabase 在生产环境中而不是在试点项目中在 Wasmtime 上运行其边缘功能。这正是该申请所允许的内容，也是该主张的结束。

在服务的生产依赖项中，而不是在 dev-dependency 或注释中，激活了 async 和 cranelift 功能，该依赖项是硬声明的：

# 从存储库中实际提取
[dependencies]

# WASM 运行时
wasmtime = { version = "43", features = ["async", "cranelift"] }

该文件未说明的内容：目前此运行时的存储库中不存在根据 基准方法 中描述的协议测量的冷启动数据。在发布包含分类百分位数、硬件和工作负载的过时测量结果之前，不应引用任何 Aurabase 数据作为产品的测量特征。有关平台的总体架构，请参阅我们的支柱文章 Aurabase Rust 架构。有关冷启动 WASM 和冷启动容器之间的具体比较（与此处讨论的方法问题无关），请参阅我们的专门文章 WASM 与容器。

任何冷启动人物都要问七个问题，包括我们发布那天的问题。

1. 包括哪些阶段？ 网络加载、验证、编译、实例化、首次调用：只统计部分的数字与全部统计的数字没有可比性。
2. 模块真的“冷”吗？ 已在内存或磁盘缓存中的模块不会测试与首次加载的模块相同的内容。
3. JIT 编译还是预编译工件 (AOT)？ 这两种策略具有结构上不同的启动成本。
4. 个位数还是分布？ 十次最佳运行与一千次运行中 p95 的值不同。
5. 指定设备和区域？ 第三方无法复制没有硬件规格的图形。
6. 同等负载和拓扑下的比较？ 将自托管运行时与托管服务进行比较而不报告它会扭曲读数。
7. 测试的运行时的日期和版本？ 一个正在快速发展的项目的未注明日期的数字在几个月后就毫无意义了。