# Re: multi threaded theoretically useful? **URL:** \ **Category:** Mongrel\ **Created:** [October 5, 2007, 6:44pm UTC](https://www.ruby-forum.com/t/re-multi-threaded-theoretically-useful/116455 "2007-10-05T18:44:23Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [October 5, 2007, 6:44pm UTC](https://www.ruby-forum.com/t/re-multi-threaded-theoretically-useful/116455/1 "2007-10-05T18:44:23Z")
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. ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [October 5, 2007, 6:56pm UTC](https://www.ruby-forum.com/t/re-multi-threaded-theoretically-useful/116455/2 "2007-10-05T18:56:08Z")
On 10/5/07, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. ---
**Author:** ![rogerdpack](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/45deac/32.png) [@rogerdpack](https://www.ruby-forum.com/u/rogerdpack)\ **Post date:** [October 5, 2007, 7:11pm UTC](https://www.ruby-forum.com/t/re-multi-threaded-theoretically-useful/116455/3 "2007-10-05T19:11:22Z")
On 10/5/07, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.