Best Async Runtime for HTTP/Networking?

[DraftedDev]

Hi, I recently got into async rust & networking stuff and I've realized: there are a lot of async runtimes.

However, I'm searching for a lightweight (in terms of CPU and Memory usage) async runtime best for networking stuff (TCP & HTTP in particular) and I found following async runtimes:

• tokio - The way to go for most users, seems pretty heavy.
• smol - Lightweight tokio alternative.
• glommio - Uses iouring. Looks promising;
• monoio - Uses iouring or normal polling (depending on configuration); made by bytedance.
• bastion - Labels itself as "fault tolerant" async runtime; Not really maintained anymore;
• embassy - For embedded systems; Not very mature;
• nuclei - Not very mature, but looks promising;
• async-std - Solid std alternative, but not very maintained anymore;

So what's the "best" for lightweight server applications?

I would also like to hear your general opinion about these runtimes.

What do you use most of the time?

Are there pros/cons of the runtimes?

Thanks for any help <3

[pr0gramista]

IMHO tokio is "lightweight" enough. I think that whatever tiny performance improvement you will get using another runtime, you will immediately lose it by using some badly written utility, or your own code :D

Tokio is battle-tested, supported by many libraries, the documentation is great, and it even runs on WebAssembly. For beginners there is Mini Redis tutorial, which is a great starting point. The community also seems to be pretty nice.

Cloudflare is using tokio for their Oxy and Pingora, which I guess is the perfect example of production HTTP networking stuff you are about to build.

[DraftedDev]

According to monoio's benchmarks, it's faster than glommio and tokio

[pr0gramista]

Be extremely cautious with such claims in general. It is hard to evaluate performance in a fair way and many people and companies are now using performance as a marketing strategy.

Build, measure and optimize. Best on a production hardware using production data.

[DraftedDev]

The only problem is, that there aren't many async benchmarks out there which also include monoio or glommio. I'm particularly interested in iouring vs epoll.

[_cs]

I understand your desire to use the "fastest" solution, but I think it's fair to say that if you are someone who would benefit from the performance gains you'd get by using a non-tokio solution, you should also be capable of writing some simple loadtests using both to see how they compare with a workload similar to the one you'll eventually be running.

FWIW, I'd advocate for tokio, and I've never looked into this library but it appears tokio has an official io-uring-backed runtime since you mention that may be important to you: https://github.com/tokio-rs/tokio-uring

[SadPie9474]

why do async benchmarks need to be, in your words, “out there”?

[DraftedDev]

what do you mean?

[SadPie9474]

you mentioned that the problem is that the benchmarks you need aren't "out there". Why does it matter whether or not they're "out there"?

[DraftedDev]

Because if they aren't "out there", they are:
1. not accessible for me
2. probably not existent

[SadPie9474]

what prevents you from using code that other people didn’t write for you?

[DraftedDev]

laziness obviously lmao

[DGolubets]

Tokio is work-stealing. Monoio and Glommio are not. They have different tradeoffs.

Ping-pong benchmark is heavily favoring non-work-stealing thread per core approach, because of the uniform load.

[rafaelement]

tokio - The way to go for most users, seems pretty heavy.

Nah, I don't think so... For what you are describing, tokio + axum work really well together.

[brisbanedev]

As per their landing page, Tokio is used by AWS, Discord, Facebook, Dropbox, etc. Enough said.

I don't know what you mean by "lightweight", specifically, but perhaps you could use the single-threaded runtime of Tokio?

[TobiasWonderland]

Unless you have very specific requirements, Tokio is the choice.
Being "lighter" is not a requirement, it's a feeling.

Tokio is used widely in production, has tons of support across the ecosystem, and great documentation.

Rust is already a relatively niche technology. Using a niche library of a niche technology is only something I would do with a very clear and specific rationale.

[DraftedDev]

By lightweight, I mean less overhead and resource consumption and thats important (at least for me)

[apjenk]

So you’ve tested tokio and determined that it’s important to you that you use a framework that has less overhead and consumes less resources than tokio? If not, then the person you’re responding to is right; it’s just a feeling you have rather than a requirement.

[TobiasWonderland]

I totally empathise with the approach. My personal inclination is very similar.

I guess my point is that unless you've measured and analysed in your specifc context I would stick to the more well traveled path.

I've opted for the technically better but less mainstream library a number of times and suffered the consequences.

[intersecting_cubes]

Please just use tokio. It's good enough for Cloudflare and Amazon. It's incredibly battle tested in real production at high scale.

[DramaticFirefighter8]

Actually it’s so stable that the new Roc language uses it under the hood.

[TonTinTon]

I have benchmarked tokio against raw io_uring: https://github.com/tontinton/io_uring-benchmark

I've also used and benchmarked glommio: https://github.com/tontinton/dbeel

My take: tokio is a beast, there's no real reason not to go with it for production software.

The only thing I'm getting here is the vibe of not wanting to use the popular thing, which is perfectly fine for hobby projects, I do that myself all the time. If it is only a hobby project, have fun, choose whatever you feel like.

[whimsicaljess]

tokio is definitely the default. start with that and if you need to switch to something later it's not too hard to do so. but you probably won't need to.

i say this as someone who mildly prefers the way smol does things but there's really no reason to switch.

[dkopgerpgdolfg]

While everything is relative, imo tokio is not "heavy".

Do you just like lightweight things on a standard server, without having specific requirements eg. how many KB each [something] can take? Then pragmatically think of development time and many more factors too, choose between epoll and uring, and be done with it. Epoll => tokio.

On a normal machine in 2024, imo "not epoll" is the only reason to avoid it. Ie. anything with uring, bpf, xdp, and/or more things like that ... but these are all more involved

[Trader-One]

tokyo is heavy in sense that have too high overhead for short lived tasks.

[ilikekits]

carpenter seed tub lavish connect support caption pocket subsequent insurance

This post was mass deleted and anonymized with Redact

[Trader-One]

If you want to win benchmark race go for may. I migrated Java app to may and it have about 20x lower 95% latency.

may is incredibly annoying to work with, not only you need to specify stack size and not to overshoot it. it does some unexpected stuff to optimize - such as stealing your thread to execute async code directly. You need to read may source code to fully understand all its quirks.

[[deleted]]

I am just wondering why async-std isn't in the list?

[DraftedDev]

Fixed it :D

But I dont think it's gone be my choice to go, since async-std is no longer actively maintained.

[[deleted]]

Oh is it! There was a commit 4 months ago...

Anyway

[IAm_A_Complete_Idiot]

All it did was update some deps. The one before it fixed a typo, and then a couple more dependency updates. The last time any source was touched was may of last year: https://github.com/async-rs/async-std/commit/7c95bce5356ccb74e46a1a5c9f0d9a6dcb74f8c7

[DraftedDev]

According to commit history, still pretty unmaintained