我对 IPFS 响应时间的期望是什么？

Question

IPFS-服务器

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

IPFS 客户端

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

观察#1

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

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

问题

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

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

观察#2

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

我尝试过的事情

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

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

Answer 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 配置进行调整以减少这些响应时间？

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

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