Subscribe to receive notifications of new posts:

网络性能更新:Full Stack Week

11/20/2021

13 min read

本博客发布于 2021 年 11 月 20 日。随着我们继续优化我们的网络,我们将发布定期更新,请于此处获取。

Network Performance Update: Full Stack Week

两个多月前,我们分享了全球最后一英里网络的广泛基准测试结果。结果显示,基于一系列的测试(TCP 连接时间、接收第一个字节的时间、接收最后一个字节的时间)和一系列测量值(平均值为 p95),Cloudflare 是全球 49% 的网络中最快的提供商。从那时起,我们一直在不断努力,持续改善性能,力图成为全球最快的提供商。我们设定了一个目标,在每一个创新周,都在额外 10% 的网络中成为最快的提供商。我们在 Birthday Week(2021 年 9 月)期间实现了该目标。

今天,我们很骄傲地报告,我们 Full Stack Week(2021 年 11 月)的目标已取得部分胜利。Cloudflare 针对全球前 1,000 个网络(依据播发的 IPv4 地址数)测量了我们的性能。Cloudflare 已在 79 个新网络中成为最快的提供商,在这 1,000 个网络中增加了 14%。当然,我们尚未完成目标,但我们想要分享最新成果,并说明我们是如何实现的。

然而,在我们详细介绍我们的网络性能之前,我们想要分享一些有关 Workers 平台的新性能指标(鉴于这是 Full Stack Week!)。我们比较了 Cloudflare Workers 和 Fastly 的 Compute@Edge 的数据,结果是:Workers 快 196%。

更快的网络意味着更快的堆栈

几个月前,我们也讨论了 Cloudflare Workers 的性能和其他相似产品的比较情况。我们将我们的性能与 Lambda 和 Lambda@Edge 进行比较,Cloudflare Workers 的性能分别超出 210% 和 298%。

当时,我们想要了解我们与所有竞争产品比较的情况,但是并非所有产品都广泛可用。因此,我们无法报告 Workers 与另一解决方案——Fastly 的 Compute@Edge 的比较情况。

今天,我们很高兴地报告,我们使用 Catchpoint 在世界各地的数据在 50 个节点上运行了测试,根据这些测试中的接收第一个字节的时间,可以得出 Cloudflare Workers 比 Fastly 的 Compute@Edgeis 快 196%。

像过去一样,我们执行了一个函数,仅返回当前时间和所测得的接收第一个字节等待时间(客户端发出 HTTP 请求,到 DNS、连接和 TLS 握手之后,客户端收到请求响应的第一个字节之间的时间长度)。测试在 2021 年 11 月 8 日进行,对 Cloudflare Workers 和 Fastly 的 Compute@Edge 都使用了免费层级帐户。

在两个提供商上运行的代码完全相同 — 是一个返回所有请求标头的小型函数:

addEventListener('fetch', event => event.respondWith(handleRequest(event)));


async function handleRequest(event) {
  let requestHeaders = Object.fromEntries(event.request.headers)

  return new Response(JSON.stringify(requestHeaders), {status: 200})
};

橙色:Cloudflare Workers

黑色:Compute@Edge

如果您想要自行探索结果,此处是数据链接

在建立我们的全球网络的过程中,我们不断加速,利用隔离,并实现零冷启动,从而全方面为客户提供极快速度。

现在,让我们继续讲述 Cloudflare 更广泛的网络性能是如何持续改进的!

测量重要指标

为量化网络性能,我们必须从世界各地的各种不同网络获取足够的数据,以将我们自己与其他提供商进行比较。我们使用 Real User Measurements (RUM) 来从几家不同提供商提取一个 100kb 的文件。世界各地的用户会报告不同提供商的性能。报告数据的用户越多,信号的保真度就越高。目标是准确地反映出在哪些网络中其他提供商的速度更快,以及更重要的,Cloudflare 在哪些地区还可以改进。您可以在这里的原始 Speed Week 博客文章中阅读更多内容。

在量化网络性能的过程中,我们清楚地看到我们并未在所有地区都实现最快速度。在 Birthday Week 之后,我们发现在 601 个国家(地区)/网络对中,我们的速度落后于领先提供商 100 多毫秒(国家(地区)/网络对定义为一个特定国家(地区)内的网络性能)。

我们不断寻找我们慢的原因,然后作出改进。我们在每一个网络所面临的挑战都是独特的,这些挑战展示出互联网上盛行的各种不同问题。我们将深入分析几个网络,展示我们诊断并改进性能的过程。

在此之前,我们先看一下我们在过去两周内努力的成果。

Cloudflare 成为 79 个新网络中的 TCP 连接时间第一名。下表显示了 Full Stack Week 和 Birthday Week 期间,我们在 TCP 连接时间方面排名第一的网络数比较情况:

*Performance is defined by TCP connection time across top 1000 networks in the world by number of IPv4 addresses advertised
*Performance is defined by TCP connection time across top 1000 networks in the world by number of IPv4 addresses advertised

*性能由全球前 1000 个网络(依据播发的 IPv4 地址数)中的 TCP 连接时间定义

出于我们的不断努力,我们在额外 79 个网络中变得更为快速,这代表我们在其中最快的网络数增长了 14%。以下图表展示了 Birthday Week 和 Full Stack Week 周期间我们的排名分布情况对比:

现在我们已经谈论完我们的改进情况,接下来我们将分享我们在全球追求最佳性能的几个故事,每个故事中都有一系列不同的挑战。

在秘鲁适当放置流量

我们改善网络性能的第一站是秘鲁。我们发现,利马的许多用户实际上是被发送到智利来接受服务。Cloudflare 在秘鲁有多个设点,这种事情本不应该发生。将流量发送到智利导致我们在该国家特定网络中的排名位于第四。我们的工程师知道,获得第一的最佳方式是确保所有利马流量保留在该国家范围内,因此我们决定了解一下为什么这么多流量会被路由到国家外部。

这么多流量被路由到国家外部的原因是,网络提供商分配到 Cloudflare 的流量并不均衡,过多用户被发送到一个特定地点。我们的网络有一系列检查和自动防故障措施,让我们能够确保即使发生这种情况,我们的用户也将继续拥有良好的体验。由于分配到我们在利马所在地点的流量不均衡,这里的检查变得过于繁忙;于是,流量被发送到国外。

为短期解决此问题,我们决定对我们在利马的设点进行一些手动负载平衡,同时构建自动化以在未来消除手动操作的需求。我们选择了流量最大的地点,并停止从该地点播发一些前缀。我们的假设是,流量将只流向利马的其他地点,而不是智利,所有一切都将取得平衡,从而改善所有人的 TCP 连接时间,同时将流量保持在国内。我们开始对免费流量的一小部分进行改变,证实了我们的假设是正确的。然后,我们在更大的范围内部署改变,P90 客户端 TCP 往返时间从 240 毫秒降低到 60 毫秒。

于是,Cloudflare 现在成为了秘鲁网络性能中的第一名。

在斯里兰卡降低延迟

我们的下一个示例在另一个半球的斯里兰卡,在这里,我们发现网络提供商将用户的请求路由到纽瓦克市。

1 * * *
2 100.85.0.1 3.061ms 2.522ms 2.728ms
3 198.51.100.146 AS29766 3.651ms 1.855ms 2.715ms
4 198.51.100.145 AS29766 3.438ms 3.225ms 2.805ms
5 222.165.177.150 AS9329 2.233ms 2.272ms 2.843ms
6 222.165.177.145 AS9329 2.703ms 2.862ms 2.291ms
7 103.87.125.253 AS45489 3.658ms 3.708ms 3.613ms
8 103.87.124.245 AS45489 120.027ms 120.665ms 120.471ms
9 103.87.124.146 AS45489 115.597ms 115.863ms 115.178ms
10 50.208.235.157 be-107-2008-pe01.60hudson.ny.ibone.comcast.net AS7922 249.884ms 249.475ms 250.063ms -> going from Sri Lanka to New York
11 96.110.41.145 be-4101-cs01.newyork.ny.ibone.comcast.net AS7922 267.839ms 267.979ms 268.719ms
12 96.110.34.34 be-3112-pe12.111eighthave.ny.ibone.comcast.net AS7922 262.647ms 261.272ms 262.272ms
13 66.208.233.106 AS7922 262.378ms 258.948ms 258.057ms
14 172.70.108.4 AS13335 268.974ms 280.475ms 268.158ms
15 172.67.182.209 AS13335 267.329ms 266.466ms 266.593ms

显然,这会导致严重的延迟问题,出于此原因, Cloudflare 在斯里兰卡的网络中排名第四。尽管科伦坡是一个相对较小的地点,我们还是尽可能多地转移了流量,并通过该地点进行播发,以改善用户体验,并减少发送至纽瓦克市的潜在流量数量。

在进行此操作后,我们发现 P90 客户端 TCP 往返时间从 150 毫秒降低到 50 毫秒。

然而,尽管我们通过科伦坡来播发我们的所有范围,且性能总体来说得到了改善,该提供商仍然将部分 Cloudflare 前缀的流量发送到纽瓦克市。我们联系了该提供商,让他们知道他们所做的这一更改影响到用户体验。

完成所有这些事情后,Cloudflare 在斯里兰卡的排名从第四上升到第一。

Birthday Week 的更新

所有这些网络变化和其他措施,让 Cloudflare 在比以往更多的网络中成为了网络效能的第一名。在 Birthday Week 期间,我们宣布在更多的网络中比我们的竞争对手更快一步。在全球前 1,000 个网络中(依据播发的 IPv4 地址数),下面是 Cloudflare 在 Birthday Week(2021 年 9 月)期间的表现:

截至 Full Stack Week(2021 年 11 月),我们进一步提升了我们的位置,在 79 个新网络中变得更快:

但我们并非仅提高了最后一英里的性能,我们也在收到最后字节的时间方面获得了更好的性能。下面是 Birthday Week(2021 年 9 月) 之前的网络格局:

下面是现在(2021 年 11 月)的网络格局:

Cloudflare 还承诺在每个国家(地区)成为最快的提供商。每个国家(地区)的网络性能是一个活动目标,很大程度上由给定日期访问的用户来驱动。此外,查看长时间范围内不同国家(地区)的总体网络性能可能会遗漏大量数据。话虽这么说,在下面的世界地图中,使用数据展示了 Birthday Week(2021 年 9 月)期间具有最快网络提供商的国家(地区):

下面是两个月之后 Full Stack Week(2021 年 11 月)期间的情况:

长尾延迟

这些性能更新反复不断的主题始终是待解决的长尾问题。随着我们的发展,解决网络上的这些问题对于确保提供卓越性能至关重要。

我们的团队已付出大量努力,且获得了一些伟大的成果,但我们仍在尝试变得更快。我们已自动化探索此类性能问题的过程,我们正在尝试构建自动化,以检测并修复不同类型的此类问题,从而在未来保持最佳网络性能。

像这样跟踪性能不仅仅是让一个数据变得更快,还有助于改善整个堆栈的性能,使一切像闪电般快速。

2021 年我们还有一个即将到来的创新周,之后我们将继续报告我们在优化全球性能方面所取得的进一步进展。

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit 1.1.1.1 from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
Full Stack Week (CN)简体中文Product News (CN)Speed & Reliability (CN)

Follow on X

David Tuber|@tubes__
Cloudflare|@cloudflare

Related posts

December 19, 2021 1:59 PM

在 Cloudflare 上构建您的下一个视频应用程序

过去,构建视频应用程序十分困难。在录制、编码和播放视频背后有许多复杂的技术。幸运的是,Cloudflare Stream 分担走了所有困难的部分,现在您可以轻松构建自定义视频和流媒体应用程序。让我们看一下,我们可以如何结合 Cloudflare Stream、Access、Pages 和 Workers,使用极少的代码创建一个高性能的视频应用程序。...

November 19, 2021 2:05 PM

喜大普奔:Cloudflare Workers 提供对 Stripe JavaScript SDK 原生支持

在应用中处理支付是建立在线业务的关键。对于许多开发者来说,处理支付的主要选择是 Stripe。自从大约七年前我第一次接触 Stripe 以来,这项服务的发展已经远远超出了简单的支付处理。在我去年分享的电子商务示例应用程序中,Stripe使用 Connect 产品管理了一个完整的卖家市场。对于那些不满足于接受支付功能的开发者来说,Stripe 的产品套件非常适用。...