Rainbows and 2.0.0pre - thread safety

Rainbows and 2.0.0pre - thread safety

[Kyle Drake]

Hi guys,

I've setup a load test for Rainbows with Rubinius 2.0.0pre:

https://github.com/kyledrake/rubinius-sinatra-loadtesting/tree/master/rainbows

When I load test it on 2.0.0pre (via rvm and with apache bench), it
has a lot of weird, random errors. My current hypothesis is this is a
bug pertaining to thread safety in Rubinius, but someone suggested I
post it here so you could take a look. Tried both ThreadSpawn and
ThreadPool. I also made a test for Mongrel (which has similar errors),
and Thin (which works fine, but doesn't really utilize threads so it
doesn't mean anything).

It would also be nice to know which deploy strategy would work well
for Rubinius' threading. I wasn't sure if ThreadSpawn or ThreadPool
made more sense so I tried both.

Cheers!

-Kyle
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: Rainbows and 2.0.0pre - thread safety

[Eric Wong]

Kyle Drake <kyledrake-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi guys,
> 
> I've setup a load test for Rainbows with Rubinius 2.0.0pre:
> 
> https://github.com/kyledrake/rubinius-sinatra-loadtesting/tree/master/rainbows
> 
> When I load test it on 2.0.0pre (via rvm and with apache bench), it
> has a lot of weird, random errors. My current hypothesis is this is a
> bug pertaining to thread safety in Rubinius, but someone suggested I
> post it here so you could take a look. Tried both ThreadSpawn and
> ThreadPool. I also made a test for Mongrel (which has similar errors),
> and Thin (which works fine, but doesn't really utilize threads so it
> doesn't mean anything).

Sounds likely Rubinius isn't 100% thread-safe.  WEBrick should be worth
a try, too, since it's part of the standard library.  I would start
there, actually.

Some questions:

Does calling C extensions in Rubinius 2.x take a global lock of any
sort?  I seem to recall reading it did, but am not sure...

I also semi-recall reading that JRuby set the precedent for individual
Ruby methods on an object being thread-safe even with a free-threading
runtime, so stuff like:

   thread 1                | thread 2
   -----------------------------------------------
   hash[:t1] = true        | hash[:t2] = false

...wouldn't need locking for a given hash.  It would be nice to confirm
if Rubinius follows that.  I don't think the ThreadPool/ThreadSpawn
models rely on either of those behaviors, though.

> It would also be nice to know which deploy strategy would work well
> for Rubinius' threading. I wasn't sure if ThreadSpawn or ThreadPool
> made more sense so I tried both.

It probably depend more on your OS threading implementation and
hardware.  Both are fully-supported and worth trying, though.

I use ThreadSpawn on my cheap VPS (bogomips.org/rainbows.git) since it's
memory-constrained, receives almost no traffic, and spawning threads
with NTPL is cheap vs my peak request rate.

ThreadPool might be better if you have a very high rate of requests
and/or spawning OS threads is expensive given your request rate.

> Cheers!

Thanks for the interest in Rainbows!

-- 
Eric Wong
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying