-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Try switch sockets to tokio #5762
Comments
The changes are quite small: https://github.com/paritytech/substrate/compare/master...tomaka:tokio-sockets?expand=1 I've applied this change on my Google Cloud node around 14:25UTC. I'll compare the CPU usage before and after in a couple of hours or tomorrow. Note that I suspect that #5767 might be way more impactful. |
Two hours and 100 connections later, it's not super convincing. Here is the CPU usage, you can't really see a difference (when the usage is on the lower end, ~1/3rd of this is normally the libp2p connections): (the peak is when I restarted the node) Here is the average time it took to poll a future dedicated to a libp2p node:
The moment when the curve almost reached 0 is when I restarted the node. If there is a difference between async-std and tokio, it seems to be lost in the background noise. It's very likely that our number of connections and traffic are not enough for a difference to actually matter. I'll suspend this test unless we find a way to considerably reduce the background noise and have more precise measurements. |
Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions. |
Issue still important for historical context. |
Done in #12646. |
This has been on my TODO list ever since the switch to futures 0.3, and I had unfortunately totally forgotten about it.
While libp2p defaults to async-std because it "just works", tokio is presumably faster than async-std due to the fact that the reactor and executor are using the same threads.
This issue consists in briefly benchmarking the two and see if we see any difference in CPU usage.
The text was updated successfully, but these errors were encountered: