时间戳

首页 > 解决方案 > 我对 IPFS 响应时间的期望是什么？

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

问题描述

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 更大，因此解析时间更长？还是这里有其他机制在起作用？- 谢谢你！！！

标签： p2pipfslibp2p

解决方案

首先要测量的是 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是否可以在发现最新记录时获取最新记录。

推荐阅读