Speeding up discovery and loading times to our nodes

Help IPFS
1

Hello colleagues!

We are running two nodes that host our files. New files get uploaded and pinned to both nodes.
The nodes are well-provisioned with enough RAM, CPU, and bandwidth.
Our Kubo repo folder size is 1.5GB, hosting around 12,000 pinned files.
We have this enabled:
“AcceleratedDHTClient”: true

Attached at the bottom is the full config file sans the sensitive details.

We notice variable results when loading our files (images) via different services. Some are really quick, while for others, it takes many minutes - but they do succeed eventually.
We would like to improve the speed at which new content is discovered by other services from our nodes.

I assume that by paying multiple hosting services and redundantly uploading (pinning) to all of them, we could improve the loading speed.
That, however, goes against the idea of decentralization and hosting your own nodes.

Please suggest any way that we could solve this issue.

Also, a few questions:

  1. Would peering asymmetrically with the service providers (i.e., nft.storage, Cloudflare, Pinata) help?
  2. Would adding more nodes on our side help (current nodes are barely utilized)?
  3. Is there anything in the Kubo config file that may help?

Thanks in advance for any suggestions or help.

Sincerely,
Michael

[---------------------kubo config start---------------------]
{
“Identity”: {
“PeerID”: “”,
“PrivKey”: “”
},
“Datastore”: {
“StorageMax”: “10GB”,
“StorageGCWatermark”: 90,
“GCPeriod”: “1h”,
“Spec”: {
“mounts”: [
{
“child”: {
“path”: “blocks”,
“shardFunc”: “/repo/flatfs/shard/v1/next-to-last/2”,
“sync”: true,
“type”: “flatfs”
},
“mountpoint”: “/blocks”,
“prefix”: “flatfs.datastore”,
“type”: “measure”
},
{
“child”: {
“compression”: “none”,
“path”: “datastore”,
“type”: “levelds”
},
“mountpoint”: “/”,
“prefix”: “leveldb.datastore”,
“type”: “measure”
}
],
“type”: “mount”
},
“HashOnRead”: false,
“BloomFilterSize”: 0
},
“Addresses”: {
“Swarm”: [
“/ip4/0.0.0.0/tcp/4001”,
“/ip6/::/tcp/4001”,
“/ip4/0.0.0.0/udp/4001/quic-v1”,
“/ip4/0.0.0.0/udp/4001/quic-v1/webtransport”,
“/ip6/::/udp/4001/quic-v1”,
“/ip6/::/udp/4001/quic-v1/webtransport”
],
“Announce”: [
“/ip4/157.XXX.XXX.XXX/tcp/4001”
],
“AppendAnnounce”: ,
“NoAnnounce”: [
“/ip4/10.0.0.0/ipcidr/8”,
“/ip4/100.64.0.0/ipcidr/10”,
“/ip4/169.254.0.0/ipcidr/16”,
“/ip4/172.16.0.0/ipcidr/12”,
“/ip4/192.0.0.0/ipcidr/24”,
“/ip4/192.0.2.0/ipcidr/24”,
“/ip4/192.168.0.0/ipcidr/16”,
“/ip4/198.18.0.0/ipcidr/15”,
“/ip4/198.51.100.0/ipcidr/24”,
“/ip4/203.0.113.0/ipcidr/24”,
“/ip4/240.0.0.0/ipcidr/4”,
“/ip6/100::/ipcidr/64”,
“/ip6/2001:2::/ipcidr/48”,
“/ip6/2001:db8::/ipcidr/32”,
“/ip6/fc00::/ipcidr/7”,
“/ip6/fe80::/ipcidr/10”
],
“API”: “/ip4/192.168.100.37/tcp/5001”,
“Gateway”: “/ip4/127.0.0.1/tcp/8080”
},
“Mounts”: {
“IPFS”: “/ipfs”,
“IPNS”: “/ipns”,
“FuseAllowOther”: false
},
“Discovery”: {
“MDNS”: {
“Enabled”: false
}
},
“Routing”: {
“AcceleratedDHTClient”: true,
“Routers”: null,
“Methods”: null
},
“Ipns”: {
“RepublishPeriod”: “”,
“RecordLifetime”: “”,
“ResolveCacheSize”: 128
},
“Bootstrap”: [
“/dnsaddr/bootstrap.libp2p.io/p2p/QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb”,
“/dnsaddr/bootstrap.libp2p.io/p2p/QmcZf59bWwK5XFi76CZX8cbJ4BhTzzA3gU1ZjYZcYW3dwt”,
“/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ”,
“/ip4/104.131.131.82/udp/4001/quic-v1/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ”,
“/dnsaddr/bootstrap.libp2p.io/p2p/QmNnooDu7bfjPFoTZYxMNLWUQJyrVwtbZg5gBMjTezGAJN”,
“/dnsaddr/bootstrap.libp2p.io/p2p/QmQCU2EcMqAqQPR2i9bChDtGNJchTbq5TbXJJ16u19uLTa”
],
“Gateway”: {
“HTTPHeaders”: {},
“RootRedirect”: “”,
“PathPrefixes”: ,
“APICommands”: ,
“NoFetch”: false,
“NoDNSLink”: false,
“DeserializedResponses”: null,
“DisableHTMLErrors”: null,
“PublicGateways”: null,
“ExposeRoutingAPI”: null
},
“API”: {
“HTTPHeaders”: {}
},
“Swarm”: {
“AddrFilters”: [
“/ip4/10.0.0.0/ipcidr/8”,
“/ip4/100.64.0.0/ipcidr/10”,
“/ip4/169.254.0.0/ipcidr/16”,
“/ip4/172.16.0.0/ipcidr/12”,
“/ip4/192.0.0.0/ipcidr/24”,
“/ip4/192.0.2.0/ipcidr/24”,
“/ip4/192.168.0.0/ipcidr/16”,
“/ip4/198.18.0.0/ipcidr/15”,
“/ip4/198.51.100.0/ipcidr/24”,
“/ip4/203.0.113.0/ipcidr/24”,
“/ip4/240.0.0.0/ipcidr/4”,
“/ip6/100::/ipcidr/64”,
“/ip6/2001:2::/ipcidr/48”,
“/ip6/2001:db8::/ipcidr/32”,
“/ip6/fc00::/ipcidr/7”,
“/ip6/fe80::/ipcidr/10”
],
“DisableBandwidthMetrics”: false,
“DisableNatPortMap”: true,
“RelayClient”: {},
“RelayService”: {},
“Transports”: {
“Network”: {},
“Security”: {},
“Multiplexers”: {}
},
“ConnMgr”: {},
“ResourceMgr”: {}
},
“AutoNAT”: {},
“Pubsub”: {
“Router”: “”,
“DisableSigning”: false
},
“Peering”: {
“Peers”: null
},
“DNS”: {
“Resolvers”: {}
},
“Migration”: {
“DownloadSources”: ,
“Keep”: “”
},
“Provider”: {
“Strategy”: “”
},
“Reprovider”: {
“Strategy”: “pinned”
},
“Experimental”: {
“FilestoreEnabled”: false,
“UrlstoreEnabled”: false,
“Libp2pStreamMounting”: false,
“P2pHttpProxy”: false,
“StrategicProviding”: false,
“OptimisticProvide”: false,
“OptimisticProvideJobsPoolSize”: 0
},
“Plugins”: {
“Plugins”: null
},
“Pinning”: {
“RemoteServices”: {}
},
“Internal”: {}
}
[---------------------kubo config end----------------------]

2
  1. Don’t peer asymmetrically, it causes problems (and won’t really help). Symmetric is ok, and might help, but good luck getting the other side to agree.
  2. It can, but if your two nodes are properly configured, reachable and doing a good job of reproviding, it won’t make a whole lot of difference. Having nodes in various parts of the world can be a good idea though.
  3. there’s one obvious mistake in your file that is hurting you some, yes. Move the contents of Swarm.Announce to Swarm.AppendAnnounce, and add the two UDP addresses (make sure the firewall allows UDP as well). That will make some difference.

The real problem isn’t you, it’s the services you are testing with. They are the ones that suck, in various ways. If you were to test with your own node (an extra one, somewhere in the world), you would discover that it would get your content very quickly.

Now, it’s not always their fault, they are just hammered by far more traffic than they can handle, and that’s often the only reason they are slow to do anything. But, other times, it’s that they either don’t use the DHT for lookups, or only use it as a last resort, after trying everything else. Until they change (and they won’t), your content will always be slow with them, and there’s really nothing you can do about it (other than re-pinning your content with them, that is).

3

Hi Yves!
Thank you so much for your answer.
Indeed, while waiting for an answer I noticed the missing UDP announce as well.
Would that be ok to use something like below in Announce, instead of AnnounceAppend. As I prefer more control over this… I noticed otherwise localhost is getting announced as well.

  "/ip4/XXX.XXX.XXX.XXX/tcp/4001",
  "/ip4/XXX.XXX.XXX.XXX/udp/4001/quic-v1",
  "/ip4/XXX.XXX.XXX.XXX/udp/4001/quic-v1/webtransport"

Thanks,
Michael

4

I assumed that your nodes were on the same local network and would use local addresses to communicate with each other, which you were not announcing. If that’s not a concern, you can keep the lines in announce. The main issue was the missing quic information.

5

Thank you @ylempereur . I can see how peering the nodes over the private net can make sense. Will do it in the future.
I’m satisfied that our kubo nodes are now configured in best way possible.
My main concern was about discovery and loading from third parties. I guess we’d need to pin on those third party services, at least new content (which we can also unpin later, given that our nodes keep serving it forever).