Hi all - I managed to get a rails app up and running with FastCGI and Apache2 on a Red Hat EL3 box. Thanks for the earlier tips and suggestions. I''d like to add 5-6 more rails apps to the server under other virtual hosts. I''m fairly sure this will be straight forward: I''ll add a FastCgiServer ... line for each and set up the virtual host. The question is, how many static processes should I be allocating per site/app? I expect the traffic to be pretty low on each of these apps, the server has a ~2.5Ghz processor, 1GB RAM, and is running the MySQL DB that is powering each of these sites. I''ve read that 1 is too low for anything and that 10 should be plenty for a dedicated server. (Which I''m guessing assumes 1 rails app) Any suggested guidelines here? Perhaps start with 2 processes for each and add more (and possibly more RAM) as use increases? Thanks!
I tried your exact setup, but stability was a nightmare. Memory leaks, fastcgi not responding. Ten processes would run well over 500 megs of ram after a few hours. I couldn''t keep the server up for more than a day or so at a time. I''ve been experimenting with other things, and so far, I have been having a good experience with SCGI. Just thought I''d give you a heads up. As far as processes go you should probably go with at least 2-3, so that if one crashes, you have more ready to go. From a load standpoint, one process per 10 req/sec at peak sounds about right. If you manage to get things stable, let me know. Kyle Maxwell On 9/30/05, cleaner416 <cleaner416-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Hi all - I managed to get a rails app up and running with FastCGI and > Apache2 on a Red Hat EL3 box. Thanks for the earlier tips and > suggestions. > > I''d like to add 5-6 more rails apps to the server under other virtual > hosts. I''m fairly sure this will be straight forward: I''ll add a > FastCgiServer ... line for each and set up the virtual host. > > The question is, how many static processes should I be allocating per > site/app? I expect the traffic to be pretty low on each of these > apps, the server has a ~2.5Ghz processor, 1GB RAM, and is running the > MySQL DB that is powering each of these sites. I''ve read that 1 is > too low for anything and that 10 should be plenty for a dedicated > server. (Which I''m guessing assumes 1 rails app) > > Any suggested guidelines here? Perhaps start with 2 processes for > each and add more (and possibly more RAM) as use increases? > > Thanks! > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Thanks for the heads up - I''ve had the single app with 5 processes running for the past 4 days now, no sign memory leaks and so far very stable. (Then again, hardly any usage) I went through quite a process to get things going however - lots of building from source. I didn''t get anything from up2date, including Ruby. I also did not install the fcgi gem via the gem installer - compiled that one too. I can send you my notes if you think it would help, but it sounds like you''ve moved on to SCGI. On Sep 30, 2005, at 3:11 PM, Kyle Maxwell wrote:> I tried your exact setup, but stability was a nightmare. Memory > leaks, fastcgi not responding. Ten processes would run well over 500 > megs of ram after a few hours. I couldn''t keep the server up for more > than a day or so at a time. I''ve been experimenting with other > things, and so far, I have been having a good experience with SCGI. > Just thought I''d give you a heads up. > > As far as processes go you should probably go with at least 2-3, so > that if one crashes, you have more ready to go. From a load > standpoint, one process per 10 req/sec at peak sounds about right. > > If you manage to get things stable, let me know. > > Kyle Maxwell > > On 9/30/05, cleaner416 <cleaner416-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Hi all - I managed to get a rails app up and running with FastCGI and >> Apache2 on a Red Hat EL3 box. Thanks for the earlier tips and >> suggestions. >> >> I''d like to add 5-6 more rails apps to the server under other virtual >> hosts. I''m fairly sure this will be straight forward: I''ll add a >> FastCgiServer ... line for each and set up the virtual host. >> >> The question is, how many static processes should I be allocating per >> site/app? I expect the traffic to be pretty low on each of these >> apps, the server has a ~2.5Ghz processor, 1GB RAM, and is running the >> MySQL DB that is powering each of these sites. I''ve read that 1 is >> too low for anything and that 10 should be plenty for a dedicated >> server. (Which I''m guessing assumes 1 rails app) >> >> Any suggested guidelines here? Perhaps start with 2 processes for >> each and add more (and possibly more RAM) as use increases? >> >> Thanks! >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
David Heinemeier Hansson
2005-Oct-02 01:00 UTC
Re: Apache2 + FastCGI: number of static processes?
> I tried your exact setup, but stability was a nightmare. Memory > leaks, fastcgi not responding.FastCGI and Apache 2 has often been reported to be a troublesome cocktail. At 37signals, we''re running FastCGI with Apache 1.3.x (on FreeBSD). Pretty darn stable. And with the latest restarting code in the RailsFCGIHandler in the trunk, it''s also a lot smoother to push new updates.> As far as processes go you should probably go with at least 2-3, so > that if one crashes, you have more ready to go. From a load > standpoint, one process per 10 req/sec at peak sounds about right.You can also make sure to have a spinner running to ensure that if a FCGI process should go down that it''ll be started again (on edge rails, you can read about the spinner with "./script/run process spinner --help"). -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 1, 2005, at 6:00 PM, David Heinemeier Hansson wrote:>> I tried your exact setup, but stability was a nightmare. Memory >> leaks, fastcgi not responding. > > FastCGI and Apache 2 has often been reported to be a troublesome > cocktail. At 37signals, we''re running FastCGI with Apache 1.3.x (on > FreeBSD). Pretty darn stable. And with the latest restarting code in > the RailsFCGIHandler in the trunk, it''s also a lot smoother to push > new updates.Also: use mod_fcgid rather than mod_fastcgi on Apache2.>> As far as processes go you should probably go with at least 2-3, so >> that if one crashes, you have more ready to go. From a load >> standpoint, one process per 10 req/sec at peak sounds about right.http://weblog.textdrive.com/article/156/putting-lighttpd-fcgi-into-a- traffic-context "Alistapart.com did about 5 million hits in two and half days and it did that on the default *4* dispatch.fcgi processes." Regards, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDP1lmAQHALep9HFYRAs/FAKCNokVb/k7inW3J/+jZxJtA0WcOIQCeKgzD zvJlBIPMpBY+u1I1fRULBWY=Qi8i -----END PGP SIGNATURE-----
On 10/1/05, cleaner416 <cleaner416-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: ...> Any suggested guidelines here? Perhaps start with 2 processes for > each and add more (and possibly more RAM) as use increases?Start with one FastCGI process per application, and if performance starts to suffer try increasing to two or three processes. Unless you''re running something extremely heavy with traffic you won''t need more than three processes. I''ve found one process is usually more than adequate (in fact, I''ve never yet had to increase an app past one process). Further, with each extra process you run you consume a considerable amount of additional memory, so if your server starts to run low on memory then increasing the number of processes may have a detrimental effect on performance. It''s really a matter of just experimenting and finding what works best for your application(s). Ben
Thanks for the tips. I actually tried FastCGI and Apache 1.3.x on Freebsd and all of the upload/progress functionality stopped working properly. I saw this post http://sean.treadway.info/articles/2005/07/06/rails-0-13-with-upload- progress regarding upload instability on FreeBSD and decided to steer clear of the platform for a bit. I didn''t have it available to me in a production environment anyway. Why use mod_fcgid rather than mod_fastcgi? Finally, regarding the latest ''restarting'' code in Rails - I''ve been applying patches via svn and and simply restarting Apache, and then just killing off the old dispatch.fcgi pids. Is this the way to go or is there some other restart script that you are referring to? Thanks again... On Oct 1, 2005, at 11:52 PM, Jeremy Kemper wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Oct 1, 2005, at 6:00 PM, David Heinemeier Hansson wrote: > >>> I tried your exact setup, but stability was a nightmare. Memory >>> leaks, fastcgi not responding. >>> >> >> FastCGI and Apache 2 has often been reported to be a troublesome >> cocktail. At 37signals, we''re running FastCGI with Apache 1.3.x (on >> FreeBSD). Pretty darn stable. And with the latest restarting code in >> the RailsFCGIHandler in the trunk, it''s also a lot smoother to push >> new updates. >> > > Also: use mod_fcgid rather than mod_fastcgi on Apache2. > > > >>> As far as processes go you should probably go with at least 2-3, so >>> that if one crashes, you have more ready to go. From a load >>> standpoint, one process per 10 req/sec at peak sounds about right. >>> > > http://weblog.textdrive.com/article/156/putting-lighttpd-fcgi-into- > a-traffic-context > > "Alistapart.com did about 5 million hits in two and half days and > it did that on the default *4* dispatch.fcgi processes." > > Regards, > jeremy > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (Darwin) > > iD8DBQFDP1lmAQHALep9HFYRAs/FAKCNokVb/k7inW3J/+jZxJtA0WcOIQCeKgzD > zvJlBIPMpBY+u1I1fRULBWY> =Qi8i > -----END PGP SIGNATURE----- > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Julian ''Julik'' Tarkhanov
2005-Oct-02 18:17 UTC
Re: Apache2 + FastCGI: number of static processes?
On 2-okt-2005, at 19:29, cleaner416 wrote:> > Why use mod_fcgid rather than mod_fastcgi?mod_fastcgi does not kill fcgi instances when they run amok (and they do), and starts another instance if all slots are busy. This way you start getting more and more fcgi processes until your system thrashes. This is surely the case with dynamic spawning (a real mess with FCGI) and also the case with static spawning (if FCGI instance starts throwing 500 errors it just sits there and never gets restarted). mod_fcgid kills dispatchers reliably. Given that, I was unable to compile mod_fcgid on the Mac (hate that...) so I just went with lighty both for testing and deployment. -- Julian "Julik" Tarkhanov
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Oct 2, 2005, at 10:29 AM, cleaner416 wrote:> Why use mod_fcgid rather than mod_fastcgi?mod_fcgid is written for the Apache2 API whereas mod_fastcgi was written for Apache1 and must run through Apache2''s compatibility layer.> Finally, regarding the latest ''restarting'' code in Rails - I''ve > been applying patches via svn and and simply restarting Apache, and > then just killing off the old dispatch.fcgi pids. Is this the way > to go or is there some other restart script that you are referring to?See scripts/process/* Regards, jeremy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDQGeiAQHALep9HFYRAkwMAKCNZQSWsimtVRzyABPhhxwRKN+PpgCgiXT3 S9WO8tSCLNWhcEJbxLnD3iU=uyD4 -----END PGP SIGNATURE-----
* David Heinemeier Hansson [2005-10-02 03:21]:> > I tried your exact setup, but stability was a nightmare. Memory > > leaks, fastcgi not responding. > > FastCGI and Apache 2 has often been reported to be a troublesome > cocktail. At 37signals, we''re running FastCGI with Apache 1.3.x (on > FreeBSD). Pretty darn stable. And with the latest restarting code in > the RailsFCGIHandler in the trunk, it''s also a lot smoother to push > new updates.I''d be interested to know if you and/or any other core Rails-folk have any future plans regarding deployment, or just plan on sticking with what works, which at this point looks primarily like apache 1.3.x? i.e. if there''s any plans to deal with the ugly bits connecting Rails to the outside world -- or to let evolution take its course and see what emerges, perhaps SCGI for example? My main motivation for asking is my current employer uses a supported linux distro that ships with apache2, as do many other companies. Getting Rails setup on the stock apache would be mighty helpful in getting Rails through the door... (but the persistent "apache2-Rails considered troublesome" threads are a bit discouraging.) -- ________________________________ toddgrimason*todd[ at ]slack.net
Convincing argument - so I thought I would give mod_fcgid a shot...
... but documentation for this is very sparse and I''m stuck. I
compiled and installed ok. (It seems) However I can''t get my
httpd.conf to work. Used this for mod_fastcgi:
LoadModule fcgid_module modules/mod_fastcgi.so
...
<IfModule mod_fcgid.c>
FastCgiIpcDir /tmp/fcgi_ipc/
AddHandler fastcgi-script .fcgi
# one of these for each vhosted rails app
FastCgiServer /data/wwwroot/appone.lan/public/dispatch.fcgi -
idle-timeout 60 -initial-env LD_LIBRARY_PATH=/usr/local/lib -initial-
env RAILS_ENV=production -processes 2
FastCgiServer /data/wwwroot/apptwo.lan/public/dispatch.fcgi -
idle-timeout 60 -initial-env LD_LIBRARY_PATH=/usr/local/lib -initial-
env RAILS_ENV=production -processes 2
</IfModule>
...
NameVirtualHost 10.0.0.50:80
<VirtualHost 10.0.0.50:80>
DocumentRoot /data/wwwroot/appone.lan/public
ServerName appone.lan
</VirtualHost>
<VirtualHost 10.0.0.50:80>
DocumentRoot /data/wwwroot/apptwo.lan/public
ServerName apptwo.lan
</VirtualHost>
...
What would I use to do equivalent in mod_fcgid? (Struck out
guessing, by the way, after the LoadModule line and AddHandler)
TIA!
On Oct 2, 2005, at 2:17 PM, Julian ''Julik'' Tarkhanov wrote:
>
> On 2-okt-2005, at 19:29, cleaner416 wrote:
>
>>
>> Why use mod_fcgid rather than mod_fastcgi?
>>
>
> mod_fastcgi does not kill fcgi instances when they run amok (and
> they do), and starts another instance if all slots are busy. This
> way you start getting more and more fcgi processes until your
> system thrashes.
> This is surely the case with dynamic spawning (a real mess with
> FCGI) and also the case with static spawning (if FCGI instance
> starts throwing 500 errors it just sits there and never gets
> restarted).
>
> mod_fcgid kills dispatchers reliably.
>
> Given that, I was unable to compile mod_fcgid on the Mac (hate
> that...) so I just went with lighty both for testing and deployment.
>
> --
> Julian "Julik" Tarkhanov
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
I couldn''t compile... so not much help from me.. On 10/3/05, cleaner416 <cleaner416-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Convincing argument - so I thought I would give mod_fcgid a shot... > > ... but documentation for this is very sparse and I''m stuck. I > compiled and installed ok. (It seems) However I can''t get my > httpd.conf to work. Used this for mod_fastcgi: > > LoadModule fcgid_module modules/mod_fastcgi.so > ... > <IfModule mod_fcgid.c> > FastCgiIpcDir /tmp/fcgi_ipc/ > AddHandler fastcgi-script .fcgi > # one of these for each vhosted rails app > FastCgiServer /data/wwwroot/appone.lan/public/dispatch.fcgi - > idle-timeout 60 -initial-env LD_LIBRARY_PATH=/usr/local/lib -initial- > env RAILS_ENV=production -processes 2 > FastCgiServer /data/wwwroot/apptwo.lan/public/dispatch.fcgi - > idle-timeout 60 -initial-env LD_LIBRARY_PATH=/usr/local/lib -initial- > env RAILS_ENV=production -processes 2 > </IfModule> > ... > NameVirtualHost 10.0.0.50:80 > <VirtualHost 10.0.0.50:80> > DocumentRoot /data/wwwroot/appone.lan/public > ServerName appone.lan > </VirtualHost> > <VirtualHost 10.0.0.50:80> > DocumentRoot /data/wwwroot/apptwo.lan/public > ServerName apptwo.lan > </VirtualHost> > ... > > What would I use to do equivalent in mod_fcgid? (Struck out > guessing, by the way, after the LoadModule line and AddHandler) > > TIA! > > On Oct 2, 2005, at 2:17 PM, Julian ''Julik'' Tarkhanov wrote: > > > > > On 2-okt-2005, at 19:29, cleaner416 wrote: > > > >> > >> Why use mod_fcgid rather than mod_fastcgi? > >> > > > > mod_fastcgi does not kill fcgi instances when they run amok (and > > they do), and starts another instance if all slots are busy. This > > way you start getting more and more fcgi processes until your > > system thrashes. > > This is surely the case with dynamic spawning (a real mess with > > FCGI) and also the case with static spawning (if FCGI instance > > starts throwing 500 errors it just sits there and never gets > > restarted). > > > > mod_fcgid kills dispatchers reliably. > > > > Given that, I was unable to compile mod_fcgid on the Mac (hate > > that...) so I just went with lighty both for testing and deployment. > > > > -- > > Julian "Julik" Tarkhanov > > > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >