第一次写 文章 《中国大陆对象存储网络性能跟踪报告 04.01 ~ 04.08》华* 垫底好意外。

[nicoljiang]

原文（含大量监控界面截图）： https://mp.weixin.qq.com/s/47nF1v4dS28cMFr3KIuPkQ

报告介绍

缤纷云 — www.bitiful.com
作为国内对象存储的新兴服务商，我们长期观察对象存储的性能与可靠性表现。想借此机会将我们的观察与大家分享，希望为大家的选择提供一点参考依据。

网络性能

数据结论

服务商	在线	TTFB(总)	TCP	SSL	Region
缤纷云 S4	100%	74 ms	25.4 ms	50.7 ms	江苏
阿 OSS	100%	146 ms	34.6 ms	101 ms	江苏
百 BOS	99.98%	207 ms	29.7 ms	152 ms	上海
京 OSS	99.97%	151 ms	27.0 ms	53.3 ms	上海
腾 COS	99.95%	181 ms	30.7 ms	87.2 ms	江苏
七 Koda	99.85%	175 ms	19.1 ms	48.8 ms	全局
华 OSS	99.75%	176 ms	32.0 ms	94.8 ms	上海

一些说明:

1. 百度 BOS 创建的是“上海可用区”的桶，但实际 IP 探测似乎为“山东”；
2. 七牛 Koda 默认套用 CDN ，所以：
   • Region 为“全局”，由于跟用户都是就近连接，故 TCP 建连时间远低于其他；
   • 也导致实际的 TTFB （首字节）延迟反而很大；
   • 导致几乎垫底的在线率（ 99.85%），因为我们的测试方法排除了缓存的干扰。
3. 只有缤纷云 S4 几乎没有多余的性能损耗（ TTFB 时间约等于 3 次 RTT ）。
4. 华为 OBS 在线率的意外垫底，我们感到非常惭愧，未来会持续优化测试方法。

[ GPT 小课堂]

理想情况下首字节（ TTFB ）延迟应该是多少？

提问：假设网络物理延迟为 25ms 服务器响应的首字节的理论延迟是多少 ms ？

GPT4 回答： 如果客户端和服务器之间的物理延迟为 25 毫秒，我们可以将此值用作单个往返时间（ RTT ）。在最理想的情况下，如果使用的是 TLS 1.3 （它可以在一个 RTT 完成 TLS 握手），整个过程的延迟将是： 加总起来，理论延迟将是：

DNS 解析 + TCP 握手 + TLS 握手 + HTTP 请求和响应
即：1 RTT + 1 RTT + 1 RTT + 1 RTT
全流程为 4 次 RTT
每次 RTT 为 25 ms

DNS 缓存前：
    首字节延迟 = 4 * 25 ms = 100 ms
DNS 缓存后（去掉 DNS 解析的 1 次 RTT ）：
    首字节延迟 = 3 * 25 ms = 75 ms

我们最终的目的是发布一个类似cdnperf.com和cloudperf.com的长期观测项目来对网络性能和服务在线率进行跟踪。是倾向于站在用户和终端角度的，不是性能压测。 然后有一些说明：

1. 总共的测试时间不止一周或一个月，也会长期进行。发布周期大概是一周一次或一月一次；
2. 我们在验证自己的网络性能与可靠性，所以本身也需要这样的跟踪和对比数据为我们制定SLA提供依据；
3. 因为我们发现国内没有这样的公开追踪，所以我们会以每周或每月的周期来发布该周期内不同服务的表现；
4. 测试工具是“阿里云的云监控（自动拨测）”，是 多节点、多地区、多线路的；
5. 没用海外的测试工具是因为，目前主要的测试对象是国内大陆的云存储服务；
6. 目前只对比了江浙可用区而不是更多可用区是因为：
   • 我们还只有一个江浙可用区（这样对比更直接）；
   • 大部分中小企业也没富有到可以同时用多个可用区；
   • 在大陆南北中间，并且离日本、北美海缆很近（是一个很居中的区域）。

不是 海外廉价主机的跨境线路测试

不是 海外廉价主机的跨境线路测试

不是 海外廉价主机的跨境线路测试

所以 无法测回程

所以 无法测回程

所以 无法测回程

数据也不是捏造的，原文末尾有阿里云监控的数据截图（图太多没有贴过来）

[totoro625]

推广就推广，正式上线不过才 94 天 /t/1006572

[nicoljiang]

@totoro625 那我应该要等上线 94 年吗？

[ounxnpz]

你们淘汰的企业硬盘哪里卖，我组 nas

[Panameragt]

v2ex 经常看到这家😅

[R18]

有没有一种可能，你们的用户上来了还不如这几家

[helone]

拉踩别人也就算了，你正式上线满一年了吗？就你家排第一？

[hefish]

缤纷云就是好就是好，好的不得了，好的没法说，好的要死了。。。op 赶紧用吧。。 我不用。

[xiaobinkk]

哈哈，这标题，流量让你玩明白了

[Greenm]

先说利益相关：

作为一个厂商，既当运动员又当裁判，这个测试从最开始的定位就站不住脚。

其次是测试方法：

你用阿里云作为拨测的出发点，然后测试其他云的单个 region ，得出仅有阿里云和你们的产品在线率是 100% 的结论。 然后测试时间仅为一周。 你哪怕多上几个节点，多测几个 region ，多用国内国外不同的云服务做做拨测，然后时间拉长到半年一年呢？

最后说你们的结论：

通篇再讲你们那个优势的 TTFB ，说实话我用对象存储根本不在意这个，最让人在意的稳定性和可靠性，你们就用了一周时间测试，然后吹自己是 100%，你们 SLA 可以承诺到 100%吗？ 阿里腾讯才出了事故大家都看见了吧。 推广都不会推广，测试手段业余得不行，在这之前我并不认识你们，说实话看了你这个报告，我对你们印象直接为负，绝对草台班子。

[gxt92]

二、创建拨测
1. 进入阿里云的“云监控”控制台，点击“创建任务”；
你们居然这么测试的？？

[hallomou]

”华为 OBS 在线率的意外垫底，我们感到非常惭愧，未来会持续优化测试方法。“

为什么不说是华为的技术不行呢？反而说是你们测试方法的问题？

[nicoljiang]

@R18 有可能啊，我们会长期跟踪。然后为什么会有这些差距，比较复杂，我们会单开一篇来说网络层的原因。
@Greenm
1. 我们没有想当裁判，只是发布我们的数据观察；
2. 测试周期也不会仅一周，会每周或每月持续观察和发布；
3. 不太懂，国内的对象存储为何要用海外节点测呢？
4. TTFB 你可以不在意，但不妨碍它是评判 http 性能的最重要指标之一；
5. 我们正式运行不到 4 个月，但公测运行了近 2 年，仍然没有发布 SLA ；
6. 但我们做这些跟踪和观察的目的恰恰就是通过连续跟踪到的指标，来先行实践我们的可靠性，为 SLA 提供说服力。我们对 SLA 很谨慎也很尊重。
7. 我们的可用性看板 https://stack-status.com/ 是完全独立的架构（包括域名），并且国内其他公有云都是手动。
8. 我们确实是草台班子，但我们对技术的态度是敬畏的。
@gxt92 那应该怎么测试呢？
@hallomou 不知道该怎么说，因为我知道华为技术非常非常强，而你也看到了，上面有人觉得这种测试方法很扯。肯定有需要改进的地方。

[stoneabc]

从未见过如此简单粗暴的测试方法。。。。。感觉我学生时代都不会想出这种方式来对比评测

[justfindu]

云厂商之间都有一定几率把对方屏蔽, 尤其严重的是 waf.

[x86]

隔壁 nodeseek 测个鸡还三网多地区回程测下，你这...

[nicoljiang]

@stoneabc 我们最终的目的是发布一个类似 cdnperf.com 和 cloudperf.com 的长期观测项目来跟踪。不过你认为应该如何测试，我们也希望可以改进。
@justfindu 这个确实是第一次听说，会了解一下（之前只知道不同运营商会有这种行为）
@x86 我们用阿里云监控从多地区多线路测的，并且我们的测的是对象存储，不是主机，没有测回程的能力。

[nuansediao]

op 至少很诚实，它发的是推广节点

[1423]

友商可以拿这个起诉你们恶意竞争么?

[qwertoazx]

建议发到隔壁 mjj 论坛，让大伙好好测评一下~