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. _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users