On Sun, Aug 16, 2009 at 10:36 PM, s.ross <[email protected]> wrote: > > > 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. >
The things that happen between a request and response do not need to be done in a linear manner. This is your choice and you may be constrained to do this for many reasons. Also, you might have a well defined workflow which dictates when, where, and how information is to be processed. > > > > > 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. Yes, this is true of the common everyday application. However, others are doing innovative and difference things with the Ruby language in addition to Rails. > > > > 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. > I can safely safe after playing with Grand Central Dispatch for 2.5 months, it's the way to go for doing MT which alleviates most of the problems that you mention above. > > > 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. > I'm simply sayint that one shouldn't waste resources. Yes, I agree with you that having multiple cores isn't the reason for MT but having the ability to distribute load across cores is better than wasting cores or buying additional hardware that's not needed. Yes, the problem isn't defined by the target architecture but the solution is defined by the target architecture. This is very consistent within software development in understanding your risk analysis in the design phase of your project. > > 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'm not a huge fan of Java but JRuby is simply another option within the Ruby landscape. You can take it or leave it. > > 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. MT is generally a hard topic but GCD is making it very easy these days. -Conrad > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
