Does anyone have any experience with production deployment of RoR on Dreamhost? Is it now stable enough? Any tips and tricks? Thanks a lot, Tom
Tom:
I''m running a small app in production there... They did something crazy
to their FCGI sweeper a few months back but a nice fellow came up with a
hack but in order to use it you''ll need to freeze your rails so you can
modify the fcti_handler.
ruby/gems/1.8/gems/rails-1.0/lib/fcgi_handler.rb
Find this file and make the "exit_now_handler" method look like
this:
def exit_now_handler(signal)
dispatcher_log :info, \"asked to terminate immediately\"
## force to restart
dispatcher_log :info, \"but we will restart\"
restart_handler(signal)
#exit
end
Now my app basically stays alive and works pretty well. I haven''t
looked
into whether they have fixed anything out there or not, but this is my
solution.
-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Tom Taylor
Sent: Thursday, January 12, 2006 1:51 PM
To: rails@lists.rubyonrails.org
Subject: [Rails] Production deployment on Dreamhost?
Does anyone have any experience with production deployment of RoR on
Dreamhost? Is it now stable enough? Any tips and tricks?
Thanks a lot,
Tom
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails
Hogan, Brian P. wrote:> Tom: > > I''m running a small app in production there... They did something crazy > to their FCGI sweeper a few months back but a nice fellow came up with a > hack but in order to use it you''ll need to freeze your rails so you can > modify the fcti_handler.Thanks Brian, I''ll give that a shot when I try and deploy it this weekend. Tom
Christopher C. Phillips
2006-Jan-12 20:29 UTC
[Rails] Re: Production deployment on Dreamhost?
I also plan on deploying on Dreamhost within the next week. Let us know how it goes. :) -Chris On Jan 12, 2006, at 3:24 PM, Tom Taylor wrote:> Hogan, Brian P. wrote: >> Tom: >> I''m running a small app in production there... They did something >> crazy >> to their FCGI sweeper a few months back but a nice fellow came up >> with a >> hack but in order to use it you''ll need to freeze your rails so >> you can >> modify the fcti_handler. > > Thanks Brian, > > I''ll give that a shot when I try and deploy it this weekend. > > Tom > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Another solution that works the same way without the need to freeze gems
and hack the core.
http://discussion.dreamhost.com/showthreaded.pl?Cat=&Board=forum_program
ming&Number=36448&page=&view=&sb=&o=&vc=1#Post36448
--- snip -----
I changed my dispatch.fcgi to this. Something is sending the fastcgi
processes a kill ''TERM'' after five minutes. This makes the
rails app
ignore it and the fcgi process stays running.
require File.dirname(__FILE__) + "/../config/environment"
require ''fcgi_handler''
class MyRailsFCGIHandler < RailsFCGIHandler
SIGNALS = {
''TERM'' => :exit_now,
}
def exit_now_handler(signal)
dispatcher_log :info, "ignoring request to terminate immediately"
end
end
MyRailsFCGIHandler.process! nil, 50
--- snip ------
-----Original Message-----
From: rails-bounces@lists.rubyonrails.org
[mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Christopher C.
Phillips
Sent: Thursday, January 12, 2006 2:30 PM
To: rails@lists.rubyonrails.org
Subject: Re: [Rails] Re: Production deployment on Dreamhost?
I also plan on deploying on Dreamhost within the next week.
Let us know how it goes. :)
-Chris
On Jan 12, 2006, at 3:24 PM, Tom Taylor wrote:
> Hogan, Brian P. wrote:
>> Tom:
>> I''m running a small app in production there... They did
something
>> crazy
>> to their FCGI sweeper a few months back but a nice fellow came up
>> with a
>> hack but in order to use it you''ll need to freeze your rails
so
>> you can
>> modify the fcti_handler.
>
> Thanks Brian,
>
> I''ll give that a shot when I try and deploy it this weekend.
>
> Tom
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
_______________________________________________
Rails mailing list
Rails@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails
On Jan 12, 2006, at 1:10 PM, Hogan, Brian P. wrote:> Tom: > > I''m running a small app in production there... They did something > crazy > to their FCGI sweeper a few months back but a nice fellow came up > with a > hack but in order to use it you''ll need to freeze your rails so you > can > modify the fcti_handler. > > > ruby/gems/1.8/gems/rails-1.0/lib/fcgi_handler.rb > > Find this file and make the "exit_now_handler" method look like > this: > > def exit_now_handler(signal) > dispatcher_log :info, \"asked to terminate immediately\" > ## force to restart > dispatcher_log :info, \"but we will restart\" > restart_handler(signal) > #exit > end > > Now my app basically stays alive and works pretty well. I haven''t > looked > into whether they have fixed anything out there or not, but this is my > solution.Note that you can do this without freezing your rails. In your dispatch.fcgi, just after the ''require "fcgi_handler"'' bit, you can reopen the class and redefine the handler: class RailsFCGIHandler def exit_now_handler(signal) ... end end RailsFCGIHandler.process! Gotta love Ruby! - Jamis
Yup just figured that out... Do you think that this would solve the issue where my app sometimes takes 30-40 seconds to "start up" after it''s not been used for awhile? I''d hate for a client website to have to wait that long to serve up a search page or something. -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Jamis Buck Sent: Thursday, January 12, 2006 3:02 PM To: rails@lists.rubyonrails.org Subject: Re: [Rails] Production deployment on Dreamhost? On Jan 12, 2006, at 1:10 PM, Hogan, Brian P. wrote:> Tom: > > I''m running a small app in production there... They did something > crazy > to their FCGI sweeper a few months back but a nice fellow came up > with a > hack but in order to use it you''ll need to freeze your rails so you > can > modify the fcti_handler. > > > ruby/gems/1.8/gems/rails-1.0/lib/fcgi_handler.rb > > Find this file and make the "exit_now_handler" method look like > this: > > def exit_now_handler(signal) > dispatcher_log :info, \"asked to terminate immediately\" > ## force to restart > dispatcher_log :info, \"but we will restart\" > restart_handler(signal) > #exit > end > > Now my app basically stays alive and works pretty well. I haven''t > looked > into whether they have fixed anything out there or not, but this is my > solution.Note that you can do this without freezing your rails. In your dispatch.fcgi, just after the ''require "fcgi_handler"'' bit, you can reopen the class and redefine the handler: class RailsFCGIHandler def exit_now_handler(signal) ... end end RailsFCGIHandler.process! Gotta love Ruby! - Jamis _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
I face the same think when using rails on dreamhost with fcgi. The app needs to startup sometimes (and this takes a lot of cpu time)... Hogan, Brian P. wrote:> Yup just figured that out... > > Do you think that this would solve the issue where my app sometimes > takes 30-40 seconds to "start up" after it''s not been used for awhile? > I''d hate for a client website to have to wait that long to serve up a > search page or something. > > > > -----Original Message----- > From: rails-bounces@lists.rubyonrails.org > [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Jamis Buck > Sent: Thursday, January 12, 2006 3:02 PM > To: rails@lists.rubyonrails.org > Subject: Re: [Rails] Production deployment on Dreamhost? > > > On Jan 12, 2006, at 1:10 PM, Hogan, Brian P. wrote: > > >> Tom: >> >> I''m running a small app in production there... They did something >> crazy >> to their FCGI sweeper a few months back but a nice fellow came up >> with a >> hack but in order to use it you''ll need to freeze your rails so you >> can >> modify the fcti_handler. >> >> >> ruby/gems/1.8/gems/rails-1.0/lib/fcgi_handler.rb >> >> Find this file and make the "exit_now_handler" method look like >> this: >> >> def exit_now_handler(signal) >> dispatcher_log :info, \"asked to terminate immediately\" >> ## force to restart >> dispatcher_log :info, \"but we will restart\" >> restart_handler(signal) >> #exit >> end >> >> Now my app basically stays alive and works pretty well. I haven''t >> looked >> into whether they have fixed anything out there or not, but this is my >> solution. >> > > Note that you can do this without freezing your rails. In your > dispatch.fcgi, just after the ''require "fcgi_handler"'' bit, you can > reopen the class and redefine the handler: > > class RailsFCGIHandler > def exit_now_handler(signal) > ... > end > end > > RailsFCGIHandler.process! > > Gotta love Ruby! > > - Jamis > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > >
Abdur-Rahman Advany wrote:> I face the same think when using rails on dreamhost with fcgi. The app > needs to startup sometimes (and this takes a lot of cpu time)...I''m not sure about deployment on Dreamhost, but if I remember correctly I think there are maintenance things that you can do on your app to keep it running up to speed. I''m still noobish with Rails, but I think I read something about clearing your logs and files like that to keep Rails apps running faster. Might be an aside to the question, but I remembered it and thought it might be of note for other new Railers. Anyone have any more details/specifics on what I am talking about? -- Posted via http://www.ruby-forum.com/.
On Jan 12, 2006, at 3:05 PM, Hogan, Brian P. wrote:> Yup just figured that out... > > Do you think that this would solve the issue where my app sometimes > takes 30-40 seconds to "start up" after it''s not been used for awhile? > I''d hate for a client website to have to wait that long to serve up a > search page or something.This has come up several times on the list recently. The problem seems to be that the fcgi processes get paged out of memory after a while, causing a delay when they get swapped back in. A workaround would be to set up a cron job that uses wget to hit your site every few minutes. This''ll keep the process in memory so it''ll be more responsive. I haven''t had this problem myself, so I''m just parroting what I''ve heard elsewhere. YMMV. -dudley
Dudley Flanders wrote:> > On Jan 12, 2006, at 3:05 PM, Hogan, Brian P. wrote: > >> Yup just figured that out... >> >> Do you think that this would solve the issue where my app sometimes >> takes 30-40 seconds to "start up" after it''s not been used for awhile? >> I''d hate for a client website to have to wait that long to serve up a >> search page or something. > > > This has come up several times on the list recently. The problem seems > to be that the fcgi processes get paged out of memory after a while, > causing a delay when they get swapped back in. A workaround would be to > set up a cron job that uses wget to hit your site every few minutes. > This''ll keep the process in memory so it''ll be more responsive. I haven''t > had this problem myself, so I''m just parroting what I''ve heard elsewhere. > YMMV.There was a thread "Idle Apache+FastCGI sleeping?" in which Ezra Zygmuntowicz gave this advice: I have seen this behavior before. It seems to me that when the fcgi''s sit idle for too long they get paged out of memory. Then when you hit the site after its been idle, the fcgi''s have to page back into memory so hence the lag. The kludge that I use works great but I''d be interested if there was another way. But this technique works great in production for me. Just add a cron job that uses curl or wget to grab a page thats not cached(so it goes through rails) and send the output to /dev/null. If you have the cron job do this once every 5 minutes your fcgi''s will always be ''awake'' . And one hit every 5 minutes is virtually no extra load on the server. But by doing things this way, your site will always be snappy no matter how long it has been since a user visited the site.
I think Ezra should have a cron job to send out that email every 10 days... it seems to be a common problem. -----Original Message----- From: rails-bounces@lists.rubyonrails.org [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Justin Forder Sent: Thursday, January 12, 2006 8:45 PM To: rails@lists.rubyonrails.org Subject: Re: [Rails] Production deployment on Dreamhost? Dudley Flanders wrote:> > On Jan 12, 2006, at 3:05 PM, Hogan, Brian P. wrote: > >> Yup just figured that out... >> >> Do you think that this would solve the issue where my app sometimes >> takes 30-40 seconds to "start up" after it''s not been used for awhile? >> I''d hate for a client website to have to wait that long to serve up a >> search page or something. > > > This has come up several times on the list recently. The problem seems > to be that the fcgi processes get paged out of memory after a while, > causing a delay when they get swapped back in. A workaround would be to > set up a cron job that uses wget to hit your site every few minutes. > This''ll keep the process in memory so it''ll be more responsive. I haven''t > had this problem myself, so I''m just parroting what I''ve heard elsewhere. > YMMV.There was a thread "Idle Apache+FastCGI sleeping?" in which Ezra Zygmuntowicz gave this advice: I have seen this behavior before. It seems to me that when the fcgi''s sit idle for too long they get paged out of memory. Then when you hit the site after its been idle, the fcgi''s have to page back into memory so hence the lag. The kludge that I use works great but I''d be interested if there was another way. But this technique works great in production for me. Just add a cron job that uses curl or wget to grab a page thats not cached(so it goes through rails) and send the output to /dev/null. If you have the cron job do this once every 5 minutes your fcgi''s will always be ''awake'' . And one hit every 5 minutes is virtually no extra load on the server. But by doing things this way, your site will always be snappy no matter how long it has been since a user visited the site. _______________________________________________ Rails mailing list Rails@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Jan 12, 2006, at 8:49 PM, Tom Fakes wrote:> I think Ezra should have a cron job to send out that email every 10 > days... > it seems to be a common problem.Great Idea! lol -Ezra> > -----Original Message----- > From: rails-bounces@lists.rubyonrails.org > [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Justin > Forder > Sent: Thursday, January 12, 2006 8:45 PM > To: rails@lists.rubyonrails.org > Subject: Re: [Rails] Production deployment on Dreamhost? > > Dudley Flanders wrote: >> >> On Jan 12, 2006, at 3:05 PM, Hogan, Brian P. wrote: >> >>> Yup just figured that out... >>> >>> Do you think that this would solve the issue where my app sometimes >>> takes 30-40 seconds to "start up" after it''s not been used for >>> awhile? >>> I''d hate for a client website to have to wait that long to serve >>> up a >>> search page or something. >> >> >> This has come up several times on the list recently. The problem >> seems >> to be that the fcgi processes get paged out of memory after a while, >> causing a delay when they get swapped back in. A workaround would >> be to >> set up a cron job that uses wget to hit your site every few minutes. >> This''ll keep the process in memory so it''ll be more responsive. I >> haven''t >> had this problem myself, so I''m just parroting what I''ve heard >> elsewhere. >> YMMV. > > There was a thread "Idle Apache+FastCGI sleeping?" in which Ezra > Zygmuntowicz gave this advice: > > I have seen this behavior before. It seems to me that when the > fcgi''s sit idle for too long they get paged out of memory. Then when > you hit the site after its been idle, the fcgi''s have to page back > into memory so hence the lag. The kludge that I use works great but > I''d be interested if there was another way. But this technique works > great in production for me. > > Just add a cron job that uses curl or wget to grab a page thats not > cached(so it goes through rails) and send the output to /dev/null. If > you have the cron job do this once every 5 minutes your fcgi''s will > always be ''awake'' . And one hit every 5 minutes is virtually no extra > load on the server. But by doing things this way, your site will > always be snappy no matter how long it has been since a user visited > the site. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-Ezra Zygmuntowicz Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 ezra@yakima-herald.com
Good info here guys. I just deployed on Dreamhost as well, and everything ain''t so "dreamy". Hopefully these fixes will speed things up. Are you guys freezing edge or anything on there? I noticed on my box at least they were running an older version of rails. 0.14.3 I believe. On 1/13/06, Ezra Zygmuntowicz <ezra@yakima-herald.com> wrote:> > > On Jan 12, 2006, at 8:49 PM, Tom Fakes wrote: > > > I think Ezra should have a cron job to send out that email every 10 > > days... > > it seems to be a common problem. > > Great Idea! lol > > > -Ezra > > > > > > > -----Original Message----- > > From: rails-bounces@lists.rubyonrails.org > > [mailto:rails-bounces@lists.rubyonrails.org] On Behalf Of Justin > > Forder > > Sent: Thursday, January 12, 2006 8:45 PM > > To: rails@lists.rubyonrails.org > > Subject: Re: [Rails] Production deployment on Dreamhost? > > > > Dudley Flanders wrote: > >> > >> On Jan 12, 2006, at 3:05 PM, Hogan, Brian P. wrote: > >> > >>> Yup just figured that out... > >>> > >>> Do you think that this would solve the issue where my app sometimes > >>> takes 30-40 seconds to "start up" after it''s not been used for > >>> awhile? > >>> I''d hate for a client website to have to wait that long to serve > >>> up a > >>> search page or something. > >> > >> > >> This has come up several times on the list recently. The problem > >> seems > >> to be that the fcgi processes get paged out of memory after a while, > >> causing a delay when they get swapped back in. A workaround would > >> be to > >> set up a cron job that uses wget to hit your site every few minutes. > >> This''ll keep the process in memory so it''ll be more responsive. I > >> haven''t > >> had this problem myself, so I''m just parroting what I''ve heard > >> elsewhere. > >> YMMV. > > > > There was a thread "Idle Apache+FastCGI sleeping?" in which Ezra > > Zygmuntowicz gave this advice: > > > > I have seen this behavior before. It seems to me that when the > > fcgi''s sit idle for too long they get paged out of memory. Then when > > you hit the site after its been idle, the fcgi''s have to page back > > into memory so hence the lag. The kludge that I use works great but > > I''d be interested if there was another way. But this technique works > > great in production for me. > > > > Just add a cron job that uses curl or wget to grab a page thats not > > cached(so it goes through rails) and send the output to /dev/null. If > > you have the cron job do this once every 5 minutes your fcgi''s will > > always be ''awake'' . And one hit every 5 minutes is virtually no extra > > load on the server. But by doing things this way, your site will > > always be snappy no matter how long it has been since a user visited > > the site. > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > -Ezra Zygmuntowicz > Yakima Herald-Republic > WebMaster > http://yakimaherald.com > 509-577-7732 > ezra@yakima-herald.com > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- seth at subimage interactive http://www.subimage.com/sublog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060117/f111cbef/attachment.html
Tom, My experience has been great using rails on Dreamhost so far. I found that it was not the best place to fully deploy a rails environment, but if the development was done locally and the shared host with limited access - Dreamhost, just handled the live environment with the fastcgi I was fine. I wrote an article here http://topcweb.com/content/ruby-rails-setup Pretty much install instant rails locally and do your development there. Also feel free to contact me and I will share further. -- Posted via http://www.ruby-forum.com/.
On Thu, Jul 23, 2009 at 4:49 AM, Topper Nineten < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > Tom, > My experience has been great using rails on Dreamhost so far. I found > that it was not the best place to fully deploy a rails environment, but > if the development was done locally and the shared host with limited > access - Dreamhost, just handled the live environment with the fastcgi I > was fine. I wrote an article here > http://topcweb.com/content/ruby-rails-setup Pretty much install instant > rails locally and do your development there. Also feel free to contact > me and I will share further.My experience has also been very good with Dreamhost and I use Passenger instead of fastcgi. Good luck, -Conrad> > -- > 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 -~----------~----~----~----~------~----~------~--~---