Performance Question about async-tungstenite HOT 8 CLOSED

Checking with async-std or gio as another runtime might also be interesting here. The performance is going to depend on the runtime too.

from async-tungstenite.

Async code will generally be slower in the small scale than sync code. There's a lot more book-keeping that has to be done compared to simply blocking a thread.

Async code starts to become better performance-wise once you have a lot of operations in parallel and running a whole OS thread for each of them would consume too many resources.

Async code also has the advantage of easier to read and maintain code since the async/await syntax was introduced.

Apart from that your code example does not seem to do much at all, I'd expect any performance differences here to be irrelevantly small unless something's going really wrong. What numbers do you measure and how?

The comparison with Python is not too useful in this regard because Python is effectively single-threaded by the use of the global interpreter lock. By running async code in Python you can do lots of operations in parallel while actually blocking would potentially block everything.

That said, I'm sure there might be some parts in this crate that can be optimized further. I'd recommend doing some profiling to find the bottlenecks if this is a concern for you.

from async-tungstenite.

~700 is still a pretty small number - try spawning 10k connections simultaneously (if you even manage to create 10k threads on your computer) :-)

from async-tungstenite.

In addition to what @Patryk27 said, CPU usage is not the only thing you want to measure really. Those 717 threads are going to use up a lot of OS resources compared to 5 threads :)

from async-tungstenite.

Ive tried recently scaling this up to 714 connections with 714 threads vs 714 tokio::spawn() tasks to try to make this more 'large' scale.

The numbers I measured are of my mac using Activity Monitor.

Threaded
Cpu Usage: 4-6%
Threads: 717

Async
Cpu Usage: 5-7%
Threads: 5

It still seems to have a similar results. I guess my testing methodology may not be sound since I assumed that in the threaded version these connections are mostly just waiting for a websocket message to be received, so I was thinking that the async implementation would run faster.

What would be a much better test for proving this ?

from async-tungstenite.

Thanks for the help. After scaling I started to see differences at 2856 websocket connections. If i try to double that, the threads fail with the following error

Number of markets 5712
thread 'main' panicked at 'failed to spawn thread: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }', src/libcore/result.rs:1165:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

at 2856 ws connections it seems like the async implementation seems to be running at half the cpu usage and only consuming 4 threads :-)

Threaded
Cpu Usage: 20-35
Threads: 2858

Async
Cpu Usage: 10-20%
Threads: 4

from async-tungstenite.

Will have a shot at this, and come back with some performance results

from async-tungstenite.

@araa47 what have you found out? You might want to have a look at the memory usage, there will be a real difference there. You can reduce the stack size of threads to make them lighter though. You can also change the max number of threads on your system, eg. for linux.

from async-tungstenite.