几个月前，我们发布了 Encore.ts — TypeScript 的开源后端框架。
由于已经有很多框架，我们想分享我们做出的一些异常设计决策以及它们如何带来卓越的性能数据。
我们最近发布的性能基准显示，Encore.ts 的请求吞吐量是 Express.js 的 9 倍，是 Fastify 的 2 倍。
今天，我们将继续我们的性能之旅，深入研究 Encore.ts 如何实现令人难以置信的快速冷启动启动时间。
这次我们对 Encore.ts、Fastify、NestJS 和 Express 进行了基准测试，以了解每个框架在冷启动时的表现。
基准测试程序注册了 10 个 API 端点，每个端点都有一个简单的模式，并设置模式验证。
对于模式验证，我们尽可能使用 Zod。
就 Fastify 而言，我们使用 Ajv 作为官方支持的模式验证库。
我们测量了从 JavaScript 代码开始执行到服务器准备好接受传入请求的时间。
对于每个基准测试，我们选取五次运行中的最佳结果。
废话不多说了，让我们深入研究一下数字吧！
(查看 GitHub 上的基准代码。)
如您所见，Encore.ts 实现了惊人的快速冷启动时间，比 Express 快 5 倍以上，比 NestJS 快 17 倍以上。
这怎么可能？通过我们的测试，我们确定了性能的两个主要来源，都与 Encore.ts 的底层工作方式有关。
但在我们开始之前，我们先来谈谈冷启动到底是什么，以及它们为什么重要。
在无服务器环境中，冷启动是指底层平台首先需要启动服务器的新实例以服务传入请求。 （它也可以指第一次启动服务器的新实例来处理请求，例如在部署之后。）
由于请求实际上处于搁置状态，直到进程启动并准备好处理请求为止，因此减少冷启动时间会对应用程序的长尾延迟产生很大影响。
这对于拥有多个无服务器功能的分布式系统尤其重要，因为在处理请求时，您更有可能在系统的某些部分遇到冷启动。
冷启动期间发生的具体情况在一定程度上取决于您要部署到的平台（Kubernetes、Lambda、Cloud Run 等）。
但总的来说，这个过程看起来像这样：
完成这些初始化步骤后，冷启动完成，无服务器函数开始处理传入请求。
前两个步骤很大程度上是我们无法控制的（除了确保代码/容器的大小得到优化），所以让我们将注意力集中在第三步上。
事实上，让我们进一步分解第三步，假设我们正在运行 Node.js：
最后，在加载所有依赖项并执行所有初始化代码后，容器/无服务器函数已准备好处理传入请求。
上面的细分为我们提供了明确的优化目标，Encore.ts 大力优化了它控制的所有步骤。
Encore.ts 在 Rust 中实现并作为本机模块加载到 Node.JS 中。这对于冷启动有几个好处：
需要解析和执行的 JavaScript 更少。由于 JavaScript 是一种解释性语言，因此所有 JavaScript 代码都需要从磁盘读取、解析和执行。 Encore.ts 作为预编译的原生模块，加载速度极快，不需要 JavaScript 引擎（V8）解析或执行。
零 NPM 依赖。由于 Encore.ts 使用 Rust 实现其所有功能，因此它没有任何 NPM 依赖项，这进一步减少了冷启动期间需要执行的 JavaScript 数量。
预编译和优化。 JavaScript 严重依赖于即时编译 (JIT)，其中重复执行的代码会被 JavaScript 引擎优化。这对于解释型语言来说很有意义，但这也意味着第一次运行一段代码时执行速度会相当慢，这会显着影响冷启动。由于 Encore.ts 是用 Rust 实现的，因此它是预编译的，并针对其运行的平台进行了大量优化，这意味着它从第一次执行起就很快。
Encore.ts 默认情况下构建缩小的 Docker 映像，仅包含转译的 JavaScript 和运行应用程序所需的依赖项。这减少了包的大小，从而减少了下载和启动容器所需的时间。
此外，一些计算平台还添加了对流式 Docker 镜像的支持，这意味着该平台可以在下载整个镜像之前启动容器。 Encore.ts 对此有内置支持，并自动优先考虑图像中需要减少冷启动的部分。
通过将 Rust 运行时与优化的 Docker 镜像相结合，Encore.ts 能够实现显着的冷启动时间，这会对应用程序的长尾延迟产生很大影响。
如果性能对您的项目很重要，尝试 Encore.ts 可能是个好主意。
而且它都是开源的，因此您可以查看代码并在 GitHub 上做出贡献。
或者尝试一下，让我们知道您的想法！
以上是Encore.ts — 比 NestJS 和 Fastify 更快的冷启动的详细内容。更多信息请关注PHP中文网其他相关文章！
