Ballpark number of mostly idle tcp connections that async server can handle


I'm having a hard time finding it via google. I'd like to get some ballpark notion of what's possible with a async Rust server w.r.t. number of concurrent connections.

Let's say I have axum based websocket server, where clients register for a notification when something happens, sometimes make a light query (not very often). Very, very lightweight workload per client, but possibly a lot of clients and thus idle connections.

At what number of connections I should expect things to start falling apart, assuming no other component is involved? Are we talking 10k? 100k? 1M? Let's assume I can tweak any OS-level limits to the maximum possible. Though memory usage (if a limiting factor) might be a constrain.

Again - I realize that it depends on the machine, networking, the exact logic behind each query, etc. Please specify these details if you have data from an actual setup. I'm juts looking for a rule of thumb type of a number.

While at it, feel free to post any stats from other workloads as well. Might be interesting to know as well.

Thanks a lot!

1 Like

If they are literally idle, the only resource that sockets really consume is kernel memory. (The file descriptors are also a distinct resource, but these are controlled by ulimit, sysctl, etc.) This problem is purely memory-bound.

If each socket periodically wakes up, then you must account for CPU and I/O bandwidth resources. It very much depends on what the code does!

You might expect a layer-7 proxy to manage something on the order of 500 K to 1 M concurrent connections. But who knows! It depends on your hardware and loads of other factors.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.