Subscribe to receive notifications of new posts:

Subscription confirmed. Thank you for subscribing!

网络性能更新:Full Stack Week

Loading...

本博客发布于 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 的 [email protected] 的数据,结果是:Workers 快 196%。

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

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

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

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

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

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

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

黑色:[email protected]

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

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

现在,让我们继续讲述 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 年我们还有一个即将到来的创新周,之后我们将继续报告我们在优化全球性能方面所取得的进一步进展。

我们保护 整个企业网络, 帮助客户高效构建 互联网规模应用, 加速一切 网站或互联网应用 , 抵御 DDoS 攻击, 阻止 黑客, 并可帮助您踏上 Zero Trust 之旅

从任何设备访问 1.1.1.1, 使用我们的免费应用加速和保护您的互联网。

如需进一步了解我们帮助构建更美好互联网的使命,请从 这里 开始。如果您正在寻找新的职业方向,请查看 我们的空缺职位

Full Stack Week (CN) 简体中文 (CN) 产品新闻 速度和可靠性 (CN)

Follow on Twitter

David Tuber |@tubes__
Cloudflare |Cloudflare

Related Posts

December 19, 2021 1:59PM

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

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