[Mongrel] multi threaded theoretically useful?
pete at nextengine.com
Fri Sep 7 15:06:41 EDT 2007
Here's one question that I think would have an impact on how useful
green threads are for many server apps:
If you are blocking on something like a database SELECT in one green
thread, will the Ruby interpreter switch to another green thread
while it's waiting for the response?
Or does a blocking request block all green threads?
On Sep 7, 2007, at 12:02 PM, Erik Hetzner wrote:
> At Fri, 7 Sep 2007 11:43:24 -0700,
> Ezra Zygmuntowicz <ezmobius at gmail.com> wrote:
>> Hey Roger-
>> No it would not be as fast at all. Current ruby threads are green
>> threads, meaning that they do not use native OS threads so there is
>> no real parallel execution. Ruby has an internal timer and just
>> switches between threads really fast. So 10 mongrels will trounce one
>> thread safe mongrel.
>> Ruby 1.9, Jruby and Rubinius will eventually have native
>> threads and may make this situation better but for now such is life.
> I don’t want to muddy the waters here, as my knowledge of Ruby
> threading performance is minimal, but there isn’t any ‘real’ parallel
> execution on any uniprocessor machine: it’s all emulation. Erlang uses
> green threads (but calls them processes) but context switches quite a
> bit faster (if I understand correctly) than native threads or
> processes. True, on a multiprocessor machine Ruby isn’t going to take
> advantage of the situation without native threads or running multiple
> processes. But it may turn out that a mixture of multiple processes
> AND green threads provides greater performance than plain old multiple
> This paper, for instance, from 2002, claims significantly better
> performance on the JVM (Linux) with green threads than native.
> Erik Hetzner
> ;; Erik Hetzner, California Digital Library
> ;; gnupg key id: 1024D/01DB07E3
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users