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