CODEWITHSUNDEEP
p2pipfslibp2p
1.618employment
1.618employment

Reputation: 106

What should my expectations be regarding IPFS response times?

IPFS-SERVER

I have a go-ipfs daemon, configured with the standard ipfs "server" profile, running on a linux server, hosted by a large cloud provider .

IPFS-CLIENT

I have an go-ipfs daemon, configured with the ipfs "default" profile, running on a Windows 10 laptop at my SOHO, behind NAT.

Observation #1

When I "publish" via CLI or API (ipfs name publish...) the multihash of a small text file from "IPFS-SERVER" the command takes about 120 seconds to 150 seconds to complete.

When I "cat" via CLI or API (ipfs cat /ipns/multihash) from "IPFS-CLIENT" the command takes about 60 seconds to 120 seconds to complete.

Questions

Are these the typical or expected response times for these commands?

Are there tweaks that can be made to the ipfs config on the client and/or server to reduce these response times?

Observation #2

When I use the same setup but with a "private swarm" the response times are almost instantaneous.

Things I've Tried

  1. I've tried adding "IPFS-SERVER" to "IPFS-CLIENT" bootstrap list with no improvement
  2. I've tried a "swarm connect" from "IPFS-CLIENT" to "IPFS-SERVER" with no improvement

I suspect being part of the "public swarm" comes with this performance hit as the DHT is larger and so takes longer to parse? Or is there some other mechanism at play here? - Thank You!!!

Upvotes: 1

Views: 554

Answers (1)

Adin Schmahmann
Adin Schmahmann

Reputation: 273

First thing up is that you're measuring IPNS response time and not IPFS response times. There are some tradeoffs regarding the mutability property of IPNS that cause it to be slower than immutable IPFS.

I suspect being part of the "public swarm" comes with this performance hit as the DHT is larger and so takes longer to parse? Or is there some other mechanism at play here?

Yes, the reason the public swarm search takes longer is because of the DHT's performance. As of go-ipfs v0.5.0 the DHT algorithm is much more performant, however the properties of the DHT depend on its members and many of them are still pre v0.5.0. As more people upgrade (or if there is some version bump to the DHT protocol the effectively forks away from old) things should improve.

Are these the typical or expected response times for these commands?

Your measurements seem on the high end (I average about 30 seconds for IPNS Publish/Resolve, and 2 minutes in the outlier cases), but I'm not surprised by them. Note: the time to do ipfs cat /ipfs/Hash should be much faster than ipfs cat /ipns/Hash (unless you are running IPNS over PubSub and the publisher of /ipns/Hash has the data it references, e.g. /ipfs/Hash)

Are there tweaks that can be made to the ipfs config on the client and/or server to reduce these response times?

If you enable IPNS over PubSub --enable-namesys-pubsub on both the SERVER and CLIENT your search times should DRASTICALLY improve. As a bonus, IPNS over PubSub (as of go-ipfs v0.5.0) will get even faster if you happen to already be connected to someone else who has the IPNS record (e.g. the publisher or another IPNS over PubSub subscriber who has previously fetched that record).

If you don't want to enable IPNS over PubSub you can also modify the settings for ipfs name resolve, such as setting --dht-record-count to a low number (e.g. 1 if you're not so picky about finding the latest version, or if the data updates infrequently) or setting --stream if you're ok getting the latest records as you discover them.

Upvotes: 1

Related Questions