IPFS-SERVER
我有一个go-ipfs守护进程，用标准的ipfs"服务器"；概要文件，运行在linux服务器上，由大型云提供商托管。
IPFS-CLIENT
我有一个go-ipfs守护进程，配置了ipfs"默认"；配置文件，运行在我SOHO的Windows 10笔记本电脑上，位于NAT后面。
观察#1
当我"；发布"；通过CLI或API(ipfs名称发布…(；IPFS-SERVER"；该命令需要大约120秒到150秒才能完成。
当我"；猫；经由CLI或API(ipfs-cat/ipns/multihash(从；IPFS-CLIENT"；该命令需要大约60秒到120秒才能完成。
问题
这些是这些命令的典型响应时间还是预期响应时间？
是否可以对客户端和/或服务器上的ipfs配置进行调整以减少这些响应时间？
观察#2
当我使用相同的设置但带有"；私人群体；响应时间几乎是瞬时的。
我尝试过的东西
- 我尝试添加"；IPFS-SERVER"；至"；IPFS-CLIENT"；引导程序列表没有改善
- 我试过；群连接"；从"；IPFS-CLIENT"；到"IPFS-SERVER"；没有任何改善
我怀疑自己是"；"公共群体"；由于DHT更大，因此需要更长的时间来解析，因此性能会受到影响吗？还是有其他机制在起作用？-非常感谢。
首先要测量的是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配置进行调整以减少这些响应时间？
如果您在SERVER和CLIENT上都通过PubSub--enable-namesys-pubsub启用IPNS，您的搜索时间应该会大大缩短。作为奖励，如果您碰巧已经连接到其他有IPNS记录的人(例如发布者或另一个先前获取过该记录的IPNS over PubSub订阅用户(，则通过PubSub的IPNS(截止到目前的ipfs v0.5.0(将变得更快。
如果您不想通过PubSub启用IPNS，您也可以修改ipfs name resolve的设置，例如将--dht-record-count设置为一个低数字(例如，如果您对查找最新版本不太挑剔，或者数据更新不频繁，则设置为1(，或者如果您可以在发现最新记录时获取这些记录，则设置--stream。