Closed jonhoo closed 9 years ago
As the number of clients goes up, this outperforms the one-thread-per-client approach. I expect this trend to be even more visible with a larger number of clients.. Benchmarking that next.
Plot above updated to reflect changes in 6bc0a1a783c50fd1d13a463282784caa53b316c4
Interestingly, rust-multiplex
performs better than rust
for a smaller number of cores, but on a larger number of cores, rust
outperforms (and scales past) rust-multiplex
...
Could you also give data on the worker pool? (channeled-based thread worker pool)
I believe it will be twice as fast.
@xekoukou no, rust-multiplex
is always faster, and has significantly lower variance in latency.
Probably, it was due to my 2-core laptop that i saw the difference.
By the way, a variance in latency is not a variance in the mean ops per second. The mean ops per second is quite stable.
Variance should translate exactly to variance in ops per second (though admittedly not to mean ops per second), as ops/s = 1/(s/op).
This branch introduces a single multiplexing Rust server based on #19 and #20 that operates as follows: With
n
cores,2n
threads are spawned:n
iterate over all of their streams (explained below), callingiterate()
on each one in turn.iterate()
performs a singlen -> n+1
iteration for a single client. These threads also listen on a per-threadmpsc
channel for new streams that they adopt upon receipt.n
cores accept new connections in a loop, and feed them to the firstn
threads in round-robin order. Before relinquishing a stream, they setTCP_NODELAY
, and perform a singleiterate()
call on the stream. This is to comply with the client waiting for all connections to be operational before starting the benchmark.Benchmark results will be posted shortly.