1

IPFS-服务器

我有一个 go-ipfs 守护程序,配置有标准 ipfs“服务器”配置文件,运行在由大型云提供商托管的 linux 服务器上。

IPFS 客户端

我有一个 go-ipfs 守护程序,配置了 ipfs“默认”配置文件,在我 SOHO 的 Windows 10 笔记本电脑上运行,在 NAT 后面。

观察#1

当我通过 CLI 或 API(ipfs 名称发布...)“发布”来自“IPFS-SERVER”的小文本文件的多重哈希时,该命令大约需要 120 秒到 150 秒才能完成。

当我从“IPFS-CLIENT”通过 CLI 或 API(ipfs cat /ipns/multihash)“cat”时,该命令大约需要 60 秒到 120 秒才能完成。

问题

这些是这些命令的典型或预期响应时间吗?

是否可以对客户端和/或服务器上的 ipfs 配置进行调整以减少这些响应时间?

观察#2

当我使用相同的设置但使用“私人群”时,响应时间几乎是瞬时的。

我尝试过的事情

  1. 我尝试将“IPFS-SERVER”添加到“IPFS-CLIENT”引导列表,但没有任何改进
  2. 我尝试了从“IPFS-CLIENT”到“IPFS-SERVER”的“swarm connect”,但没有任何改进

我怀疑成为“公共群体”的一部分会带来这种性能损失,因为 DHT 更大,因此解析时间更长?还是这里有其他机制在起作用?- 谢谢你!!!

4

1 回答 1

1

首先要测量的是 IPNS 响应时间,而不是 IPFS 响应时间。关于 IPNS 的可变性属性有一些权衡,导致它比不可变的 IPFS 慢。

我怀疑成为“公共群体”的一部分会带来这种性能损失,因为 DHT 更大,因此解析时间更长?还是这里有其他机制在起作用?

是的,公共群体搜索需要更长的时间是因为 DHT 的性能。从 go-ipfs v0.5.0 开始,DHT 算法的性能要高得多,但是 DHT 的属性取决于其成员,其中许多仍然是 v0.5.0 之前的版本。随着越来越多的人升级(或者如果 DHT 协议有一些版本冲突,那么有效地分叉)事情应该会有所改善。

这些是这些命令的典型或预期响应时间吗?

您的测量结果似乎处于高端(IPNS 发布/解析平均约为 30 秒,异常情况为 2 分钟),但我对它们并不感到惊讶。注意:做的时间ipfs cat /ipfs/Hash应该比ipfs cat /ipns/Hash(除非你在 PubSub 上运行 IPNS 并且 /ipns/Hash 的发布者有它引用的数据,例如 /ipfs/Hash)快得多

是否可以对客户端和/或服务器上的 ipfs 配置进行调整以减少这些响应时间?

如果您--enable-namesys-pubsub在服务器和客户端上启用 IPNS over PubSub,您的搜索时间应该会大大缩短。作为奖励,IPNS over PubSub(从 go-ipfs v0.5.0 开始)如果您碰巧已经连接到拥有 IPNS 记录的其他人(例如,发布者或其他 IPNS over PubSub 订阅者之前已获取那个记录)。

如果您不想通过 PubSub 启用 IPNS,您还可以修改 的设置ipfs name resolve,例如设置--dht-record-count为较低的数字(例如,如果您对查找最新版本不那么挑剔,或者如果数据不经常更新,则为 1)或设置--stream是否可以在发现最新记录时获取最新记录。

于 2020-08-04T20:43:08.260 回答