On 8 Oct 2008, at 18:22, Michael Sofaer <[EMAIL PROTECTED]> wrote:
>
> Yes, mongrel_cluster is the way to go if you want to handle multiple
> concurrent requests. I recommend nginx over Apache for load balancing
> them, if you have the choice.
>
> Threading is indeed hard, but it helps immensely with scaling
> problems. That being said, Ruby threading is not very good at all
> and ActiveRecord is not threadsafe, so Rails won't be threaded any
> time soon.
Actually rails 2.2 will be threaded (rc out real soon now).
Activerecord itself can be used in a threadsafe way (but not in a
rails app; i've got a few multithreaded daemons using active record).
Of course to see the most benefit you'll need a ruby implementation
with native threads, like jruby.
Fred
>
>
> Check out Joe Domato's blog for an example of how poorly implemented
> and debugged Ruby threading is:
> http://timetobleed.com/ruby-threading-bugfix-small-fix-goes-a-long-way/
>
> Robert is right about how Rails handles concurrent requests (many
> instances of application) and correct that Mongrel doesn't spawn Ruby
> green threads (a good thing if you looked at the blog post above).
> However, most other web frameworks I know of don't do it that way.
> PHP and J2EE will have a master process that spawns child threads to
> handle requests, as does nginx. This lets the OS handle load
> balancing, and switch out threads that are blocked (usually waiting
> for DB calls to return).
>
> It would be better if Rails could do that but it can't. It's not a
> huge deal, unless you are running a very high-traffic site; just put
> up a Mongrel cluster and you will be fine.
>
> On Oct 8, 9:32 am, Robert Walker <[EMAIL PROTECTED]>
> wrote:
>>> is a single thread(ruby green thread) created for everyone request?
>>
>> I'm going to go out on a limb here since no others have responded,
>> but
>> my understanding (at least in the current version of Rails) is no. I
>> don't believe than a thread is created at all. It is my understanding
>> that the Rails application instance is a single processes thread that
>> handles the request all the way through to the response. The Rails
>> application instance will block from the time it receives a request
>> to
>> the time it completes the response.
>>
>> To handle requests concurrently you need to have multiple Rails
>> processes running. Typically you would use a Mongrel cluster for
>> this.
>> For best performance you also need a load balancer that is smart
>> enough
>> to know not to send a request to a busy Rails instance, otherwise,
>> that
>> request will be blocked until the Rails process completes it's
>> current
>> request.
>>
>> However, my understanding is the Mongrel, or Thin or whatever is
>> concurrent and will queue up the request that it sends to the Rails
>> instance for processing.
>>
>> That being said this is not that unusual. I believe that PHP
>> applications would work in a similar way. They would spin up a
>> process
>> to handles each request. One process handling one request.
>>
>> This is actually a safe and scalable solution. Threading is HARD!
>> And,
>> it's dangerous if not done correctly. And in the end it doesn't
>> really
>> help you scale as much as you might expect.
>>
>> I'll reiterate that this is my own understanding of this, and I
>> could be
>> completely off-base.
>>
>> Pokkai Dokkai wrote:
>>> i don't understand that request ... response process in rails
>>> framework
>>> .
>>
>>> is a single thread(ruby green thread) created for everyone request?
>>> then that single thread will be living upto the response send.
>>> am i correct ?
>>
>> --
>> Posted viahttp://www.ruby-forum.com/.
> >
--~--~---------~--~----~------------~-------~--~----~
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 rubyonrails-talk@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
