本博客发布于 2021 年 11 月 20 日。随着我们继续优化我们的网络,我们将发布定期更新,请于此处获取。
两个多月前,我们分享了全球最后一英里网络的广泛基准测试结果。结果显示,基于一系列的测试(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 都使用了免费层级帐户。
在两个提供商上运行的代码完全相同 — 是一个返回所有请求标头的小型函数:
橙色:Cloudflare Workers
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})
};
黑色: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
*性能由全球前 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 年我们还有一个即将到来的创新周,之后我们将继续报告我们在优化全球性能方面所取得的进一步进展。