[Mongrel] multi threaded theoretically useful?

Roger Pack rogerpack2005 at gmail.com
Fri Oct 5 12:43:46 EDT 2007


Thanks to all for your helpful answers on this question.  It's nice to
belong to a mailing list that has smart users (not that others don't,
of course).
So overall the answer to my question is that a multi-threaded rails
app might well not be significantly faster because say it has 10
threads, if 1 thread is waiting on a long-taking DB query, the other 9
are blocked anyway, so the benefits of a multi-threaded model are moot
(so a single-threaded rails is perhaps about as fast as a
multi-threaded rails).  Bring on Ruby 2.0 :)

Further question:
would providing the option of having mongrel bind to UNIX sockets
perhaps speed it? (i.e. bind to port 3000 and unix socket x).  Just a
thought.  Probably not enough speed difference to matter, but perhaps
useful for local processes and simple to implement. Thoughts?


> 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?

>When the flow of execution leaves Ruby and goes into some 3rd party
>extension (like that of a DB library), then ruby can't context switch.

>So yes, when one does a DB query that is going through a C extension,
>all of the other green threads are blocked, so that latency can't be
>captured.

>If it could be, then yes, there would be some benefit from some number
>of green threads per process for typical web apps.


More information about the Mongrel-users mailing list