-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow transfer on localhost #6442
Labels
kind/bug
A bug in existing code (including security flaws)
P1
High: Likely tackled by core team if no one steps up
regression
Comments
lucasmaheo
changed the title
Slow transfer speed on localhost
Slow transfer on localhost
Jun 12, 2019
Stebalien
added
kind/bug
A bug in existing code (including security flaws)
P1
High: Likely tackled by core team if no one steps up
regression
labels
Jun 12, 2019
Went back to v0.4.20 for now. This seems to fix the issue, but something may arise on other functionalities I guess. |
A likely fix: ipfs/go-peertaskqueue#5 |
Fix in ipfs/go-peertaskqueue#7 |
Stebalien
added a commit
that referenced
this issue
Jun 12, 2019
Merged
Stebalien
added a commit
that referenced
this issue
Jun 13, 2019
Thank you! I was on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
kind/bug
A bug in existing code (including security flaws)
P1
High: Likely tackled by core team if no one steps up
regression
go-ipfs version
ipfs version 0.4.21
I have deployed a small private swarm of IPFS nodes in Kubernetes on a local network (also tried local host with minikube), and
ipfs get
is really slow. My CPU should be able to handle this small load, and transfer using scp between "nodes" is lightning fast.Transfer results
162MB file: 46s (average of multiple tries)
325MB file: 2m41s (also averaged)
Initial
ipfs add
results in 3~4s of hashing.ipfs get
-ing on the node that added the file results in 1s "download"Troubleshooting and ideas
I have tried using
--routing=none
and--routing=dhtclient
to no avail.The gap in transfer time between the two file sizes may indicate it comes from hashing I suppose (the merkle tree must be deeper), but the CPU is not at full capacity.
Any idea what may cause this?
The text was updated successfully, but these errors were encountered: