Getting tokio to match actix-web performance

[vitalyd]

@fpgaminer

I haven’t tried Vec yet, but I swapped in BytesMut with various reserve sizes in the function that reads the socket, but that didn’t have any effect. Do you still think Vec might perform better? If so what implementation are you thinking of (just initialize a fixed size Vec and keep the code as-is, or extend and erase from the Vec as lines come in and out?)

That was mostly just a side comment. One concern with an embedded/inline 4k array is the cost to move the host struct will go up as it has to memcpy all that (this assumes optimizer doesn't eliminate the move).

@fpgaminer

I’m still wrapping my head around Tokio (their code being constantly in flux and fragmented across many modules isn’t helping ).

Yeah, this landscape (along with the rest of async I/O) is very much still being painted with broad brushstrokes.

@fpgaminer

So if I understand correctly, for example, with a threadpool of 2 Tokio would actually have 3 threads running? 2 workers and 1 handling I/O events and passing them to the workers? Man … that’s some nasty synchronization.

Essentially, yes. If you search for "tokio reform" you'll see a bunch of discussions around the current default tokio setup.

@fpgaminer

By the way, if I/O heavy workloads are pathologic for Tokio … well isn’t Tokio mostly going to be used for I/O heavy workloads? What else would you need Tokio for if not I/O heavy workloads?

They're probably pathological for the default tokio setup, which is the one using a dedicated reactor thread + threadpool for execution. There's a current_thread module in tokio where you can create a reactor + executor to be the same thread (this was the only mode in the previous tokio version, called tokio_core). Take a look at:

1. tokio::runtime::current_thread - Rust
2. tokio::executor::current_thread - Rust

The current_thread executor (#2 there) is what actix-web appears to use on its http worker threads: https://github.com/actix/actix-web/blob/master/src/server/worker.rs#L185. That spawned HttpChannel then does all subsequent I/O with the peer; you can browse the channel code in https://github.com/actix/actix-web/blob/master/src/server/channel.rs