Before the question(s), let me stress that I don''t have ANY biases in any direction on this subject. I''ve been learning RoR and am very impressed by it; this is just a request to learn - not any type of flame bait. I can see (some of) the advantages to developing w/RoR. I say some because I''m pretty sure that I''m just scratching the surface. There is no question that it is an incredibly powerful development engine. It''s the deployment side of it that bothers me. I see people talking about switching to lighthttp or some other server just so they can use RoR. I see a FAQ page that actually has a question about how to have more than one Rails application on a single server. If that question even has to be asked, it seems something is wrong. If RoR is so specialized that the most common web server in use (Apache) isn''t in the first choices for hosting, something seems wrong. A quick (and it was very quick) google shows me that there are alternatives. There are frameworks for Python and Perl ... and I''d be surprised if a closer look wouldn''t show more frameworks for Ruby and any other languages that have a current following (I guess that rules out Cobol <g>). Considering what appears to be the deployment problems of RoR, why is this a good / better general purpose framework. If I''m wrong about the deployment problems, I''m willing to learn. Remembering that I *REALLY* don''t want to start a flame-war, would some of you that have been using RoR for a while be willing to fill in what are my obvious gaps? ---Michael -- 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 -~----------~----~----~----~------~----~------~--~---
May be...I am not the correct person to answer this, but currently Apache-2.2.3 is the standard way of serving Ruby on Rails application.Justuse a cluster of mongrel application servers as a backend(for your own good actually). Lots of commercial sites are being run like this. Its scalable, fast and works as a charm.There ain''t any point in stressing this.....but for serving ASP.NET applications you must use IIS, so does that makes ASP.NETapplications total crap to deploy? I dont think so. On 9/5/06, Michael Satterwhite <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Before the question(s), let me stress that I don''t have ANY biases in > any direction on this subject. I''ve been learning RoR and am very > impressed by it; this is just a request to learn - not any type of flame > bait. > > I can see (some of) the advantages to developing w/RoR. I say some > because I''m pretty sure that I''m just scratching the surface. There is > no question that it is an incredibly powerful development engine. It''s > the deployment side of it that bothers me. I see people talking about > switching to lighthttp or some other server just so they can use RoR. I > see a FAQ page that actually has a question about how to have more than > one Rails application on a single server. If that question even has to > be asked, it seems something is wrong. If RoR is so specialized that the > most common web server in use (Apache) isn''t in the first choices for > hosting, something seems wrong. > > A quick (and it was very quick) google shows me that there are > alternatives. There are frameworks for Python and Perl ... and I''d be > surprised if a closer look wouldn''t show more frameworks for Ruby and > any other languages that have a current following (I guess that rules > out Cobol <g>). Considering what appears to be the deployment problems > of RoR, why is this a good / better general purpose framework. If I''m > wrong about the deployment problems, I''m willing to learn. > > Remembering that I *REALLY* don''t want to start a flame-war, would some > of you that have been using RoR for a while be willing to fill in what > are my obvious gaps? > > ---Michael > > -- > Posted via http://www.ruby-forum.com/. > > > >-- nothing much to talk --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hemant Kumar wrote:> May be...I am not the correct person to answer this, but currently > Apache-2.2.3 is the standard way of serving Ruby on Rails > application.Justuse a cluster of mongrel application servers as a > backend(for your own good > actually).OK, I''ll look at this. Seems a bit heavy handed to need multiple boxes just because you''re running more than one application (if I understand you). I thought we left that requirement behind back in the 1970''s.> Lots of commercial sites are being run like this. Its scalable, fast and > works as a charm.There ain''t any point in stressing this.....but for > serving > ASP.NET applications you must use IIS, so does that makes > ASP.NETapplications total crap to deploy? > > I dont think so.I do. ASP.NET is a nightmare; I''d *NEVER* use it as an example of a good framework. It - combined with the IIS requirement is a security hole inviting people in. Just because Microsoft is big doesn''t mean they''ve got the best answers. ---Michael -- 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 -~----------~----~----~----~------~----~------~--~---
> > May be...I am not the correct person to answer this, but currently > > Apache-2.2.3 is the standard way of serving Ruby on Rails > > application.Justuse a cluster of mongrel application servers as a > > backend(for your own good > > actually). > > OK, I''ll look at this. Seems a bit heavy handed to need multiple boxes > just because you''re running more than one application (if I understand > you). I thought we left that requirement behind back in the 1970''s.Whoever said that is wrong. You don''t need multiple boxes to run more than one application. Rails applications usually use either FCGI or Mongrel where you get x number of Rails processes lined up for Apache/lighttpd/litespeed/whatever-with-a-decent-proxy-or-fcgi-implementation lined up. This does in general require more memory than, say, mod_php, though. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 9/4/06, Michael Satterwhite <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Hemant Kumar wrote: > > May be...I am not the correct person to answer this, but currently > > Apache-2.2.3 is the standard way of serving Ruby on Rails > > application.Justuse a cluster of mongrel application servers as a > > backend(for your own good > > actually). > > OK, I''ll look at this. Seems a bit heavy handed to need multiple boxes > just because you''re running more than one application (if I understand > you). I thought we left that requirement behind back in the 1970''s.mongrel_cluster is a piece of software that essentially starts and stops multiple instances of mongrel on different ports. You don''t need to have them on separate hardware, although you could if you want. On the front-end, you''ll want to use something like Apache or Pound to proxy requests to the appropriate app server(s). You should seriously consider reading the mongrel documentation: http://mongrel.rubyforge.org/docs/index.html -- James --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
On 9/4/06, Michael Satterwhite <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > the deployment side of it that bothers me. I see people talking about > switching to lighthttp or some other server just so they can use RoR. I > see a FAQ page that actually has a question about how to have more than > one Rails application on a single server. If that question even has to > be asked, it seems something is wrong. If RoR is so specialized that the > most common web server in use (Apache) isn''t in the first choices for > hosting, something seems wrong.It often is the first choice, whether via FastCGI, mod_proxy_balancer, or even mod_ruby. Rails scales best as a pool of Ruby processes, so running a cluster of FastCGI instances or proxying a pack of Mongrel makes a lot sense. A quick (and it was very quick) google shows me that there are> alternatives. There are frameworks for Python and Perl ... and I''d be > surprised if a closer look wouldn''t show more frameworks for Ruby and > any other languages that have a current following (I guess that rules > out Cobol <g>). Considering what appears to be the deployment problems > of RoR, why is this a good / better general purpose framework. If I''m > wrong about the deployment problems, I''m willing to learn.You haven''t actually stated any deployment problems. What''s wrong with Rails deployment is that it''s a little bit different and therefore scary. Wait until you get to what''s right: migrations and Capistrano. Good luck. jeremy --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
DHH wrote:>> > May be...I am not the correct person to answer this, but currently >> > Apache-2.2.3 is the standard way of serving Ruby on Rails >> > application.Justuse a cluster of mongrel application servers as a >> > backend(for your own good >> > actually). >> >> OK, I''ll look at this. Seems a bit heavy handed to need multiple boxes >> just because you''re running more than one application (if I understand >> you). I thought we left that requirement behind back in the 1970''s. > > Whoever said that is wrong. You don''t need multiple boxes to run more > than one application. Rails applications usually use either FCGI or > Mongrel where you get x number of Rails processes lined up for > Apache/lighttpd/litespeed/whatever-with-a-decent-proxy-or-fcgi-implementation > lined up.Sorry. Like I said, I''m looking for information and the post said "cluster of Mongrel servers". From "cluster", I extrapolated - apparently incorrectly.> > This does in general require more memory than, say, mod_php, though.Which doesn''t necessarily bother me. Memory is cheap today (I can''t believe I started on a box that filled a computer room and had 32K of *CORE* memory) ---Michael -- 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 -~----------~----~----~----~------~----~------~--~---
James Ludlow wrote:> You should seriously consider reading the mongrel documentation: > http://mongrel.rubyforge.org/docs/index.htmlI absolutely will. Thank you for referring me to it. ---Michael -- 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 -~----------~----~----~----~------~----~------~--~---
On 9/4/06, Michael Satterwhite <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > James Ludlow wrote: > > > You should seriously consider reading the mongrel documentation: > > http://mongrel.rubyforge.org/docs/index.html > > I absolutely will. Thank you for referring me to it.While you''re at it. http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/ -- James --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---