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. 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. 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? > > 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. > > 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. -Conrad > > > Just asking... > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
