大约四年前，我们推出了Cloudflare Workers，一个直接在边缘运行的无服务器平台。
在本周期间，我们将介绍 Cloudflare 帮助现有 Web 应用变得更快的多种方式。但如果您今天决定将自己的想法变为现实，那么在 Cloudflare 边缘上构建您的项目，并将其直接部署到互联网上，就是确保您的应用对每个用户都始终快速的最佳方式，无论他们身在何处。
我们已经有几年没有讨论 Cloudflare Workers 与其他无服务器平台的性能比较了，所以我们决定是时候进行更新了。虽然我们过去几年在 Workers 平台上的大部分工作都是为了增强平台的功能，例如引入新特性、API、存储、调试和可观察性工具，但性能方面也没有被忽视。
今天， Workers 的速度比三年前提高了 30%（P90）。而且它比 Lambda@Edge 快 210%，比 Lambda 快 298%。
对了，我们还消除了冷启动。
您如何衡量无服务器平台的性能？
我过去做过数百次有关各种 CDN 的性能基准测试 ——方法很简单：我们使用一个名为 Catchpoint 的工具，它从世界各地的节点向同一资源发出请求，并报告请求为每个地点返回响应所花费的时间。
衡量无服务器性能则略有不同，由于比较的是计算性能，而不是静态资源的性能，我们希望确保所有函数执行相同的操作。
在我们 2018 年有关速度测试的博客文章中，我们让每个函数简单地返回当前时间。对于本测试，如果“无服务器”产品无法满足执行这项任务的最低标准，将被取消资格。本轮测试中使用的无服务器产品执行了具有相同计算复杂性的相同函数，以确保结果准确、公正。
还要注意的一点是，我们要测量什么。性能之所以重要，是因为它影响实际最终客户的体验。延迟的来源是什么并不重要： DNS，网络拥塞，冷启动……客户并不关心来源是什么，他们关心的是为等待应用加载而浪费的时间。
因此，根据端到端最终用户体验来衡量性能很重要，这就是我们使用全球基准来衡量性能的原因。
如下结果显示从全球 50 个节点运行的测试，包括北美、南美、欧洲、亚洲和大洋洲。
蓝色： Cloudflare Workers 红色：Lambda@Edge 绿色：Lambda
（查看结果的链接）。
从结果可以看出，无论用户身处何地，在速度方面，Workers 都能为客户提供最佳体验。
就 Workers 而言，获得全球范围的最佳性能不需要开发人员付出任何额外努力。开发人员不需要进行任何额外的负载平衡或区域配置。每次部署都会立即运行于 Cloudflare 的广泛边缘网络上。
即使您不打算面向全球受众，并且您的客户群位于美国东海岸， Workers 也能够保证对所有请求提供最快的响应。
上图是刚仅来自华盛顿特区的结果，尽可能接近 us-east-1。同样，在未进行任何优化的情况下， Workers 速度快 34%。
为何如此呢？
什么决定了无服务器平台的性能？
除了代码本身的性能之外，从最终用户的角度来看，无服务器应用性能基本上取决于两个变量：应用执行位置与用户的距离，以及运行时本身启动所花费的时间。由于意识到与用户的距离正在成为应用性能方面越来越大的瓶颈，许多无服务器供应商不断向边缘推进。在边缘——更靠近最终用户——运行应用可提高性能。随着 5G 网络普及，这一趋势只会继续加速。
然而，许多无服务器领域的云供应商在竞相提高性能时，面临一个关键问题。问题就是：他们用来构建产品的传统架构并不能在边缘的固有限制内很好地运行。
由于无服务器模型背后的目标是有意抽象出底层架构，并非每个人都清楚 AWS 等传统云提供商如何创建像 Lambda 这样的无服务器产品。传统云提供商通过为您的代码启动容器化进程来提供无服务器产品。提供商在后台自动扩展所有不同的进程。每次启动容器时，整个语言运行时都会随之启动，而不仅仅是您的代码。
为了解决第一个图表，即衡量全球性能，供应商正在尝试从其大型、集中式架构（少数几个大型数据中心）转移到一个分布式、基于边缘的架构（在世界各地设置更多较小规模的数据中心），以便来缩短应用与最终用户之间的距离。但他们的方法存在一个问题：较小的数据中心意味着机器更少，内存容量也更小。每当供应商采用小而多的数据中心策略以更接近边缘时，任何单个进程发生冷启动的可能性就会增加。
这实际上为基于容器的架构上运行的无服务器应用造成了性能上限。如果拥有小型数据中心的传统供应商使您的应用更靠近边缘（和用户），可用服务器和内存将更少，应用需要冷启动的可能性将更高。为了降低这种可能性，他们又回到了更集中化的模型；但这意味着要从少数几个大型集中数据中心运行您的应用。顾名思义，这些较大的集中式数据中心几乎总是离您的用户更远。
上图可以看到这一点，查看在 Lambda@Edge 上运行时的测试结果——尽管离最终用户的距离减少了，p90 性能却比 Lambda 更慢，因为容器需要更频繁地启动。
基于容器构建的无服务器架构可以在性能边界上下调整，但最终它们无法从根本上改变边界曲线。
为何 Workers 速度如此之快？
Workers 是从头开始为边缘优先的无服务器模型设计的。由于 Cloudflare 从一个分布式边缘网络开始，而不是试图将计算从大型集中数据中心推向边缘，在这些限制下工作迫使我们进行创新。
在我们之前的一篇博客文章中 ，我们已经讨论了这种创新如何转化为新的范式转变， Workers架构在轻量级 V8 隔离之上构建，能够快速启动，不会给每个请求引入冷启动。
运行隔离环境不仅赋予我们现成的优势，而且随着 V8 的不断改进，我们的平台也在不断提升。例如，当V8 发布 Liftoff （用于 WASM 的编译器）时，所有 WASM Workers 的速度立即得到提升。
同样地，每当对 Cloudflare 的网络（例如，当我们添加新的数据中心时）或堆栈（例如，支持新的、更快的协议，如 HTTP/3）进行改进， Workers 都会立即从中受益。
此外，我们一直在寻求改进 Workers 本身，使这个平台变得更快。例如，我们去年发布了一项改进，帮助客户消除了冷启动。
帮助 Workers 识别和解决性能差距的一个关键优势是它运行的规模。今天， Workers 为世界各地从业余爱好者到企业的数十万开发人员提供服务，每秒钟处理数百万个请求。每当我们为单个客户进行改进时，整个平台就会变得更快。
性能很重要
无服务器模型的最终目标是让开发人员专注于他们最擅长的事情——为用户构建体验。选择一个开箱即用即可提供最佳性能的无服务器平台，为开发人员减少了一件麻烦事。如果您需要花时间优化冷启动，就没有时间为客户构建最佳的功能。
就像开发人员希望通过提高其应用的性能来为他们的用户创造最佳体验一样，我们也在不断努力为使用 Workers 进行构建的开发人员改善体验。
就像客户不想等待缓慢的响应一样，开发人员也不希望等待缓慢的部署周期。
这是 Workers 平台再次表现出色的地方。
在 Cloudflare Workers 上进行的任何部署都能在不到一秒的时间内传播到全球，让您无需等待代码部署，用户也能尽快看到变化。
当然，重要的不仅仅是部署时间本身，整个开发周期的效率也很重要，这就是为什么我们在从注册到调试的每一个步骤不断寻求改进。
不要只听我们说。
无需多言，尽管我们努力保持中立，但我们总是会带有一点偏见。幸运的是，您不必只相信我们所说的。
我们诚邀您立即注册并部署您的第一个 Worker —— 只需几分钟！