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
Thanks!
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
competitive!
Best,
Michael
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
