谎言、该死的谎言和（Cloudflare）统计数据：揭穿 Cloudflare 最近的性能测试

作者:糖果
发布时间:2024-05-07 11:57:02 (1天前)
来源:cloudflares-recent-performance-tests

几周前，我们的竞争对手之一 Cloudflare发表了[一篇博文](https://blog.cloudflare.com/network-performance-update-full-stack-week/?_fsi=TVvRQggY&_fsi=TVvRQggY&_fsi=TVvRQggY "一篇博文")，声称他们的边缘计算平台的速度大约是 Compute@Edge 的三倍。这个荒谬的结论提供了一个很好的例子，说明如何使用统计数据来误导。继续阅读 Cloudflare 的测试方法分析，以及更科学、更有用的比较结果。

人们常说，谎言分为三种：谎言、该死的谎言和统计数据。这也许是不公平的：一些统计数据非常合理。但这些不是：

从哪里开始？像这样引用Catchpoint使这种说法听起来像是来自第三方的独立研究。它不是。Catchpoint 允许您根据自己的需要配置他们的工具，这意味着您可以使用它们根据公平和严格的基准标准创建测试，或者您可以使用它们来讲述您想讲述的故事。

# 好的，那么他们的测试有什么问题？
Cloudflare 测试的设计和执行在几个方面存在缺陷：
1. Cloudflare 在测试中使用了精选的 Catchpoint 节点。没有解释为什么选择这组特定的节点，但值得注意的是，Cloudflare 的基础设施与我们的位置并不完全相同，并且测试位置的偏颇选择会极大地影响结果。
2. 他们的测试将运行在 Cloudflare Workers（一种成熟的、普遍可用的产品）上的 JavaScript 与运行在 Compute@Edge 上的 JavaScript 进行了比较。尽管 Compute@Edge 平台现在可供所有产品使用，但在 Compute@Edge 上对JavaScript 的支持是一个测试版产品。我们在文档中明确指出测试版产品尚未准备好用于生产。在这一点上，比较公平的测试是将 Compute@Edge 上的 Rust 与 Cloudflare Workers 上的 JavaScript 进行比较，它们处于产品生命周期的更具可比性的阶段。
3. Cloudflare 使用免费的 Fastly 试用帐户来进行测试。与付费帐户相比，免费试用帐户的用途有限，并且两者在负载下的性能没有可比性。
4. Cloudflare 在一天内的一个小时内完成了他们的测试。这无法针对日常交通模式或异常事件进行标准化，并且容易受到随机失真效应的影响。如果您在一天中的不同时间运行多组测试，很可能在某个时候达到您想要的结果。
5. 博客文章指出，测试代码“执行了一个简单地返回当前时间的函数”，然后继续显示一个代码示例，该示例从入站请求中返回标头的副本。其中之一一定是错误的。如果没有清楚地解释测试方法，就不可能客观地评估或再现结果。
6. 仅使用几乎没有计算负载、没有显着大小的有效负载和没有平台 API 的测试来评估首字节时间 (TTFB) 并不能以任何有意义的方式衡量 Compute@Edge 的性能。
这是糟糕的科学。那么，为什么我们提请注意它，因为我们选择这样做，什么是计算的@缘表现真的很喜欢？

# 惊喜！Compute@Edge 比 Cloudflare Workers 更快
需要明确的是，我们实际上不能肯定地说，因为 TTFB 指标并没有真正告诉您哪个平台“更快”（一分钟后会详细介绍），但我们可以说，在偏差较小的版本中在相同的测试中，我们的网络和 Compute@Edge 得分优于 Cloudflare 的网络和 Cloudflare Workers，即使在 TTFB 上也是如此。
很难衡量边缘网络的相对性能。我们已经超越了 CDN 时代；今天，你不能用单个变量来判断边缘网络的价值。Cloudflare 尤其应该知道这一点，因为它们在边缘拥有一组令人钦佩的功能——在本次练习中没有使用这些功能。
这种“基准”的令人分心的性质使我们对参与任何类似术语的比较持谨慎态度，而且我们不可能定义自己的比较术语，因为 Cloudflare 的使用条款禁止对其服务进行基准测试：
![](/user/files/Vfi9pXfV-TFDztFs1UpTb2HdU7zUsKmzVTylOz2dkcQ.jpeg)
因此，我们在自己的平台上运行了相同的测试（回显标头并通过 Catchpoint 测量 TTFB），但有一些主要区别：
1. 我们使用了 673 个 Catchpoint 节点，而不是 50 个，时间要长得多（一周而不是一小时）。
2. 我们使用了从 Rust 而不是 JavaScript 编译的 Wasm 二进制文件。
3. 我们使用付费 Fastly 帐户而不是免费试用帐户。
您可以自己查看原始结果，但最重要的是，在这些更公平的测试中，我们的网络和 Compute@Edge 在六个区域中的四个区域中比 Cloudflare 的网络和 Workers 更快，即使在这个有缺陷的指标上：
![](/user/files/QunZ4goRQgGIZadVslpSLuOl5wTr5NS0NyQL1-K6g6c.png)
快速数据：中值 TTFB，673 个捕获点节点，378,000 个请求，执行时间为 2021-11-24 00:00 至 2021-11-30 00:00（6 天）[结果] Cloudflare 数据：中值 TTFB，50 个捕获点节点，未知请求数量，从 2021-11-08 20:30 到 2021-11-08 22:00（1.5 小时）[结果]
基于 Cloudflare 的首选 TTFB，我们运行 Compute@Edge 的网络在北美和欧洲的速度几乎是 Cloudflare Workers 的两倍，在大洋洲则快 10 倍。请记住，他们的服务条款禁止进行基准测试，这使我们无法直接测试它们并试图复制那个偏远的大洋洲数字。
Compute@Edge 没有本地语言，因为我们直接在边缘服务器上运行 WebAssembly 二进制文件，但 Rust 是目前提供开发人员体验和编译代码性能的最佳组合之一的语言。如果Compute@Edge 编译为 WebAssembly，你绝对可以在 Compute@Edge 上运行任何东西——人们也这样做。

# 是的，但是…… JavaScript
我们知道对许多客户的 JavaScript 支持很重要，但我们对从 JavaScript 编译的 Compute@Edge 包的性能并不满意。这就是它处于测试阶段的原因。当产品准备好生产时，我们会删除 Beta 名称。
在创建我们的边缘计算平台时，我们的整个方法是制定一条与大多数行业截然不同的路线。这意味着我们的表现也会有所不同——因为我们开始的问题是不同的。

# 测量正确的数字
让我们更详细地深入研究该 TTFB 指标，并探讨为什么它在这种情况下没有用。
Cloudflare 发布了未以任何有意义的方式衡量计算性能的测试结果。我们应该使用一个基准来评估边缘计算在对客户很重要的核心用例中的性能，而不是测量单个变量。网络 RTT 是其中的一部分，但变量也是如此，例如：
- 启动时间，将请求移交给客户代码
- 各种规模的工作负载的计算性能（“思考时间”）
- 缓存性能，包括热对象和长尾内容
- RTT 到源服务器，用于涉及源请求的用例
Cloudflare 的测试在测量网络往返时间方面甚至很糟糕——因为第一个字节的时间涵盖了网络 RTT 和服务器思考时间——并且无法了解每个组件对总数的贡献。如果您想更好地了解性能，可以将它们分开。  
例如，请考虑下图，其中显示了 Fastly 服务在亚洲的网络 RTT 和 TTFB 的中位数。我们的 VCL 平台（左图）提供的缓存命中速度非常快，以至于网络 RTT（蓝色）与 TTFB（绿色）基本相同。使用 Compute@Edge（右），TTFB 是不同的，反映了运行任意代码的成本增加——但是，RTT 仍然是连接延迟普遍较高的地区（以下示例中的亚洲）的绝大多数数字。
![](/user/files/-jUzOWuxMs5c9QA5TyHKDDj-aaLXSgsgGcDk4PrD8Co.png)
RTT 因地理位置而异，我们在之前展示的主要测试结果中看到这种差异非常显着。其结果是，你是不是在CloudFlare的测试中看到的是我们的优势计算平台的相对性能的一个清晰的画面- “服务器思考时间。”

# 为客户创造更好的结果
我们正在开发一个基准套件，它将在更现实的环境中评估性能，我们将发布该基准套件的代码，并由独立的第三方测量和发布结果——因为书呆子狙击是非常令人厌烦的比赛分散了为每个人改善互联网的注意力。
与此同时，Cloudflare Workers 比 Compute@Edge 快 196%绝对不是真的——事实上，它根本不快。但对于我们的客户而言，重要的变量是对其业务至关重要的变量。如果您想知道我们是否足够快地满足您对您关心的指标的特定需求，我们鼓励您尝试我们并自行衡量。

> 本文包含基于 Fastly 的信念和假设以及 Fastly 在本文发布之日目前可获得的信息的“前瞻性”陈述。前瞻性陈述可能涉及已知和未知的风险、不确定性和其他因素，这些因素可能导致我们的实际结果、业绩或成就与前瞻性陈述所明示或暗示的存在重大差异。这些声明包括但不限于关于未来产品供应的声明。除法律要求外，Fastly 不承担公开更新这些前瞻性陈述或更新实际结果可能与前瞻性陈述中预期的结果存在重大差异的原因的义务，即使将来有新信息可用。Fastly 向美国证券交易委员会 (SEC) 提交的报告中不时详细说明了可能导致 Fastly 的实际结果出现重大差异的重要因素，包括我们截至 12 月 31 日的财政年度的 10-K 表格年度报告中， 2020 年，以及我们关于 Form 10-Q 的季度报告。向 SEC 提交的报告副本发布在 Fastly 的网站上，可从 Fastly 免费获取。

1 条回复

动动手指，沙发就是你的了！

登录后才能参与评论