Open howardjohn opened 1 month ago
Did you push the prototype code?
It shouldn't be terribly hard to use spawn
and join on the handles instead, or whatever, I guess, if we want real parallelism.
A little more expensive for trivial cases, but probably worth it for all the others.
I think we can collect multiple handles from tokio::spawn and then await them. I presume something like that is what @howardjohn already tried but didn't see any benefit from.
I think we can collect multiple handles from tokio::spawn and then await them. I presume something like that is what @howardjohn already tried but didn't see any benefit from.
Yeah - I misread. It probably doesn't make much difference because we already spawn the per-workload handler in a thread and are not remotely CPU bound even under load - distributing this specific operation across threads won't help much (and might make it easier for a greedy workload to starve other workloads on the node).
in general sticking with a one-thread-per-conn-handler-instance model seems best.
copy_bidirectional
usestokio::join
for the copy from upstream->downstream and vis-versa. Join is not concurrent, so its impossible for these two to happen at the same time (utilizing threads).Intuitively it seems like this should be helpful. On a simple call-response workload, no, but if there is continuous flow of data in both directions it should.
I put together a prototype, however, and do not see any benefits:
We should investigate more