On Sat, Mar 23, 2013 at 1:20 PM, Jodi Showers <j...@homestars.com> wrote:
> 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.li...@gmail.com> wrote:
>>
>> Please bottom post (appending). It makes responses easier to find.
>>
>> On Sat, Mar 23, 2013 at 10:32 AM, Jodi Showers <j...@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 <clan...@googlemail.com>
>> > wrote:
>> >>
>> >> On 23 March 2013 15:15, Jodi Showers <j...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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.
>
>
The primary issue when you bring in multiple servers is
synchronization of the workers. Cron can't do that, as it only knows
about one server. Having something that workers can distribute over
requires something more sophisticated. That's what DJ is really about.
Using clockwork makes it all the easier coming from cron.
--
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+unsubscr...@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.
