What is the reason for very slow

[voxsoftware]

Version information:

go-ipfs 0.4.20

• I go to a machine with go-ipfs 0.4.20 and execute ipfs add xxxxx (a file with 20MB), i got the hash
• I go to another machine, use the HTTP gateway with the hash, the request hangs, more than 36 minutes without still can access to uploaded file

What is the reason for this?

[voxsoftware]

I tested the same happens with orbit-db if I try initiate database on nodejs app with remote address (using http client) hangs (but openning in browser works). What is the reason of this really really slow ?

[jasonzhouu]

I think the latency is mainly resulted from low performance of DHT resolving.

Recommend to read the performance test:
#5226 (comment)

This test take place in July 2018
In Mar 2019, @Stebalien said:

The situation has significantly improved
#5226 (comment)

[voxsoftware]

Just now 5 hours later, still cannot access to hash from other machine

[Stebalien]

@jasonzhouu that's a different issue. The issue here is about finding content. The issue there is about receiving the same block multiple times. While that's still an issue, it no longer scales linearly with the number of peers that have the block.

---

@voxsoftware

The gateway may not be able to reach your node. However, the issue is likely content routing (i.e., using the DHT to find who has the content). Unfortunately, this is currently really slow as the DHT is full of unreachable peers behind NATs.

See: libp2p/go-libp2p-kad-dht#216

[Stebalien]

Closing as this isn't directly actionable. Feel free to continue asking followup questions.

[jasonzhouu]

@Stebalien
There are 2 kinds of test in #5226 (comment) :

• latency test
• duplicate blocks test

The issue here is basically a latency issue

[voxsoftware]

@Stebalien my node is online. I tested with other files, on node and works some times. But other times like this, hangs for many many time. Really the problem is not related to node because is my own node, in a machine with 0 latency.

In other words: I have two nodes, i uploaded from one node, and go to other node to download using gateway. With some files, works good, like as expected and other times, like this example of 20MB, hangs for many many time. I hope that now is explained correctly

So, if you close this issue, you are ignoring a big issue

[voxsoftware]

@jasonzhouu latency more than one hour?

[voxsoftware]

I consider acceptable 5 minutes, but more than 20 minutes, is unusable. If I need have some requirenments on nodes where I uploaded please say me, because I cannot believe that this happens

[voxsoftware]

Another aclaration, for this tests, I am using vps on dedicated servers, with 100% internet all time and without firewalls, and really I don't understand, what is happening

[jasonzhouu]

@voxsoftware

latency more than one hour?

yes, and this is a big issue that long exist in IPFS

[Stebalien]

@jasonzhouu IIRC, those tests are all about duplicate blocks in a closed test network. I can't find anything on that thread about finding content, latency, etc.

---

@voxsoftware

So, if you close this issue, you are ignoring a big issue

I'm sorry, I realize I wasn't clear on this. This issue is very much valid and we're working on it as fast as we can.

I closed this report simply for tracking purposes. This isn't something that can simply be fixed or implemented and leaving a bunch of vague "ipfs is slow" issues open just clutters the issue tracker. Worse, these issues tend to turn into a mess of multiple issues as other users jump in and start reporting unrelated performance issues.

However, looking through the issue tracker, I can't find a decent meta-issue for this. I'm going to create one now.

[jasonzhouu]

@Stebalien

Maybe I should use the word delay, instead of latency

[Stebalien]

@jasonzhouu The comment associated with that graph is:

IPFS performance deteriorates as the number of nodes increases. This is due to the increasing number of duplicate blocks. This is happenning due to the current Bitswap implementation.

That issue has been (mostly) fixed. At the time, go-ipfs was asking every connected peer for every block of data instead of asking different peers for different blocks. If 10 peers had a single block, go-ipfs would fetch the block from all 10 peers and take 10x longer to do so as it was downloading 10x the amount of data.

The delay there is the delay in fetching the entire file.

---

@voxsoftware I've filed a meta issue (#6383) to try to explain what's going on here and why.

[voxsoftware]

If this is relevant, i want say that just now I tested, and I can access to file from my other node, almost one day later.

[Stebalien]

If this is relevant, i want say that just now I tested, and I can access to file from my other node, almost one day later.

I've heard this before and that is kind of odd. I wonder if the initial attempt to tell the network you have the content failed but a subsequent request succeeded.