Is IPFS supposed to be this slow?

[whydna]

I setup a test with 2 computers on separate networks, and on each of them I'm running an IPFS node inside the browser.

On computer A, I did a ipfs.add(<video_file>) and then I pin the file.

On computer B, I do an ipfs.cat(<video_hash>) and then load it into a video player.

But it is unusably slow - videos that are a few seconds long can take minutes to load, and videos that are a few minutes long can take an hour to transfer.

Is this expected? I make sure to keep both nodes running, so it should have a node to seed the file from. What's taking so long?

[alanshaw]

Hey @whydna, no it shouldn't be unusably slow. It could be due to a number of factors though. Can you share your node configuration so we can diagnose?

[whydna]

@alanshaw Thanks for your response!

You can see the code here: https://gist.github.com/whydna/087916b1ba88da8a2f1df9b8e92ff365

It's a simple 1-page React app. When user selects a file, it calls add().

When someone loads the page with a hash in the URL it calls cat() and pin(), and then loads the contents of the file into a video player.

You can also play with the app here: https://streamzor-abb39.firebaseapp.com

[whydna]

@alanshaw any ideas?

[wehriam]

@whydna - See #2161 and #1307

[suutaku]

same issue, any update??

[alanshaw]

Hey, apologies for the lack of updates - I haven't had a moment to look into this.

One thing I can inform you about is that there's a big refactor landing soon in libp2p which will change the performance characteristics (hopefully for the better 🤞) so unless you need speed ups asap then it might be better to wait for that to land.

That said, if you have the time and inclination to look into this then please do! There's always the possiblity any issue you come across has been reproduced in the refactor so it won't be wasted effort.

I'll try and revisit this issue after the refactor lands to ensure this gets resolved.

[suutaku]

do my best.

[sebastiendan]

Can we have an update on this? It's been a while and new go-ipfs and js-ipfs versions have been released, yet I also find both clients unusable for two nodes that do not know each other.

I find a lot of slow performance issues everywhere but there's no clear response to this question: can today a random node on earth cat or ls a hash from a custom file another totally unrelated node added elsewhere, right before?

[achingbrain]

Yes, if the network conditions are favourable. That is they can locate the content each one is making available and they can then either make a direct connection or via a content router to transfer that content.

This means having some common means of discovery configured.

Have you used the latest js-ipfs - v0.48.0 release yesterday? It's got delegate routing configured by default so you should be more well connected to the network - I'm regularly seeing 2/3x more swarm peers than before.

[sebastiendan]

No I haven't tried v0.48.0, but I assume more swarm peers won't necessarily fix the content delivery. Shouldn't the content discovery mechanism work with any network conditions? Shouldn't looking for content providers through the DHT work in a reasonable time period even if both nodes are just joining the network - meaning they are only connected to a very small amount of peers?

Delegate routers peform tasks on behalf of nodes that may be missing functionality, so for example they may search the DHT for peers or content providers on behalf of IPFS implementations that do not have a DHT.

Which IPFS implementation does not have a DHT?

[onichandame]

Still unusably slow on browsers with the latest js-ipfs. But using go-ipfs through REST API is not too slow. Just reporting the observation as I don't know much about the implementation details.

[thotheolh]

Same issue here. I have a node setup and I have uploaded a 70 kb test file and generated a shared link from the GUI and attempted to open it in my own web browser and it takes a long load time.

Some information on my setup.
AGENT: go-ipfs v0.7.0
UI: v2.11.4

Current peers at 500+ peers and it's still very slow.

[whydna]

Also, does anyone know why the browser node maxes out at 4 peers?

[oinuar]

Still experiencing slowness in 0.55.2. My setup is similar: I have a go-ipfs node where I add files and another js-ipfs node that runs in browser's service worker which cat the added files. There is a huge lag before the added files even become available to js-ipfs.

I am just wondering what could be done to speed things up? But I realize that I don't understand the protocol well enough to really understand why there is the lag in the first place. I think it has something to do with web browser limitations or maybe the node configuration can be tweaked.

• I have tried to directly link js-ipfs to go-ipfs node by enabling WebSockets in go-ipfs and adding the node to js-ipfs's Addresses.Swarm config, but it is unclear to me if that succeeded or not because I did not experience any difference and did not get any error message. If I manually create a WebSocket connection to go-ipfs, it establishes it successfully. However, I don't see browser's network tab any activity that js-ipfs is trying to even connect to it.
• I tried to setup my own rendezvous server where all my nodes could connect to, to help them to discover content more quickly. I built a Docker image from https://github.com/libp2p/js-libp2p-webrtc-star and started the server. Made a Docker port forwards and added the server address (/ip4/127.0.0.1/tcp/9090/wss/p2p-webrtc-star) to js-ipfs's Addresses.Swarm config, but I keep getting "Error: no WebRTC support". I think this is because my node is running in a service worker.

My use case is quite simple: it is acceptable for me to directly connect to go-ipfs node since that is the node where I add the files. In that case I could just use ipfs-http-client and connect to go-ipfs node directly. However, I would love to benefit from IPFS's decentralized nature by off-loading some the content distribution workload to js-ipfs nodes where my actual app is running on. Could somebody help me a bit by explaining what causes the lag of file availability and what could be done to speed it up? Thank you so much for the very awesome library so far!

[LoreBadTime]

same issue here, if i try to download a file from another pc it takes ages, local download and upload works normally

[wangpin34]

same issue here, if i try to download a file from another pc it takes ages, local download and upload works normally

So do I.

[fabiooshiro]

same issue here, if i try to download a file from another pc it takes ages, local download and upload works normally

So do I.

+1

[nft-legends]

IPFS is NOTHING like Azure Storage or Amazon Buckets.. It's SLOW, doesnt respond, cant find my content, unreliable.. I hate it..

[achingbrain]

You are quite correct, IPFS is not like Azure Storage or Amazon S3. Those are centralised systems, IPFS is decentralised which means it has a very different set of constraints.

If you cannot resolve a piece of content, have you tried using https://ipfs-check.on.fleek.co/ to see if it's actually available on the network? If it's not, you're not going be able to find it.

I think this issue has run it's course and is no longer helpful.

If you need help with getting IPFS to work, diagnosing a network problem or just with trying to understand how it all works, please post on https://discuss.ipfs.io/ - if you find an actual, actionable bug that requires a fix, please open an issue here with clear instructions on how to reproduce the problem you are seeing.

[casey]

You are quite correct, IPFS is not like Azure Storage or Amazon S3. Those are centralised systems, IPFS is decentralised which means it has a very different set of constraints.

One thing that might be good to note is that BitTorrent is also decentralized, however it is much much faster.

[kimgysen]

I'm just randomly reading pages with info on IPFS to see if it's something worth learning. Reading this thread doesn't motivate me very much. Can't tell me that it's still unusably slow after 3 years. Priorities maybe?
Don't want to sound rude but my untuïtive reaction is yeah bye... gonna spend my time studying something else.

[johnwwk]

IPFS is NOTHING like Azure Storage or Amazon Buckets.. It's SLOW, doesnt respond, cant find my content, unreliable.. I hate it..

I 100% agree with this and I also genuinely hate it. And I am telling this after using it in projects for 2 years. No one wants this -so called- decentalisation if it will be 10 times slow than any centralized solution. We have to hold replicas of ipfs data in mongo just to get them in normal times. This is pathetic and absolutely not Web3.

[liam-ot]

I am using IPFS to build an NFT application (yes very original I know lol) but in my experience IPFS works well and while it is not yet as quick as AWS S3, or comparative Web2 infrastructure providers, it is certainly not "unusably slow"

I would say on average when uploading a file to ipfs then using the brave browser to go to ipfs://{cid} (so using different nodes) it takes about 30 seconds max to load

For those complaining about slowness, have you considered starting up your own nodes? It would considerably speed up the network latency and increase the usability of the network, rather than just complaining!

Thanks to those at IPFS for helping build the decentralised future "no one wants" ;)