这是一个创建于 245 天前的主题，其中的信息可能已经有所发展或是发生改变。
原文（含大量监控界面截图）： 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 | 上海 |
一些说明:
- 百度 BOS 创建的是“上海可用区”的桶，但实际 IP 探测似乎为“山东”；
-
七牛 Koda 默认套用 CDN ，所以：
- Region 为“全局”，由于跟用户都是就近连接，故 TCP 建连时间远低于其他；
- 也导致实际的 TTFB （首字节）延迟反而很大；
- 导致几乎垫底的在线率（ 99.85%），因为我们的测试方法排除了缓存的干扰。
- 只有缤纷云 S4 几乎没有多余的性能损耗（ TTFB 时间约等于 3 次 RTT ）。
- 华为 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
第 1 条附言 · 245 天前
我们最终的目的是发布一个类似cdnperf.com和cloudperf.com的长期观测项目来对网络性能和服务在线率进行跟踪。是倾向于站在用户和终端角度的，不是性能压测。 然后有一些说明：
- 总共的测试时间不止一周或一个月，也会长期进行。发布周期大概是一周一次或一月一次；
- 我们在验证自己的网络性能与可靠性，所以本身也需要这样的跟踪和对比数据为我们制定SLA提供依据；
- 因为我们发现国内没有这样的公开追踪，所以我们会以每周或每月的周期来发布该周期内不同服务的表现；
- 测试工具是“阿里云的云监控（自动拨测）”，是 多节点、多地区、多线路的；
- 没用海外的测试工具是因为，目前主要的测试对象是国内大陆的云存储服务；
-
目前只对比了江浙可用区而不是更多可用区是因为：
- 我们还只有一个江浙可用区（这样对比更直接）；
- 大部分中小企业也没富有到可以同时用多个可用区；
- 在大陆南北中间，并且离日本、北美海缆很近（是一个很居中的区域）。
不是 海外廉价主机的跨境线路测试
不是 海外廉价主机的跨境线路测试
不是 海外廉价主机的跨境线路测试
所以 无法测回程
所以 无法测回程
所以 无法测回程
数据也不是捏造的，原文末尾有阿里云监控的数据截图（图太多没有贴过来）
19 条回复 • 2024-04-12 11:28:32 +08:00
 |
1
totoro625 245 天前
推广就推广，正式上线不过才 94 天 /t/1006572
|
 |
2
nicoljiang OP  1
@totoro625 那我应该要等上线 94 年吗？
|
 |
3
ounxnpz 245 天前 1
你们淘汰的企业硬盘哪里卖，我组 nas
|
 |
4
Panameragt 245 天前
v2ex 经常看到这家😅
|
 |
5
R18 245 天前
有没有一种可能，你们的用户上来了还不如这几家
|
 |
6
helone 245 天前
拉踩别人也就算了，你正式上线满一年了吗？就你家排第一？
|
 |
7
hefish 245 天前
缤纷云就是好就是好，好的不得了，好的没法说，好的要死了。。。op 赶紧用吧。。 我不用。
|
 |
8
xiaobinkk 245 天前
哈哈，这标题，流量让你玩明白了
|
 |
9
Greenm 245 天前 8
先说利益相关：
作为一个厂商，既当运动员又当裁判，这个测试从最开始的定位就站不住脚。 其次是测试方法： 你用阿里云作为拨测的出发点，然后测试其他云的单个 region ，得出仅有阿里云和你们的产品在线率是 100% 的结论。 然后测试时间仅为一周。 你哪怕多上几个节点，多测几个 region ，多用国内国外不同的云服务做做拨测，然后时间拉长到半年一年呢？ 最后说你们的结论： 通篇再讲你们那个优势的 TTFB ，说实话我用对象存储根本不在意这个，最让人在意的稳定性和可靠性，你们就用了一周时间测试，然后吹自己是 100%，你们 SLA 可以承诺到 100%吗？ 阿里腾讯才出了事故大家都看见了吧。 推广都不会推广，测试手段业余得不行，在这之前我并不认识你们，说实话看了你这个报告，我对你们印象直接为负，绝对草台班子。 |
 |
10
gxt92 245 天前
二、创建拨测
1. 进入阿里云的“云监控”控制台，点击“创建任务”； 你们居然这么测试的？？ |
 |
11
hallomou 245 天前
”华为 OBS 在线率的意外垫底，我们感到非常惭愧，未来会持续优化测试方法。“
为什么不说是华为的技术不行呢？反而说是你们测试方法的问题？ |
|
12
nicoljiang OP @R18 有可能啊，我们会长期跟踪。然后为什么会有这些差距，比较复杂，我们会单开一篇来说网络层的原因。
@Greenm 1. 我们没有想当裁判，只是发布我们的数据观察； 2. 测试周期也不会仅一周，会每周或每月持续观察和发布； 3. 不太懂，国内的对象存储为何要用海外节点测呢？ 4. TTFB 你可以不在意，但不妨碍它是评判 http 性能的最重要指标之一； 5. 我们正式运行不到 4 个月，但公测运行了近 2 年，仍然没有发布 SLA ； 6. 但我们做这些跟踪和观察的目的恰恰就是通过连续跟踪到的指标，来先行实践我们的可靠性，为 SLA 提供说服力。我们对 SLA 很谨慎也很尊重。 7. 我们的可用性看板 https://stack-status.com/ 是完全独立的架构（包括域名），并且国内其他公有云都是手动。 8. 我们确实是草台班子，但我们对技术的态度是敬畏的。 @gxt92 那应该怎么测试呢？ @hallomou 不知道该怎么说，因为我知道华为技术非常非常强，而你也看到了，上面有人觉得这种测试方法很扯。肯定有需要改进的地方。 |
 |
13
stoneabc 245 天前
从未见过如此简单粗暴的测试方法。。。。。感觉我学生时代都不会想出这种方式来对比评测
|
 |
14
justfindu 245 天前
云厂商之间都有一定几率把对方屏蔽, 尤其严重的是 waf.
|
 |
15
x86 245 天前
隔壁 nodeseek 测个鸡还三网多地区回程测下，你这...
|
|
16
nicoljiang OP @stoneabc 我们最终的目的是发布一个类似 cdnperf.com 和 cloudperf.com 的长期观测项目来跟踪。不过你认为应该如何测试，我们也希望可以改进。
@justfindu 这个确实是第一次听说，会了解一下（之前只知道不同运营商会有这种行为） @x86 我们用阿里云监控从多地区多线路测的，并且我们的测的是对象存储，不是主机，没有测回程的能力。 |
 |
17
nuansediao 245 天前
op 至少很诚实，它发的是推广节点
|
 |
18
1423 245 天前
友商可以拿这个起诉你们恶意竞争么?
|
 |
19
qwertoazx 244 天前
建议发到隔壁 mjj 论坛，让大伙好好测评一下~
|
Select Language