that is a good thinking, just like normalization - then comes a time to denormalize
we have millions of visitors per month - and about 50 asynch processes - having one rails process deal with all those asynchs rather than one per is not helpful in any way using a best practice such as my approach is not harder to implement and will scale - choosing an approach of equal complexity that won't scale doesn't hold water On Sat, Mar 23, 2013 at 11:27 AM, Colin Law <[email protected]> wrote: > On 23 March 2013 15:15, Jodi Showers <[email protected]> wrote: > > for regularly scheduled jobs, I use a mixture of cron (to create a > delayed > > job), and the delayed_job itself > > > > the crontab instance is very light, just a small (non-rails) rb script to > > insert the delayed_job in the delayed_jobs table > > > > then the delayed_job instance will pickup the job and run it > > > > in your instance, I would create a class method on the Test model - > > something like > > > > def self.remove_old_unpublished > > delete_all(["created_at < ? and state in('unpublished')", > 24.hours.ago]) > > end > > > > cron entry like this: > > 05 1 * * * cd /path/to/current && RAILS_ENV=production > > /path/to/current/lib/delayed_job_cron_jobs/create_delayed_job.rb --model > > "Test" --method "remove_old_unpublished" --queue "general" --arguments > > "{:any_argument => 42}" > > > > the following gist is a script to insert delayed_jobs from cron > > https://gist.github.com/jshow/5228049 > > > > fyi, the reason to take this route over the simpler rake route (run rake > > task from cron) is performance and memory usage - this method will save > you > > a bunch of both. > > I am always suspicious of the idea of doing something in a more > complex way in order to save resources. It is only worth spending the > additional time developing the solution if computing resources are > likely to be an issue. Computing resources are usually cheaper than > human resources. > > Colin > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
