From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: Rainbows! list <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: Rainbows and 2.0.0pre - thread safety
Date: Mon, 20 Jun 2011 14:29:39 -0700 [thread overview]
Message-ID: <20110620212939.GA18538@dcvr.yhbt.net> (raw)
In-Reply-To: <BANLkTin8_7QiUAoxmtcoePT03Cg4cdK85g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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
prev parent reply other threads:[~2011-06-20 21:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-20 20:51 Rainbows and 2.0.0pre - thread safety Kyle Drake
[not found] ` <BANLkTin8_7QiUAoxmtcoePT03Cg4cdK85g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-20 21:29 ` Eric Wong [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://yhbt.net/rainbows/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110620212939.GA18538@dcvr.yhbt.net \
--to=normalperson-rmlxzr9ms24@public.gmane.org \
--cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhbt.net/rainbows.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).