I am currently running some background processes by using script/runner to run an infinite loop (with a sleep). I am considering moving this to a thread that is forked off of the environment file. This would be easier to maintain, because I wouldn''t have to start and stop it independently of my rails app. I was wondering: Does anyone knows any more pros and cons of this comparison? Thanks! Kyle Maxwell
Wouldn''t it be far better to set up a cron process that starts the background script/runner script on the period that you want? That would seem to be orders of magnitude more efficient than running an infinite loop... -Brian Kyle Maxwell wrote:> I am currently running some background processes by using > script/runner to run an infinite loop (with a sleep). I am > considering moving this to a thread that is forked off of the > environment file. This would be easier to maintain, because I > wouldn''t have to start and stop it independently of my rails app. I > was wondering: Does anyone knows any more pros and cons of this > comparison?
The startup costs of script/runner are not insignificant, so a loop with a sleep is nice for the CPU costs, but probably harder to maintain. Regards, Blair Brian V. Hughes wrote:> > Wouldn''t it be far better to set up a cron process that starts the > background script/runner script on the period that you want? That would > seem to be orders of magnitude more efficient than running an infinite > loop... > > -Brian > > Kyle Maxwell wrote: > >> I am currently running some background processes by using >> script/runner to run an infinite loop (with a sleep). I am >> considering moving this to a thread that is forked off of the >> environment file. This would be easier to maintain, because I >> wouldn''t have to start and stop it independently of my rails app. I >> was wondering: Does anyone knows any more pros and cons of this >> comparison? > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
Kyle, The biggest problem with what you want is that normal Rails runs fairly stateless, especially as a CGI. With a CGI you''ll never get it to work. I believe it''ll work in WEBrick, but I remember that WEBrick seemed to also kill off threads like Rails was a CGI. Under FastCGI or SCGI you could probably do it since they are long running processes, but you''ll have to setup your thread(s) outside of the Rails control, most likely with a global or similar (Singleton?) unique place. Another option--if you need better control from your Rails application--is to create a simple DRb API to your stand-alone processor. This kind of gives you the best of all worlds. The finaly problem I *know* you''ll run into is if this processor is supposed to be unique on a machine--where only one runs--then you''ll have huge problems in a clustering situation. Imagine it this way: You have your wonderful processor thread working great with 1 SCGI process. Now, you decide to speed up your app and start 4 SCGI processor, which also means you have 4 of your little processing threads running. In this situation, look to the DRb solution or just a simple cronjob. Zed A. Shaw http://www.zedshaw.com/ On Tue, 29 Nov 2005 11:14:34 -0800 Kyle Maxwell <kyle-FOSOgQihYpQjo0HpFSRKWA@public.gmane.org> wrote:> I am currently running some background processes by using > script/runner to run an infinite loop (with a sleep). I am > considering moving this to a thread that is forked off of the > environment file. This would be easier to maintain, because I > wouldn''t have to start and stop it independently of my rails app. I > was wondering: Does anyone knows any more pros and cons of this > comparison? > > Thanks! > Kyle Maxwell > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails