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.
On 10/5/07, Roger P. [email protected] wrote:
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 
Multi-threaded may even be slower, in fact. In a lot of the
cases, it will definitely be slower.
Even on a platform with native threads, multithreading may be no
faster than a multiprocess model. It’s not a magic bullet.
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?
I used to run all of my IOWA apps via unix sockets. I don’t do that
anymore, though. There are situations where it can arguably be
useful, but most of the time it just doesn’t matter. Any differences
between 127.0.0.1:11111 and /path/to/a/unix/socket are lost in the
noise of the rest of the performance affecting load – they are just
too small to matter much.
Kirk H.
On 10/5/07, Roger P. [email protected] wrote:
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?
Depending on the kernel, you may find Unix sockets to be less performant
than localhost TCP. The dominant effect on performance comes from
getting
the network out of the picture. Beyond that, I’ve often found that
unix-domain I/O stacks don’t seem to be as well-tuned as TCP stacks are.
And
use localhost/tcp instead of an IP address on a network interface. On
most
kernels, that saves you a trip through the network interface driver.
