Часовой механизм требует своего собственного процесса?

Question

Я видел людей, которые говорили в нескольких разных местах, что часовой механизм должен запускаться на своем собственном динамо с прокфилем, который может выглядеть примерно так (пример из heroku):

clock: bundle exec clockwork lib/clock.rb

Есть ли причина не запускать его на том же динамо, что и рабочие? С процессом, который выглядит примерно так:

worker: bundle exec clockwork clock.rb & bundle exec sidekiq -C config/sidekiq.yml -L log/sidekiq.log

Кажется, это работает нормально, но я хотел бы знать причину, по которой люди говорят, что не следует так поступать. Любое руководство будет оценено. Заранее спасибо.

Answer 1

Недавно я начал запускать sidekiq и Clockwork бок о бок, вот так:

web: bundle exec puma -C config/puma.rb
worker: bundle exec clockwork clock.rb & bundle exec sidekiq & wait -n
# ^ https://help.heroku.com/CTFS2TJK/how-do-i-run-multiple-processes-on-a-dyno

И пока никаких проблем не наблюдается.... Это экономия 25 долларов в месяц для нас на хостинге heroku.

что произойдет, если умрут друзья? (@Anthony сказал)

Обычно sidekiq не умирает (по крайней мере, для меня), я думаю, это потому, что sidekiq только управляет вакансиями. Фактическая работа происходит в классах с методом perform(), и когда эти методы "вызывают / терпят неудачу", они не сбивают родительский элемент sidekiq вместе с ним. У Sidekiq есть графический интерфейс, который показывает очередь повторных попыток и мертвую очередь, поэтому мертвые задания оказываются в одном из этих мест.

Кстати, у Heroku есть статья о запуске нескольких заданий на одном "динамометрическом стенде":https://help.heroku.com/CTFS2TJK/how-do-i-run-multiple-processes-on-a-dyno

OP сказал:

Я видел, как люди говорили в паре разных мест

Мне было бы любопытно прочитать эти комментарии, если у вас есть ссылки.