Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Optimize CountryChart widget on Status Page
See original GitHub issueI am quite sure the moment we ship it officially, someone will ask us this, so let’s be proactive and try to answer why a simple looking Status page in webui:
- makes 1k of requests and fetches around 6MB in about a minute 🙃
- intuitively this feels off for a simple status page
- left open, continues to eat bandwidth at the steady rate:
- ~5 minutes later:
- ~10 minutes later:
- ~5 minutes later:
Size does not concerns me as much as the number of HTTP requests.
Looks like multiple calls to ipfs.object.get happen always after refreshing peer list.
What are we fetching? Is it geodata or something else?
Is there anything we could do about it? Optimize or preload geo data (or use smaller db with countries only)? Throttle the number of parallel API calls? Decrease refresh interval, improve caching? There is a ceiling on how many parallel HTTP requests make sense.
Issue Analytics
- State:
- Created 5 years ago
- Comments:13 (12 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
For me bandwidth usage by IPFS is mostly between 10 kB/s, with long staring sometimes jumping to 500 kB/s, but when I open the webui I start seeing at least 10 Mb/s download traffic which is 1/5 of promised bandwidth and makes sites load slowly and my connectivity not work very well in general.
I had a lot of Firefox tabs open including webui when I noticed this issue, I resolved it by stopping the ipfs daemon entirely and was linked here from #ipfs on freenode.
I am running
--routing=dhtclientas I understood it’s recommended for decreasing bandwidth usage and this node isn’t very useful for being only direcltly reachable over IPv6 and Yggdrasil-network.ipfs version 0.4.18installed withipfs-updateron Debian GNU/Linux testing (buster).looking at this the first thing that jumps out at me is why does the situation not improve after the second run. Is my swarm really changing so much that I’m cache-missing all of the previously resolved things? Then there is the even more surprising issue of, why are content-addressed get requests to the api not just being pulled from the browser cache… well, because the API doesn’t return any cache headers.
There is an issue from 2016: https://github.com/ipfs/go-ipfs/issues/3543
I have a new crusade!