Во-первых, вы измеряете время ответа IPNS, а не время ответа IPFS. Есть некоторые компромиссы относительно свойства изменчивости IPNS, из-за которых он работает медленнее, чем неизменяемый IPFS. больше и поэтому разбор занимает больше времени? Или здесь задействован какой-то другой механизм?
Да, поиск по publi c swarm занимает больше времени из-за производительности DHT. Начиная с go -ipfs v0.5.0 алгоритм DHT намного более производительный, однако свойства DHT зависят от его членов, и многие из них по-прежнему работают до v0.5.0. По мере того, как все больше людей обновляется (или если есть какой-то скачок версии для протокола DHT, который фактически разветвляется от старого), все должно улучшаться.
Это типичное или ожидаемое время отклика для этих команд?
Ваши измерения кажутся на высоком уровне (я в среднем около 30 секунд для IPNS Publish / Resolve и 2 минуты в исключительных случаях), но они меня не удивляют. Примечание: время выполнения ipfs cat /ipfs/Hash должно быть намного быстрее, чем ipfs cat /ipns/Hash (если вы не используете IPNS через PubSub и издатель / ipns / Ha sh не имеет данных, на которые он ссылается, например / ipfs / Ha sh )
Можно ли внести изменения в конфигурацию ipfs на клиенте и / или сервере, чтобы уменьшить время ответа?
Если вы включите IPNS через PubSub --enable-namesys-pubsub как на СЕРВЕРЕ, так и на КЛИЕНТЕ время поиска должно СРАЗИТЕЛЬНО улучшить. В качестве бонуса IPNS через PubSub (начиная с go -ipfs v0.5.0) будет работать еще быстрее, если вы уже подключены к кому-то еще, у кого есть запись IPNS (например, издателю или другому подписчику IPNS через PubSub, у которого есть ранее полученная эта запись).
Если вы не хотите включать IPNS через PubSub, вы также можете изменить настройки для ipfs name resolve, например, установить --dht-record-count на меньшее число (например, 1, если вы ' (не так разборчивы в поиске последней версии или если данные обновляются нечасто) или установке --stream, если вы в порядке, получать последние записи по мере их обнаружения.