【IPFS相关】IPFS网关基准测试及数据

七个主流IPFS网关供应商的“测试”结果……

【IPFS相关】IPFS网关基准测试及数据 IPFS 第1张
本文由IPFS原力区收集译制,版权所属原作者
 

Aadhi Manivannan:我在Protocol Labs工作了6个月,现在已经不再在那里工作了。

 
性能是IPFS的一个重要问题,有许多探索这个更广泛问题的不同途径。
 
我决定选择的途径:IPFS网关。什么是IPFS网关?这是浏览器用户无需运行守护程序即可访问IPFS托管内容的方式。换句话说,它有助于创建从今天的Web到DWeb(在本例中是IPFS)的无缝桥梁。
 
那里不乏社区提供的网关,最常见的是ipfs.io,因为协议实验室(创建IPFS的公司)运行它。但其他强有力的竞争者仍然存在,包括Cloudflare
 
看看可用的选项,脑子里出现了一个想法:哪一个最适合我的日常使用?
我决定找出答案。
 
测试概述
 
我想让这个测试保持简单。
话虽如此,测试包括调用三个不同的文件:
  • 文本文件(~1.3KB)
  • 图像文件(~3.6MB)
  • 视频文件(约153.3MB)
你可以用上面的超链接访问它们。我把它们托管在Pinata的固定服务上,并计划在可预见的未来保持它们的正常运行。
 
我从七个不同的网关提供商的地址中调用每个文件:
  • Protocol Labs (https://ipfs.io/ipfs/)
  • Cloudflare (https://cloudflare-ipfs.com/ipfs/)
  • Infura (https://ipfs.infura.io/ipfs/)
  • Pinata (https://gateway.pinata.cloud/ipfs/)
  • Eternum (https://ipfs.eternum.io/ipfs/)
  • Siderus (https://siderus.io/ipfs/)
  • Temporal (https://gateway.temporal.cloud/ipfs/)
 
我还提出了另一个问题:在不同的地理位置运行该测试
  • US-East
  • US-West
  • EU-London
  • EU-Frankfurt
  • AP-Tokyo
  • AP-Mumbai
  • AP-Sydney
  • SA-Sao Paolo
 
为了测试这些不同的地理位置,我使用了AWS的t2.micro实例。
如果你对运行这些测试的代码感兴趣,我已将其上传到GitHub。你可以按照自述文件在自己的机器上启动。
 
确定获胜者的方法
 
在分享我的方法之前的一点说明:我不是在寻找最快的网关。或者性能差异最小的那个。我正在寻求速度和一致性之间的平衡。
 
为此,我确定了四个子类别的胜利者。然后我使用了第五个子类来打破平局。这些类别是:
  • 10次尝试的最低速度
  • 10次尝试的最高速度
  • 10次尝试的最低平均速度
  • 通过10次尝试的最低中位值
  • 仲裁:10次尝试的最低标准偏差
 
结果
 
接下来的几个表都是很详细的。
对于寻找通用答案的人来说,Cloudflare获胜。
 
下表中字母的简短说明:
  • PL = Protocol Labs
  • C = Cloudflare
  • I = Infura
  • P = Pinata
  • E = Eternum
  • S = Siderus
  • T = Temporal
如果要查看excel中的原始数据和表,可以此处查看
文字结果
 【IPFS相关】IPFS网关基准测试及数据 IPFS 第2张
图像结果
【IPFS相关】IPFS网关基准测试及数据 IPFS 第3张
视频结果
【IPFS相关】IPFS网关基准测试及数据 IPFS 第4张
* Std Dev仅打破平局
 
讨论结果
 
一般来说,Cloudflare的网关是一个安全的选择。它提供了跨地理和文件类型的可靠性能。如果你在孟买,悉尼或圣保罗地区,无论文件类型如何,它们也是最好的网关。
 
排名第二和第三的是 Protocol Labs 和Pinata。前者是IPFS旗下的公司。后者一个在社区中有固定服务的公司。对我来说似乎很有意义。
 
关于这些结果的最后一点说明。在查看这些性能指标时,我忽略了一个大数据点:每个网关上的流量。我的假设是协议实验室在其网关上获得更多流量。毕竟,大多数人默认使用他们的网关地址。
 
更多流量=更多问题。并且我的数据中的任何地方都没有捕获该变量。但是,我希望这种分析最终会引起对备用网关的关注,以此作为负载平衡的一种方式。
 
最后-冷启动问题
 
这些数据=令人大开眼界,值得一提的是我的想法,我以前在Serverless的世界里看到过。
 
冷启动问题
 
在Serverless的世界环境中,Mike Roberts将冷启动问题描述为:
在每个事件之前,FaaS平台都需要一些时间来初始化函数的实例。这种启动延迟可能会有很大的差异,甚至对于一个特定的函数也是如此,具体取决于很多因素,并且可能在几毫秒到几秒的范围内……
 
Lambda函数的初始化将是“热启动” -(重用Lambda函数的实例及其来自以前事件的宿主容器),也可以是“冷启动”(创建新的容器实例,启动函数宿主进程),等等。毫不奇怪,在考虑启动延迟时,这些冷启动引起了最多的关注。
 
– Mike Roberts,Serverless的世界体系结构
 
IPFS网关的背景下,这个问题似乎存在(至少在某种程度上)。例如,按地理位置查看Cloudflare在文本文件(~1.3KB)上的表现:
【IPFS相关】IPFS网关基准测试及数据 IPFS 第5张
冷启动问题全面展开
 
很清楚。在尝试1和尝试2-10之间,每个地理位置都有很大的性能改进。但是,我不确定这是一个IPFS问题。为了说明 – 除了Infura的表现之外,这里的剪辑相同:
【IPFS相关】IPFS网关基准测试及数据 IPFS 第6张
也许不
 
我不太清楚存在冷启动的问题,坦率地说,我不确定这种差异来自何处。是IPFS本身吗?是网关的架构吗?难道我做错了什么?我不清楚。
 
但这是件好事。
 
思考
 
让我们明确一点:这并不完美。这是一个简单而通用的测试,我把它放在一起看一些数据。我回答了我的个人问题:我应该使用哪个网关?但是,我可能没有回答你的问题。
如果是这样,请随意使用我的原始数据进行自己的分析。或者,自己运行测试并分享结果。或者,如果你觉得自己很有雄心壮志 ,请通过推送PR来编辑测试
本文由IPFS原力区编译,原文链接:
https://aadhi.rocks/benchmarking-ipfs-gateways/
【IPFS相关】IPFS网关基准测试及数据 IPFS 第7张
【IPFS原力区】
价值观:价值 共建 共享 荣耀
 
总部位于上海,聚集基于分布式网络&存储的众多技术大咖和爱好者,深耕基于 IPFS 的商业生态建设和社区发展。
 
每周二举办“分布式存储网络”主题沙龙,聚集了众多技术大咖和 IPFS 爱好者,通过持续输出全面、精细、优质的 IPFS 咨询和技术支持,将生态中的爱好者转化为 IPFS 支持者和参与者,共建 IPFS 生态的健康发展。

【IPFS相关】IPFS网关基准测试及数据 IPFS 第8张

本文来自https://aadhi.rocks,经授权后发布,本文观点不代表IPFSER立场,转载请联系原作者。

发表评论

登录后才能评论

联系我们

在线咨询:点击这里给我发消息

邮件:ipfsforce@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code