[rust-dev] net::tcp::TcpSocket slow?

Michael Neumann mneumann at ntecs.de
Sat Dec 22 16:11:02 PST 2012

Am 22.12.2012 17:35, schrieb Patrick Walton:
> On 12/22/12 9:15 AM, Michael Neumann wrote:
>> The best thing I can do is to use blocking I/O here anyway as it's
>> better to have just one connection to Redis and multiplex that, so I can
>> easily use one native thread for that.
>> I am just very new to Rust, and the only thing I found was tcp_net. So I
>> think I should define my own FFI socket calls, right?
> Yes, that's what I would do. I think there may be some bindings to BSD 
> sockets in cargo -- Brian would know better here.
> The scheduler modes here might be useful to ensure that your task gets 
> its own OS thread: 
> http://dl.rust-lang.org/doc/0.4/core/task.html#enum-schedmode


I rerun the same benchmark on a faster box with many cores. Now there is 
almost no difference in the single-thread case compared against Ruby. I 
get 15k requests per second.
Once I use multiple threads, Rust is the clear winner. It maxes out at 
30k requests per second, which I think is somehow the limit what can be 
obtained (I've seen this number in several other HTTP benchmarks). Each 
thread uses a separate connection of course.

I tried to create a separate iotask for each socket connection as well, 
but somehow when I do so:

   let iotask = uv::iotask::spawn_iotask(task::task());

performance decreases to 50% when compared against:

   let iotask = uv::global_loop::get();

I wonder what the reason for this is...

Anyway, I am quite happy to see that Rust's network performance is quite 



More information about the Rust-dev mailing list