Open lexnv opened 2 months ago
lexnv
commented
2 months ago This may free up some litep2p resources:
Based on comment litep2p handles considerably more connections.
Might also be the cause of a lower networking bytes sent:
lexnv
commented
1 month ago After implementing connection limits in litep2p:
| Stage | litep2p | libp2p |
|---|---|---|
| Warp Sync | 6m 38s | 18m 35s |
| State Sync | 4m 10s | 1m 58s |
| Total Sync Time | 10m 48s | 20m 33s |
Based on origin/master at ce6938ae92b.
After implementing connection limits, we have effectively improved the sync time with around 50%, from 16m 24s to 10m 48s.
We are also seeing a regression for libp2p, related to:
In the current state of things, litep2p is twice is fast as libp2p. Even compared to the previous better libp2p state, we are still 30% faster in syncing.
It is clear we need more performance testing, both for:
(cc @alexggh @sandreim )
dmitry-markin
commented
1 month ago Why are the numbers for libp2p so different? Comparing the first message with this one, warp sync went 8m 27s -> 18m 35s, state sync 5m 30s -> 1m 58s. Are they for the different chains, or the measurements are just noisy? (The same might apply for litep2p.)
lexnv
commented
1 month ago It could be some noise for sure. I've synced to kusama both nodes, believe I've used the same params here
We could double check using more data points, and probably improve https://github.com/lexnv/sub-triage-logs/ to do this for us.
litep2p
Libp2p
Data points
litep2p warp sync: 14:06:42.414 - 14:16:34.688 = 9m 52s libp2p warp sync: 14:07:27.569 - 14:15:54.968 = 8m 27s
litep2p state sync: 14:16:34.688 - 14:23:06.679 = 6m 32s libp2p state sync: 14:15:54.968 - 14:21:24.293 = 5m 30s