IPFS running on RPi + Cloudflare IPFS gateway super slow

Help
1

Hi, I’m hosting some files in a Raspberry Pi 3 and trying out IPFS.

I’ve setup a Cloudflare IPFS gateway for a subdomain and run the deamon in the RPi.

CNAME    ipfs.grondtrack.space             ipfs.cloudflare.com
TXT      _dnslink.ipfs.groundtrack.space   "dnslink=/ipns/k51qzi5uqu5dlkcvrhwnye8x0cgv3m6g8nb7lh8etwnmkf9mdrfw7zk78h2yh0"

I created a key (named www) to use for IPNS. Everytime I want to publish a new version, I do,

pi@raspberrypi:~ $ ipfs name publish --key=www $(ipfs add -Qr www)
(www is also a folder that contains the files)

However, discovery and content fetch is super slow, until it gets cached in Cloudflare.
ipfs.io gateway generally timeout! (using both /ipfs/<root-cid> and /ipns/<www-peer-id-or-domain>)

My guess is, following the installation, I run init using the lowpower profile (and that’s what I’d prefer). I read some documentation on this profile, and it sets DHT as client only (my CIDs are not announced to the DHT?), and Reprovider 0.

I wonder how Cloudflare (sometimes) is able to fetch my content even if IPFS deamon is set to dhtclient. How could I improve discovery and content initial fetchs for this scenario?

Tried updating my Reprovider config and restarted the daemon, but ipfs.io and Cloudflare keeps giving timeout, and sometimes finds it but takes like 15s and several page refreshes. Then it gets cached and there’s no problem for a while (until cache gets invalidated).

1 Like
3

Wow, lots to unpack. I’ll go in order:

There are two kinds of IPNS, DNS based and public key based. They both serve the same purpose. DNS is pretty fast, but public key lookups are slow (by design, it has to wait a while to make sure it has received the latest version, not an old one).

Your first issue is that you are using both in a chain. While functional, it’s unnecessary and slow. Pick one. I would use the DNS based, since you set it up already, and just set your dnslink to the direct ipfs address (not the other ipns one). That will speed up the lookup dramatically. And yes, it means you have to update your dnslink every time you make an update.

Next, ipfs.io and cloudflare are both slow. The former used to be fast, and is only meant to be a test server. However, everyone decided to use it as their free to use production server. It’s overwhelmed now, and barely moves. The latter has always been slow, not sure why. Bottom line, don’t use either, there are many other gateways you could use (or set up your own).

Next, your node will make your pins available to the network whether it’s running in dhtserver or dhtclient mode, it doesn’t matter (as long as it’s actually running. don’t turn it off). In dhtserver mode, your node also helps the dht system (for others, it doesn’t really help you). Only run it in dhtserver mode if you run your node 24/7, have enough cpu power and ram, and have a lot of bandwidth.

Don’t turn off your reprovider, your node will still serve your pins, but it will stop telling the DHT about them on a regular basis, so no one will be able to find them. DHT records survive for 24 hours, but a reprovide only stores the records in 20 nodes, and the network has a lot of churn, so most of those 20 will go offline before the 24 hours are up. For that reason, your node rewrites those 20 nodes every 12 hours (the default has changed now, it’s longer, like 22 hours). Due to the churn, my own records would often disappear much earlier than 12 hours, so I set mine to 6 hours. It seems fine now.

Finally, if your node pins more than a handful of blocks, you need to set AcceleratedDHTClient to true, or your reprovide cycle will take far longer than 24 hours (days).

I hope all this helps.

1 Like
4

Thanks @ylempereur for the detailed response. I’ve updated my config, set reprovider to 6h and strategy pinned. I’ll try out updating the _dnslink TXT record to point to the ipfs CID directly instead of the ipns one, that might speed things up too.

Maybe this can help too? Peering with content providers | IPFS Docs, that seems to keep connections with Cloudflare nodes, but not sure if it makes more sense to help my RPi fetch other content through Cloudflare, or to help my content inside my RPi to be fetched by Cloudflare nodes, or both?

5

While that could help you a little bit (maybe, they have a lot of nodes), you really shouldn’t peer with a node that isn’t peering with you as well. For example, I run two nodes, and they each peer with the other one. That leads to a stable connection between the two. However, one way peering can lead to two problems: first, a node should be able to decide what connections it wants to keep at any time, so if the remote node wants to get rid of you, you keep redialing, which leads to the connection going up and down constantly. second, if many people decide to do it to the same node, that sort of thing turns into something like a ddos attack on it, and is really detrimental to its health.

1 Like