"Be careful with mutexes" is good advice, but I'm surprised it doesn't explicitly call out the various channels that tokio provides as alternatives (detailed here: <a href="https://docs.rs/tokio/latest/tokio/sync/index.html" rel="nofollow">https://docs.rs/tokio/latest/tokio/sync/index.html</a>). There are a variety of options that fit different use cases, and you don't even need to enable the runtime feature to use them (e.g. if you want to do a single check for completion rather than await). I'd estimate that at least half of the bottlenecks I've seen with mutexes when using tokio could have been avoided by not even using a mutex at all and instead passing the data that's truly needed across different tasks with some type of channel.<p>The other trick I've used a few times that's a bit hacky but can get the job done is when reading a snapshot of the data under a mutex is enough without needing to prevent other changes; if that's the case, you can just clone the data and drop the mutex to allow other uses move forward at the cost of the data potentially being stale.
Tasks and channels is the way. You can get something that feels like programming a real preemptive concurrency model like BEAM languages or golang but with minimal overhead.
(I am OP) Both good call outs. Will update the article to include them
For a true high performance you should use thread busy-spinning, CPU pinning and SPSC/MPSC ring buffers.
It all depends on what you are doing. I do embedded with strict realtime requirements. CPU pinning would not be an option. I have also done software that should use as little resources as possible (but still be quick) to coexist with other software on the same hardware.<p>All of these are different, valid, meanings of high performance. You need context. An interactive IDE is yet another thing that needs to be high performance in yet another way.
[dead]
When you're at a point of tuning Tokio, consider taking a look at ef_vi/DPDK + SPDK
I don't think there is a ton of overlap. tokio is appropriate for general userspace apps, ranging anywhere from a CLI, GUI, API or web app. DPDK and SPDK are specialized fast paths for building network data paths and storage solutions that come with tradeoffs: DPDK uses poll mode drivers, outside of the operating system, which have various implications including busy waiting and taking over the interface. That is why DPDK is fast, no kernel/userspace context switching and copies, and the drivers are tuned for the polling model. But it's not a general purpose building block.
Fwiw with ef_vi you have full control over the event queue - you don't need to busy-spin it, you can choose whatever strategy you prefer.<p>> tokio is appropriate for general userspace apps<p>Yep, and for those I wouldn't recommend it. But tokio is also widely used in performance-critical infrastructure and web services. For those I'd say it can definitely be worth taking a second look at kernel bypass.
Do you have any resources worth referencing on this? I assume this isn't something that works with tokio more of a replace tokio?
One great use of agentic coding is being able to add and very granular tracing instrumentation to help with these sort of optimizations.
Fast Tokioo, drift, drift, drift!
All of the significant server applications I have encountered in the industry have suffered from the same problem, which surprised their authors but seemed obvious to me: the application was spending the majority of its CPU time doing meta-work like entering and leaving epoll, stealing work from itself, etc. There are principles for writing Tokio servers and these are good points in the OP but I think they are little-known and too easy to violate.
I can't say I'm surprised when I see the 100+ function stack traces that Axum built on Tokio produces.<p>Before you say Axum is "holding it wrong" the project lives under the tokio-rs GitHub org.
Do you have any references for these principles for writing Tokio servers? Or just a high level summary of what best practices look like?
What the hell is Tokio? Articles mentions it like once
I was expecting some programing principles from Japan
[flagged]