I hope Rails becomes mutli-threaded in a not-to-distant future release. That would relieve much of the criticism of Rails due to its single threadness. In reading Dave Thomas'' book, Agile Web Development with Rails, 2nd ed, section 27.2, page 617, he indicates the way to scale Rails is to have a front end HTTP proxy server that sends rails requests to back end rails processes. In the next paragraph, he refers to these processes as application servers. I understand this to mean each rails implementation runs on its own "box." If my understanding is not correct, stop me now and set me straight! However, if my basic understand is basically correct, this seems like a rather expensive approach of having to add a "box" everytime the system slows down. Here is my question, can the single thread issue be solved by running multiple rails instances on a single powerful box using some level of Virtualization? Please follow this link to Wikipedia''s section on Virtualization for more info: http://en.wikipedia.org/wiki/Virtualization. If this can be done, does anyone know what level/kind of virtualizations is required? Any wisdom that you can provide would be much appreciated. Thanks again! --~--~---------~--~----~------------~-------~--~----~ 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 May 7, 2007, at 8:24 AM, someone1111 wrote:> In reading Dave Thomas'' book, Agile Web > Development with Rails, 2nd ed, section 27.2, page 617, he indicates > the way to scale Rails is to have a front end HTTP proxy server that > sends rails requests to back end rails processes. In the next > paragraph, he refers to these processes as application servers. I > understand this to mean each rails implementation runs on its own > "box." If my understanding is not correct, stop me now and set me > straight!You can run as many processes as you''d like on a single piece of physical hardware (within reason). Dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
The idea is that you run a number of backend server processes (something like Mongrel) that have your Rails apps running with a "frontend" server (like Apache or Lighttpd or nginx) for static file serving, load balancing, forwarding requests to the backend, etc. You can run a number of backend processes on a single box, no virtualization required. :) --Jeremy On 5/7/07, someone1111 <marvins611-YDxpq3io04c@public.gmane.org> wrote:> > I hope Rails becomes mutli-threaded in a not-to-distant future > release. That would relieve much of the criticism of Rails due to its > single threadness. In reading Dave Thomas'' book, Agile Web > Development with Rails, 2nd ed, section 27.2, page 617, he indicates > the way to scale Rails is to have a front end HTTP proxy server that > sends rails requests to back end rails processes. In the next > paragraph, he refers to these processes as application servers. I > understand this to mean each rails implementation runs on its own > "box." If my understanding is not correct, stop me now and set me > straight! > > However, if my basic understand is basically correct, this seems like > a rather expensive approach of having to add a "box" everytime the > system slows down. > > Here is my question, can the single thread issue be solved by running > multiple rails instances on a single powerful box using some level of > Virtualization? Please follow this link to Wikipedia''s section on > Virtualization for more info: http://en.wikipedia.org/wiki/Virtualization. > If this can be done, does anyone know what level/kind of > virtualizations is required? > > Any wisdom that you can provide would be much appreciated. > > Thanks again! > > > > >-- http://www.jeremymcanally.com/ My free Ruby e-book: http://www.humblelittlerubybook.com/book/ My blogs: http://www.mrneighborly.com/ http://www.rubyinpractice.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 -~----------~----~----~----~------~----~------~--~---
Another thing to consider is that handling concurrent requests using multiple instances of these "backend server processes" is inherently much safer than multi-threading inside a single instance. Threading is a technique that is VERY difficult to get right. Generally the benefit that you gain from multi-threading can easily be overshadowed by the problems that it causes when not done 100% correctly. In a single threaded application you don''t have to worry about situations like deadlocking and lock management in general. In my opinion using a mongrel cluster is much preferred over multi- threaded Rails. It certainly makes life much less complicated for the average developer. On May 7, 9:46 am, "Jeremy McAnally" <jeremymcana...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> The idea is that you run a number of backend server processes > (something like Mongrel) that have your Rails apps running with a > "frontend" server (like Apache or Lighttpd or nginx) for static file > serving, load balancing, forwarding requests to the backend, etc. You > can run a number of backend processes on a single box, no > virtualization required. :) > > --Jeremy > > On 5/7/07, someone1111 <marvins...-YDxpq3io04c@public.gmane.org> wrote: > > > > > > > I hope Rails becomes mutli-threaded in a not-to-distant future > > release. That would relieve much of the criticism of Rails due to its > > single threadness. In reading Dave Thomas'' book, Agile Web > > Development with Rails, 2nd ed, section 27.2, page 617, he indicates > > the way to scale Rails is to have a front end HTTP proxy server that > > sends rails requests to back end rails processes. In the next > > paragraph, he refers to these processes as application servers. I > > understand this to mean each rails implementation runs on its own > > "box." If my understanding is not correct, stop me now and set me > > straight! > > > However, if my basic understand is basically correct, this seems like > > a rather expensive approach of having to add a "box" everytime the > > system slows down. > > > Here is my question, can the single thread issue be solved by running > > multiple rails instances on a single powerful box using some level of > > Virtualization? Please follow this link to Wikipedia''s section on > > Virtualization for more info:http://en.wikipedia.org/wiki/Virtualization. > > If this can be done, does anyone know what level/kind of > > virtualizations is required? > > > Any wisdom that you can provide would be much appreciated. > > > Thanks again! > > --http://www.jeremymcanally.com/ > > My free Ruby e-book:http://www.humblelittlerubybook.com/book/ > > My blogs:http://www.mrneighborly.com/http://www.rubyinpractice.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 -~----------~----~----~----~------~----~------~--~---