Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Try switch sockets to tokio #5762

Closed
tomaka opened this issue Apr 23, 2020 · 5 comments · Fixed by #12646
Closed

Try switch sockets to tokio #5762

tomaka opened this issue Apr 23, 2020 · 5 comments · Fixed by #12646
Assignees
Labels
J0-enhancement An additional feature request. Z1-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder

Comments

@tomaka
Copy link
Contributor

tomaka commented Apr 23, 2020

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.

@tomaka tomaka added the J0-enhancement An additional feature request. label Apr 23, 2020
@tomaka
Copy link
Contributor Author

tomaka commented Apr 24, 2020

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.
EDIT: to be clear, I purposefully didn't update the node in any way other than applying this diff, so that the measurement isn't influenced by anything else.

Note that I suspect that #5767 might be way more impactful.

@tomaka
Copy link
Contributor Author

tomaka commented Apr 24, 2020

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):

Screenshot from 2020-04-24 18-17-08

(the peak is when I restarted the node)

Here is the average time it took to poll a future dedicated to a libp2p node:

rate(polkadot_tasks_polling_duration_sum{task_name="libp2p-node"}[20m]) / (polkadot_tasks_spawned_total{task_name="libp2p-node"} - polkadot_tasks_ended_total{task_name="libp2p-node"})

Screenshot from 2020-04-24 18-17-37

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.

@tomaka tomaka added the Z1-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder label May 3, 2021
@stale
Copy link

stale bot commented Jul 7, 2021

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.

@stale stale bot added the A5-stale Pull request did not receive any updates in a long time. No review needed at this stage. Close it. label Jul 7, 2021
@tomaka
Copy link
Contributor Author

tomaka commented Jul 8, 2021

Issue still important for historical context.

@stale stale bot removed the A5-stale Pull request did not receive any updates in a long time. No review needed at this stage. Close it. label Jul 8, 2021
@dmitry-markin
Copy link
Contributor

Done in #12646.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
J0-enhancement An additional feature request. Z1-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder
Projects
No open projects
Networking (Outdated)
  
Awaiting triage
Development

Successfully merging a pull request may close this issue.

2 participants