litep2p/kad: Configure periodic network bootstrap for better throughput #4942
Conversation
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
lexnv
added
A1-insubstantial
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
| /// Number of connected peers over the block announce protocol. | ||
| /// | ||
| /// This is used to update metrics and network status. | ||
| num_sync_connected: Arc<AtomicUsize>, |
There was a problem hiding this comment.
Looks like a metric that should be moved to the sync crate.
There was a problem hiding this comment.
Yep that sounds good, have created an issue for this:
Since this was a bit involved for the peerstore metrics :D
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
|
Is the algorithm the same as what |
| @@ -439,6 +441,9 @@ impl<B: BlockT + 'static, H: ExHashT> NetworkBackend<B, H> for Litep2pNetworkBac | |||
| let peer_store_handle = params.network_config.peer_store_handle(); | |||
| let executor = Arc::new(Litep2pExecutor { executor: params.executor }); | |||
|
|
|||
| let limit_discovery_under = | |||
| params.network_config.network_config.default_peers_set.out_peers as usize + 15; | |||
There was a problem hiding this comment.
What happens if in_peers is lower than 15?
Do you think the discovery should be guided by the number of sync peers connected, and not by the number of known peers?
Also, I would make sure we do a random walk at least once per minute as it was before, even if we have enough peers connected (make discovery_only_if_under_num slow down queries, but not stop them completely).
|
Nice catch indeed, we can remove the limit under config. The extra load on the network should be negligible and at the same time remove some extra logic from our code. Initially, I used sync peers but can't remember why I transitioned to what libp2p is doing. After I make the adjustemt and remove the limit, I think we'll have the benefit of not waiting for slow queries to finish before starting a new one. This should be a bit better than before, we could keep the PR around until we find the root cause (also think its safe to merge but lets be extra sure here) 👍 A few ideas to tackle this next:
|
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
…er number" This reverts commit b6c9901.
This is mainly done to keep a healthy subset of the network in the node's memory and routing table. Otherwise, we may risk trading off discoverability with protocol performance, which is not entirely desirable. Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
lexnv
changed the title
|
I changed the algorithm for kademlia discovery from litep2p side to:
The main goal was to improve the network throughput as discussed in this forum post. Will provide some more details about performance in a bit, however short-term 6-8h data looks extremely promising. Offhand, it looks like we were performing too many KAD queries, leading to a more dynamic view of the network. In terms of consuming resources to dial, submit queries, handle responses, peer evictions from the routing table etc |
This PR modified the periodic network bootstrap process (submitting kad
FIND_NODEcommand with random peerIDs) to improve the number of connected peers:The old behavior:
For my full node started in Kusama, I observed that queries finish under 1 minute.
What I expect is happening for a long running node:
Testing Done
Started 2 nodes with
--in-peers 50 --out-peers 50:Part of:
cc @paritytech/networking