Comments (3)
I agree it's not ideal, but our experiments indicated that joining the main network (which as I understand is still currently the only way to have a single daemon) substantially decreases performance.
I haven't profiled IPFS to know where the baseline resource usage is coming from, but if it's from maintaining connections and discovering peers, I'm also a little skeptical of a unified IPFS daemon (which is what I presume the go-ipfs-daemon
comment in the linked thread is about) wouldn't either decrease performance, or end up with roughly the same resource usage as independent IPFS daemons, since the peers/connections radicle IPFS wants are ultimately a largely disjoint set from the rest of IPFS. (E.g., radicle doesn't need to know about DHT items for anything that's not radicle related, and for the most part won't retrieve IPFS data from anything that wasn't put there by another radicle instance.)
from radicle-alpha.
I agree it's not ideal, but our experiments indicated that joining the main network (which as I understand is still currently the only way to have a single daemon) substantially decreases performance.
That is interesting & worth discussing & investigating in that other thread. I presume you mean that radicle becoming slower at propagating changes because node is busy doing other stuff. If so it seems like a IPFS needs to get better at resource management and prioritize active tasks submitted by clients rather over whatever else is doing while being conceptually idle.
I haven't profiled IPFS to know where the baseline resource usage is coming from, but if it's from maintaining connections and discovering peers, I'm also a little skeptical of a unified IPFS daemon (which is what I presume the go-ipfs-daemon comment in the linked thread is about) wouldn't either decrease performance, or end up with roughly the same resource usage as independent IPFS daemons, since the peers/connections radicle IPFS wants are ultimately a largely disjoint set from the rest of IPFS. (E.g., radicle doesn't need to know about DHT items for anything that's not radicle related, and for the most part won't retrieve IPFS data from anything that wasn't put there by another radicle instance.)
If unified daemon performs worse than separate peers it implies a sub-optimal resource management & is worth figuring out. Truth is is if I have multiple IPFS nodes each comes with own overhead so collectively they make my machine perform more poorly.
I think your remark on disjoint pen sets is a good point, however as (and if) IPFS gains more adoption that may not be true. Chances are that peers I'm collaborating with are also the peers I'm interacting with my textile app and in the future and drafting roadmaps on https://anytype.io/. Furthermore it would be far more convenient if all of that was mirrored by the same server peer which seems more straight forward with single node than on per app basis.
Anyway I started all this issues to start the conversation across groups in a hope to identify goals & constraints and attempt to converge to some reasonable plan to improve things.
from radicle-alpha.
I might be mistaken, but the performance issues seemed mainly around IPNS and PubSub, not data replication.
from radicle-alpha.
Related Issues (20)
- error in 'Version' field string 'v0.0.3': version number does not start with digit HOT 3
- Import should fail if a symbol isn't defined
- How can I uninstall `radicle`? HOT 4
- Pattern matching evaluation considerations
- Pubsub reconnect backoff
- Can't build with nix on OS X due to missing glibcLocales HOT 2
- rad issue list (pipe) HOT 1
- Multiple loads of modules should cause an error message
- Refactor items.rad
- Arbitrary instance for Value is way out of date.
- Federation with ForgeFed HOT 4
- ERROR Timeout communicating with IPFS daemon on rad daemon-radicle --debug HOT 2
- symlink to rad-repl doesn't exist
- Roadmap HOT 2
- Does it unpacks git objects? Also, it doesn't compresses when pushing? HOT 1
- Why to use LISP? HOT 1
- Support 32bit HOT 1
- Distributed code reviews HOT 1
- A more approachable issue format HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from radicle-alpha.