Hello Is mod_ruby still considered an inferior solution compared to fastcgi, even after the availability of 1.2.6, which includes the RailsDispatcher [1], which allows for safe execution of multiple rails applications? I''m asking because using apache is a requirement here, given our existing set of tools which work with it. Also, mod_ruby doesn''t require executable scripts, which allows me to mount the partition with the noexec flag (this is an important security feature in a server that allows customer logins via ssh). Best regards, Andre [1]http://blog.shugo.net/articles/2005/08/03/running-rails-on-mod_ruby --~--~---------~--~----~------------~-------~--~----~ 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 12/12/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Hello > > Is mod_ruby still considered an inferior solution compared to fastcgi, > even after the availability of 1.2.6, which includes the > RailsDispatcher [1], which allows for safe execution of multiple rails > applications? >Both are inferior to mongrel. Even with the new mod_ruby, do you really want to use something with a small enough user base that you don''t know if it will still work a year down the road? And if you allow ssl logins but don''t allow them to execute anything, what''s the point? --~--~---------~--~----~------------~-------~--~----~ 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 12/12/06, snacktime <snacktime-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Both are inferior to mongrel. Even with the new mod_ruby, do you > really want to use something with a small enough user base that you > don''t know if it will still work a year down the road?Why not? If nobody starts using it, the userbase will never grow. I guess rails itself had a small user base once... why did the pioneers start using it?> And if you allow ssl logins but don''t allow them to execute anything, what''s the > point?It''s not that they can''t execute anything. It means they can''t have executables in their home dirs. Best regards, Andre --~--~---------~--~----~------------~-------~--~----~ 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 12/12/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> It''s not that they can''t execute anything. It means they can''t have > executables in their home dirs.And why is that bad again? I''d hate to know I couldn''t execute my own backup.sh in my own ~ -- Greg Donald http://destiney.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 -~----------~----~----~----~------~----~------~--~---
Greg Donald wrote:> On 12/12/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> It''s not that they can''t execute anything. It means they can''t have >> executables in their home dirs. >> > > And why is that bad again? > > I''d hate to know I couldn''t execute my own backup.sh in my own ~Presumably /bin/sh is on another partition so "/bin/sh backup.sh" would work fine. I''m just playing devil''s advocate ;) Back to the issue at hand: I am currently developing a Rails app which I will be deploying in the next month or so. I was intending to use Apache webserver because I am familiar with it but the comments in this thread prompted me to take a look at Mongrel. It appears that Mongrel doesn''t support SSL and "...will break down pretty quick if you have lots of people accessing Rails actions that are slow." How can anyone seriously propose Mongrel for a production setup? It appears that Mongrel is just a cut-down and easy-to-use webserver for the kiddies who don''t want to learn Apache. The documentation makes numerous statements like "Apache is notorious for having a horribly complex configuration file." What a load of bullshit! Sure, there are lots of directives which can be a bit overwhelming for the newbie, but break it down and look at each directive individually and it makes perfect sense. There are some great books out there to help. So to Andre, who started this thread: I''ll be trying mod_ruby so there''s one more for the user base :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I wouldn''t be too quick to cast Mongrel to the dogs, as it were. It''s running a number of fairly decent sized sites, including one of the 37s ones (http://weblog.rubyonrails.org/2006/7/3/pound-makes-lighty- and-mongrel-play-nice). As distinctly opposed to where PHP and dot- Net deployment is right now, Rails deployment is not a one-target deal (IMO). There are several capable servers around that can serve up pages, and many people have thrashed at all of them. The consensus seems to be moving toward Apache proxying to a load balancer, distributing to a Mongrel pack. Mongrel packs will not break down "if you have lots of people..." because you can add new Mongrel instances behind your load balancer. Pages that are slow typically only take .2 seconds to serve up. If you have 4-5 Mongrels running in a cluster, you''re unlikely to experience latency as a result of a blocking request, but of course some testing would be in order. I run some of my sights on lighttpd and some on Mongrel. Now that I''ve started using Mongrel, each lighttpd site that gets a revision also changes to Mongrel. It''s that much easier to work with. I haven''t even considered Apache because fcgi has typically been unstable and mod_ruby suffered from concurrency problems. Just my $.02 On Dec 12, 2006, at 5:47 PM, Michael Henry wrote:> > Greg Donald wrote: >> On 12/12/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>> It''s not that they can''t execute anything. It means they can''t have >>> executables in their home dirs. >>> >> >> And why is that bad again? >> >> I''d hate to know I couldn''t execute my own backup.sh in my own ~ > Presumably /bin/sh is on another partition so "/bin/sh backup.sh" > would > work fine. > > I''m just playing devil''s advocate ;) > > Back to the issue at hand: I am currently developing a Rails app > which I > will be deploying in the next month or so. I was intending to use > Apache > webserver because I am familiar with it but the comments in this > thread > prompted me to take a look at Mongrel. > > It appears that Mongrel doesn''t support SSL and "...will break down > pretty quick if you have lots of people accessing Rails actions > that are > slow." How can anyone seriously propose Mongrel for a production > setup? > It appears that Mongrel is just a cut-down and easy-to-use > webserver for > the kiddies who don''t want to learn Apache. The documentation makes > numerous statements like "Apache is notorious for having a horribly > complex configuration file." What a load of bullshit! Sure, there are > lots of directives which can be a bit overwhelming for the newbie, but > break it down and look at each directive individually and it makes > perfect sense. There are some great books out there to help. > > So to Andre, who started this thread: I''ll be trying mod_ruby so > there''s > one more for the user base :) > > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi, *DON''T* do that. - Mongrel rocks, kudos to Zed ... don''t diss his software, have u seen how *he* can rant ? ;-) - Yes, Apache has complex config compared to http://brainspl.at/ nginx.conf.txt ( shameless Nginx plug ) - Mongrel was never meant to be used standalone in Production ... Development env, yes. - You need to proxy via a third party web server to preconfigured Mongrel instances. Just my 10 cents. - Lourens http://blog.methodmissing.com On 2006/12/13, at 01:47, Michael Henry wrote:> > Greg Donald wrote: >> On 12/12/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >>> It''s not that they can''t execute anything. It means they can''t have >>> executables in their home dirs. >>> >> >> And why is that bad again? >> >> I''d hate to know I couldn''t execute my own backup.sh in my own ~ > Presumably /bin/sh is on another partition so "/bin/sh backup.sh" > would > work fine. > > I''m just playing devil''s advocate ;) > > Back to the issue at hand: I am currently developing a Rails app > which I > will be deploying in the next month or so. I was intending to use > Apache > webserver because I am familiar with it but the comments in this > thread > prompted me to take a look at Mongrel. > > It appears that Mongrel doesn''t support SSL and "...will break down > pretty quick if you have lots of people accessing Rails actions > that are > slow." How can anyone seriously propose Mongrel for a production > setup? > It appears that Mongrel is just a cut-down and easy-to-use > webserver for > the kiddies who don''t want to learn Apache. The documentation makes > numerous statements like "Apache is notorious for having a horribly > complex configuration file." What a load of bullshit! Sure, there are > lots of directives which can be a bit overwhelming for the newbie, but > break it down and look at each directive individually and it makes > perfect sense. There are some great books out there to help. > > So to Andre, who started this thread: I''ll be trying mod_ruby so > there''s > one more for the user base :) > > > > > >--~--~---------~--~----~------------~-------~--~----~ 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 12/12/06, Michael Henry <michael.k.henry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> It appears that Mongrel doesn''t support SSL and "...will break down > pretty quick if you have lots of people accessing Rails actions that are > slow." How can anyone seriously propose Mongrel for a production setup?That may be from the documentation, I''m not sure. Anyway, you''re right that it doesn''t support SSL. Not sure why you''d need/want it to. Mongrel, as far as I know, was developed from the ground up to be a Rails server. If you need stuff like SSL, you use a web server that supports SSL and uses mod_proxy to talk to Mongrel. Which it sounds like you have in Apache ;) If you only have one Mongrel process, then yeah it''ll choke on multiple requests to slow-running pages. That certainly doesn''t seem like a fault of Mongrel though...any time you have a single thread of access and really slow code you''re going to have trouble. Now for my experience...I''ve been running pregopoker.com for the past 6 months, and it''s using Apache with mod_proxy to Mongrel. All the static stuff is handled by Apache, as well as the SSL. I run it on three mongrel processes, and it handles 80k requests/day with no problem, the vast majority of them being handled by Mongrel. 80k isn''t even a request/second...I''m not going to get into detailed stats and standard deviations like Zed wants, mainly cause I just don''t care :) Mongrel runs great for my config. I''d have to say that most pages are relatively slow...each request results in some fairly complex math going on in the background. I can almost assure you that all my pages run slower than yours will, and I''ve never run into a problem with Mongrel breaking down under heavy access. Mongrel''s also never crashed on me. Not once. Long story short, Mongrel is not for kiddies. Mongrel is perfect for hosting Rails apps, and runs great behind a full-featured webserver for handling the other duties. Pat --~--~---------~--~----~------------~-------~--~----~ 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 12/12/06, Michael Henry <michael.k.henry-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> So to Andre, who started this thread: I''ll be trying mod_ruby so there''s > one more for the user base :)Heh, nice Michael :) I guess I should just try mongrel too and see how it goes compared to mod_ruby. Anyone has hints on how to set up mongrel_cluster to serve in a shared hosting environment? Can I set up a single cluster that will receive connections to the different applications as needed, or do I have to pre-allocate a static number of intances for each virtual host? Also, what''s a good way to calculate the needed number of mongrel instances I''ll need? For example, in a mod_php server here there are 48 instances of Apache running simultaneously. If this was a rails server with mongrel, would I need 48 instances of mongrel? Can this be made dynamically (i.e., mongrel creates more instances as needed)? Pointers to the appropriate docs would be great. I''ve searched them and the list though, and couldn''t find much stuff related to shared hosting. Thanks to all for the opinions. Andre --~--~---------~--~----~------------~-------~--~----~ 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 12/13/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I guess I should just try mongrel too and see how it goes compared to > mod_ruby. Anyone has hints on how to set up mongrel_cluster to serve > in a shared hosting environment? Can I set up a single cluster that > will receive connections to the different applications as needed, or > do I have to pre-allocate a static number of intances for each virtual > host?No, Mongrel loads up the entire application environment. So a mongrel process can only handle one application. You specify how many processes per app in your config file.> Also, what''s a good way to calculate the needed number of mongrel > instances I''ll need? For example, in a mod_php server here there are > 48 instances of Apache running simultaneously. If this was a rails > server with mongrel, would I need 48 instances of mongrel? Can this be > made dynamically (i.e., mongrel creates more instances as needed)?There''s no way you need that many. Basically the only way to do this is config and test. Start up two mongrel processes, hammer away at your app, gather stats, and see if you need more. As I said in an earlier email, I''ve got 3 processes handling 80k requests/day on slow code, and it runs great. In http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html Zed covers a process for determining the ideal number of mongrels. If you google "how many mongrels" you''ll find plenty of info. Pat --~--~---------~--~----~------------~-------~--~----~ 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 12/13/06, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> No, Mongrel loads up the entire application environment. So a mongrel > process can only handle one application. You specify how many > processes per app in your config file.Does that mean that if I have 10 applications, I''d need 10 separete mongrel_clusters, each running a given (pre-configured) number of mongrel instances?> In http://rubyforge.org/pipermail/mongrel-users/2006-May/000200.html > Zed covers a process for determining the ideal number of mongrels. If > you google "how many mongrels" you''ll find plenty of info.Thanks, I''ll check it out. Andre --~--~---------~--~----~------------~-------~--~----~ 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 12/13/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 12/13/06, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > No, Mongrel loads up the entire application environment. So a mongrel > > process can only handle one application. You specify how many > > processes per app in your config file. > > Does that mean that if I have 10 applications, I''d need 10 separete > mongrel_clusters, each running a given (pre-configured) number of > mongrel instances?Yes --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Pat Maddox wrote:> On 12/13/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> Does that mean that if I have 10 applications, I''d need 10 separete >> mongrel_clusters, each running a given (pre-configured) number of >> mongrel instances? > > YesWhich is nice - you can run a different mongrel_cluster for each hosting client, giving clean privilege separation by user account. A simpler suexec, as it were. One concern I have about proxying to backend processes is SSL connections - given that mongrel doesn''t support SSL, your previously SSL''d data is getting passed to your backend processes in plain text. A malicious user on the same machine could sniff this proxied traffic as it goes to your backend and do Bad Things. I still haven''t heard a satisfactory solution to this one. . . -DJCP -- 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 -~----------~----~----~----~------~----~------~--~---
> > One concern I have about proxying to backend processes is SSL > connections - given that mongrel doesn''t support SSL, your previously > SSL''d data is getting passed to your backend processes in plain text. A > malicious user on the same machine could sniff this proxied traffic as > it goes to your backend and do Bad Things. I still haven''t heard a > satisfactory solution to this one. . . > > > That''s a valid point. However you have to remember that those are somewhatrare cases. Your backends should be firewalled off and well protected from the outside world. If you have a malicious user in that backend machine, you''re not going to be protected just because you have encrypted the traffic. He''ll have your logs, passwords, etc. :) On 12/13/06, Daniel Collis-puro <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > > Pat Maddox wrote: > > On 12/13/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Does that mean that if I have 10 applications, I''d need 10 separete > >> mongrel_clusters, each running a given (pre-configured) number of > >> mongrel instances? > > > > Yes > > Which is nice - you can run a different mongrel_cluster for each hosting > client, giving clean privilege separation by user account. A simpler > suexec, as it were. > > One concern I have about proxying to backend processes is SSL > connections - given that mongrel doesn''t support SSL, your previously > SSL''d data is getting passed to your backend processes in plain text. A > malicious user on the same machine could sniff this proxied traffic as > it goes to your backend and do Bad Things. I still haven''t heard a > satisfactory solution to this one. . . > > -DJCP > > > -- > 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 12/13/06, Daniel Collis-puro <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Which is nice - you can run a different mongrel_cluster for each hosting > client, giving clean privilege separation by user account. A simpler > suexec, as it were.The problem I see with that is that if the number of accounts on the server is large, there''ll be need for a large number of mongrel instances, and if you consider that a good share of these accounts won''t have high traffic, you''d have a lot of instances using server resources but not serving anything most of the time. I think that, in some situations, a single pool of mongrel instances would be a better solution, although I believe it''s not currently possible to use mongrel like that. Andre --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
That is why you test for performance. Every app doesn''t NEED 10 instances of Mongrel. Many are fine with 2 or 3. You need to do performance testing and determine your own needs. Throw out what you know about serving web applications because it''s just going to get in the way... Rails doesn''t work like that. Some apps need only one instance of mongrel because they rely on page caching which Apache handles nicely. Some need 10 because they are really heavy applications with long-running processes. PlanetArgon (good host for Rails) manages to allow each user a port range where they can run their Mongrel instances. So it''s not a real problem if you have a lot of accounts on the machine. On 12/14/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > On 12/13/06, Daniel Collis-puro <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote: > > Which is nice - you can run a different mongrel_cluster for each hosting > > client, giving clean privilege separation by user account. A simpler > > suexec, as it were. > > The problem I see with that is that if the number of accounts on the > server is large, there''ll be need for a large number of mongrel > instances, and if you consider that a good share of these accounts > won''t have high traffic, you''d have a lot of instances using server > resources but not serving anything most of the time. > > I think that, in some situations, a single pool of mongrel instances > would be a better solution, although I believe it''s not currently > possible to use mongrel like that. > > Andre > > > >--~--~---------~--~----~------------~-------~--~----~ 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 12/14/06, Brian Hogan <bphogan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> That is why you test for performance. Every app doesn''t NEED 10 instances of > Mongrel. Many are fine with 2 or 3. You need to do performance testing and > determine your own needs. Throw out what you know about serving web > applications because it''s just going to get in the way... Rails doesn''t work > like that. Some apps need only one instance of mongrel because they rely on > page caching which Apache handles nicely. Some need 10 because they are > really heavy applications with long-running processes.But if you have 100 accounts that''s 100 mongrels at least, more likely 200 or 300. If running 300 mongrels at the same time works fine, then excellent! I''m just trying to learn from other people''s experiences doing shared hosting with mongrel. Best regards, Andre --~--~---------~--~----~------------~-------~--~----~ 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 12/14/06, Andre Nathan <andre.nathan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > On 12/14/06, Brian Hogan <bphogan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > That is why you test for performance. Every app doesn''t NEED 10 instances of > > Mongrel. Many are fine with 2 or 3. You need to do performance testing and > > determine your own needs. Throw out what you know about serving web > > applications because it''s just going to get in the way... Rails doesn''t work > > like that. Some apps need only one instance of mongrel because they rely on > > page caching which Apache handles nicely. Some need 10 because they are > > really heavy applications with long-running processes. > > But if you have 100 accounts that''s 100 mongrels at least, more likely > 200 or 300. If running 300 mongrels at the same time works fine, then > excellent! I''m just trying to learn from other people''s experiences > doing shared hosting with mongrel.May I ask what you''re actually doing? From your original post I thought you were just planning on deploying an application...where is this 100 accounts all running 2-3 mongrels figure coming from? If you''re just concerned about a shared host being overloaded, it''d be far more appropriate to ask current customers what their experiences with a particular host is. You can even ask the host how many accounts are on the server, what the average load is like, what policy they have on resource abuse, etc. Mongrel truly is the best way to deploy Rails apps right now. I''m not sure what you''re looking for, but it looks like the wrong thing... Perhaps you''re planning on starting your own Rails shared hosting? If that''s the case, there''s no way around the fact that Rails takes up more resources than shared PHP does, so you won''t be able to cram 1k accounts onto a server like you could with PHP. Just the way it is. Pat Pat --~--~---------~--~----~------------~-------~--~----~ 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 12/14/06, Pat Maddox <pergesu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> May I ask what you''re actually doing? From your original post I > thought you were just planning on deploying an application...where is > this 100 accounts all running 2-3 mongrels figure coming from?It''ll be a server for shared rails hosting. I''m just trying to find out what are the current alternatives for such a setup, given the restrictions I mentioned on the first post (have to use apache, user data is in a noexec partition). Of course, I know rails will use more resources than PHP, that''s totally expected. One of the reasons that a shared server with lots of PHP accounts works is the fact that a lot (most?) of the virtual hosts have such a low usage that they have little impact on the server performance, since apache doesn''t pre-allocate resources tied to specific virtual hosts. I''m not attacking mongrel or anything like that. I''m just trying to understand how it works to decide if it''s the right solution for me. Regards, Andre --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Can you quantify "lots"? Here''s the uptime for one of my most heavily loaded shared hosts: 12:43:21 up 1 day, 4:50, 3 users, load average: 0.96, 0.56, 0.43 Not exactly terrifying, eh? On Dec 14, 2006, at 7:10 AM, Andre Nathan wrote:> One of the reasons that a shared server with lots of > PHP accounts works is the fact that a lot (most?) of the virtual hosts > have such a low usage that they have little impact on the server > performance--~--~---------~--~----~------------~-------~--~----~ 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, I know rails will use more resources than PHP, that''s > totally expected. One of the reasons that a shared server with lots of > PHP accounts works is the fact that a lot (most?) of the virtual hosts > have such a low usage that they have little impact on the server > performance, since apache doesn''t pre-allocate resources tied to > specific virtual hosts. > > I''m not attacking mongrel or anything like that. I''m just trying to > understand how it works to decide if it''s the right solution for me.Resource wise mongrel and mod ruby will probably be about the same, but only if you run a mod ruby enabled apache behind another apache that serves your static content. Every apache process is going to have the ruby interpreter loaded. Mod ruby might not even work in a shared environment either. Can it run multiple rails applications in a single apache process? Might want to check that out. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---