On Aug 16, 2009, at 9:40 PM, Conrad Taylor wrote:
> On Sun, Aug 16, 2009 at 7:07 PM, s.ross <[email protected]> wrote: > > > On Aug 16, 2009, at 6:51 PM, Maurício Linhares wrote: > > > > > On Sun, Aug 16, 2009 at 10:47 PM, s.ross<[email protected]> wrote: > >> > >> Why do you say this? Most request/response cycles are so quick that > >> they are unlikely to benefit significantly from multithreading. How > >> "huge" a win is multi-threading in the timespan of ... say ... < > >> 30ms? > >> > > > > It's a HUGE win 'cos if you have a machine with multiple processing > > cores (something that's as common as a keyboard and a mouse > nowadays) > > your server can benefit from them without a separate process and all > > the monitoring/memory/OS footprint that this solution carries. > > > > It's a huge win if you have blocking tasks. It's not if you have tasks > that cannot be parallelized. My point is that a good deal of the stuff > you do between when you get a request and when you serve a response is > done in a linear manner. If you were going out and foraging among > several Web services to create a composite response then fine, > multithread away. > > I can have long running tasks that does not block. I can stuff it > in a thread, > return to the caller, and wait for a notification. This can be done > using a > single thread and no additional plugins. And the common everyday Rails applicability of being able to stuff a long-running task into a thread is what I've seldom seen. > In C-Ruby, the way to work around the GIL to achieve concurrency is to > push this functionality down into the Ruby C-Extension. Thus, > you'll be > using processes for thread parallelism. This workaround isn't > needed with > JRuby. JRuby provides a threading model which allows one to write > truly > concurrent Rails applications because it's not limited by a GIL as > it is in C-Ruby (i.e. MRI/YARV). Also, JRuby uses system native > threads > that operate concurrently instead of green threads. I understand the difference between the OS-native threads and Ruby's threads that run under the GIL. Multi-processing is, however, not the worst solution. Consider this: There is no standard IPC for the threaded model because threads run (duh) in-process. So how do threads communicate? Shared (global?) variables. So now you are facing concurrency problems, setting and releasing mutexes, and all the other keen stuff you don't have to do if you use the more constrained multi- process model. > Next, I have seen better resource utilization by using VMs that > support multiple cores. What's the point of having an 8 core > machine and > 10 mongrels running on a single core? That's like saying why have a car that can go 150 when the speed limit is 65? Having multiple cores is not a reason in and of itself to design multithreaded solutions. Some problems are well-suited to parallel solutions; some aren't. But the problem is not defined by the target architecture. > Multithreading is just peachy for systems where orthogonal bodies of > work can be isolated into threads and run at their own pace and/or > block on external dependencies like IO, to coalesce when possible. For > example, finding and formatting a bunch of data and populating a > listbox in a client app without freezing the UI. But such > orthogonality is seldom, in my experience, found in that brief instant > between a user request and the time the response must be issued. > > You should try writing a multi-threaded Rails application and see > where it > takes you. I have. It takes me into a painstaking exercise in protecting myself against elusive and difficult to reproduce concurrency bugs. > So my question is still: How much of a practical (not theoretical) win > is MT for a Web application and does the J in JRuby really increase > the win over green threads for this brief a set of tasks? > > In short, JRuby opens the door to accessing the wealth of Java > libraries > and frameworks. Also, it provides a truly current threading model > using > system native threads and I'm glad that there are other > implementations > leveraging the environments that are used to build them. I'm really not missing Java that much. I think multi-threading is just another arrow in the quiver of the good software designer. Having been down this road many times, I find it difficult to characterize multi-threading as a "huge win" in the context of Web applications. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
