[Mongrel] multi threaded theoretically useful?
brandorr at opensolaris.org
Fri Sep 7 17:45:56 EDT 2007
On 9/7/07, Pete DeLaurentis <pete at nextengine.com> wrote:
> 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?
Well considering that a single-threaded process will map to a single
kernel thread in Solaris 9+ and Linux 2.6+. A process with green
threads that makes a system call will be blocked, until the call
returns, that means that all green threads in that process are
blocked. (Green threads are now known as fibers) ;)
This is one reason why IO intensive workloads, which make intensive
use of system calls, should benefit from "real" kernel threads, while
CPU intensive workloads can have the edge when implemented using green
threads, vs kernel threads. (The context switching cost being lower.)
> 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
> > processes.
> > This paper, for instance, from 2002, claims significantly better
> > performance on the JVM (Linux) with green threads than native.
> > <http://cselab.snu.ac.kr/member/naehyuck/papers/%5BJ14%5DComparative
> > %20performance%20evaluation%20of%20Java%20threads%20for%20embedded%
> > 20applications.pdf>
> > best,
> > Erik Hetzner
> > ;; Erik Hetzner, California Digital Library
> > ;; gnupg key id: 1024D/01DB07E3
> > _______________________________________________
> > Mongrel-users mailing list
> > Mongrel-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/mongrel-users
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
- Brian Gupta
More information about the Mongrel-users