[Mongrel] multi threaded theoretically useful?

Erik Hetzner erik.hetzner at ucop.edu
Fri Sep 7 17:36:56 EDT 2007


At Fri, 7 Sep 2007 13:50:50 -0700,
"Kirk Haines" <wyhaines at gmail.com> wrote:
>
> On 9/7/07, Erik Hetzner <erik.hetzner at ucop.edu> wrote
>
> > What problem domain? Web servers in general? Web applications? Web
> > applications which are heavily database dependent? I show below
> > that there are web apps whose throughput can be improved by green
> > threading.
>
> The general area of Ruby web applications and the serving thereof.

Which in my experience involves waiting for external web services,
among other things. If you want to say that this is something that
isn’t a typical rails app, fine. I’m telling you that my threads are
often i/o bound.

> Sure, but the _only_ way to get this with Ruby green threads is if
> you have threads that are blocking on something within Ruby code, so
> that Ruby can context switch to a different thread and get something
> done with it while the first one sits around, waiting. You
> artificially construct exactly that scenario in your example below.
> I'll comment on it more in a minute. In real apps, though, most of
> the time, that just isn't happening.

I understand how threads work, and I don’t think that my construction
is artificial.

> And when you are waiting on something like a database, you are doing
> it within the DB driver extension, so there are no context switches
> happening -- your green threads are blocked.

Surely it is possible to write a C extension for Ruby that allows
context switching from within it? This is outside my understanding of
Ruby threads.

> The reason you get more performance when multithreading is because
> of that sleep call. It is all happening inside of Ruby, so when
> running in a multithreaded context, when one thread goes to sleep,
> the others just get the execution cycles. It's artificial, though.
> Read Ruby web apps don't tend to have latencies like that. When they
> are waiting, they are waiting inside of things that block the entire
> Ruby process, and not just waiting for something that is blocking a
> single thread.

I know why we are getting greater performance, and again, I don’t
think it’s artificial. But, in any case, it was a demonstration,
mostly for the original responder, who claimed that you would never
get more performance from Ruby threads.

Again, your mileage may vary. And it’s all moot for rails users since
I don’t see rails going multithreaded.

best,
Erik Hetzner
;; Erik Hetzner, California Digital Library
;; gnupg key id: 1024D/01DB07E3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/mongrel-users/attachments/20070907/ec5d9f95/attachment.bin 


More information about the Mongrel-users mailing list