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 via http://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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 via http://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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. 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 <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 8 Oct 2008, at 18:22, Michael Sofaer <msofaer-V+/iQTQbTeZBDgjK7y7TUQ@public.gmane.org> 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 <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> > 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 8 Oct 2008, at 17:32, Robert Walker <rails-mailing-list@andreas- s.net> 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 thatIt probably depends on what hosts rails. For example mongrel is most definitely multithreaded and can handle multiple concurrent requests, just not concurrent requests handled by rails. Fred> > 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 via http://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> Of course to see the most benefit you''ll need a ruby implementation > with native threads, like jruby.Or Ruby 1.9 YARV if I''m not mistaken? Frederick Cheung wrote:> On 8 Oct 2008, at 18:22, Michael Sofaer <msofaer-V+/iQTQbTeZBDgjK7y7TUQ@public.gmane.org> wrote: > >>...snip...> > Fred-- Posted via http://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 8 Oct 2008, at 19:52, Robert Walker wrote:> >> Of course to see the most benefit you''ll need a ruby implementation >> with native threads, like jruby. > Or Ruby 1.9 YARV if I''m not mistaken? >IIRC ruby 1.9 is a bit special - threads are mapped to native threads, but there''s some giant mutex (IIRC to help compatibility with C- extensions that could previously assume that everything was single threaded from a native thread point of view) that limits the effectiveness of this. Fred> Frederick Cheung wrote: >> On 8 Oct 2008, at 18:22, Michael Sofaer <msofaer-V+/iQTQbTeZBDgjK7y7TUQ@public.gmane.org> wrote: >> >>> > ...snip... >> >> Fred > > -- > Posted via http://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for all your reply now i understand. -- Posted via http://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---