Re: [Rails] Delayed methods

I'm just about to scale to a second app server - so good timing

in which ways did you find cron to be a poor choice ? on a single server they meet our needs nicely

you'd only run one clock instance per cluster - so much like cron (ie. no interserver clock scheduling). Have you tried using clock driven from a schedule described in the db (like a centralized cron, useful for failover) ?

Any thoughts you have on this topic appreciated

As for the OP, I hope they can see the short and long term options before them.

J

On Sat, Mar 23, 2013 at 2:01 PM, tamouse mailing lists <tamouse.lists@gmail.com> wrote:

Please bottom post (appending). It makes responses easier to find.

On Sat, Mar 23, 2013 at 10:32 AM, Jodi Showers <jodi@homestars.com> wrote:
> 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 <clanlaw@googlemail.com> wrote:
>>
>> On 23 March 2013 15:15, Jodi Showers <jodi@homestars.com> 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 rubyonrails-talk+unsubscribe@googlegroups.com.
>> To post to this group, send email to rubyonrails-talk@googlegroups.com.
>> 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 rubyonrails-talk+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-talk@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

If you're working in a distributed, multi-server and multi-process
environment, cron is a poor solution. DelayedJobs and several others
work in a distributed environment much better. I have been using the
gem clockwork in addition to DJ, which makes things very simple.

--
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 rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
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 rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.