Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
А не лучше ли использовать старый добрый cron, который запускает rake задачи. И лишнюю память не будет занимать, и жутко стабилен, плюс время запуска заданий можно поинтереснее задавать =)
В каких то случаях лучше.
Но это вечный вопрос — что лучше иметь запускаемые по крону скрипты, постоянно отжирающие ресурсы во время запуска или иметь один запущенный демон съевший часть памяти на совсем постоянно. Если таймаут между задачами не большой — то проще запустить единожды и не париться, а в данном случае демоном еще и проще управлять.
Но это вечный вопрос — что лучше иметь запускаемые по крону скрипты, постоянно отжирающие ресурсы во время запуска или иметь один запущенный демон съевший часть памяти на совсем постоянно. Если таймаут между задачами не большой — то проще запустить единожды и не париться, а в данном случае демоном еще и проще управлять.
В данном случае плюс в том, что регулярные задачи описываются в коде приложения, всегда на виду, никуда не потеряются, не забудутся. Но если хочется именно cron, есть еще Whenever
Ну так rake задачи тоже же в коде приложения. И Расписание для крона тоже храниться в текстовом файле и при деплое через капистрано новое расписание автоматом заливается в крон.
И заодно, отвечу здесь на ответ выше: полностью согласен, если время запуска менее пяти минут, то лучше писать демона. Мы используем вот этот gem.
И заодно, отвечу здесь на ответ выше: полностью согласен, если время запуска менее пяти минут, то лучше писать демона. Мы используем вот этот gem.
cron это очень хороший вариант для редких задач. Есть два недостатка:
1) по крону не будешь запускать частые задачи, такие, например, как ежеминутный опрос твиттера, иначе большая часть ресурсов процессора будет уходить на запуск задач, а не на их выполнение;
2) если кроновские задачи вдруг начали подвисать (сеть подводит или просто стали сложнее и длительнее) и время их выполнение превышает частоту запуска. Например задача запускается каждые 10 минут, а длительность выполнения начала превышать 11 минут, то через некоторое время вы получите память забитую зависшими тасками со всеми вытекающими последствиями.
Есть два способа выполнения периодических задач — по крону и демоном. У каждого способа есть свои достоинства и недостатки.
1) по крону не будешь запускать частые задачи, такие, например, как ежеминутный опрос твиттера, иначе большая часть ресурсов процессора будет уходить на запуск задач, а не на их выполнение;
2) если кроновские задачи вдруг начали подвисать (сеть подводит или просто стали сложнее и длительнее) и время их выполнение превышает частоту запуска. Например задача запускается каждые 10 минут, а длительность выполнения начала превышать 11 минут, то через некоторое время вы получите память забитую зависшими тасками со всеми вытекающими последствиями.
Есть два способа выполнения периодических задач — по крону и демоном. У каждого способа есть свои достоинства и недостатки.
1) правильно, т.к. такие задачи засовываются в Resque github.com/defunkt/resque
2) — хрень которая лечится
require 'timeout'
begin
Timeout::timeout(10*60) {
ваши медленные и подвисающие запросы
}
rescue Timeout::Error
puts «вывалились по таймауту»
end
2) — хрень которая лечится
require 'timeout'
begin
Timeout::timeout(10*60) {
ваши медленные и подвисающие запросы
}
rescue Timeout::Error
puts «вывалились по таймауту»
end
О, кстати, насчет resque.
Правильно понимаю что для того чтобы с ним выполнять какие-то типовые задачи периодически, например каждые 5 минут, нужно запустить redis-сервер, reqsue-сервер и еще какую-то нибудь хрень (хотя бы по крону) которая будет эти задачи периодически пихать в очередь?
Правильно понимаю что для того чтобы с ним выполнять какие-то типовые задачи периодически, например каждые 5 минут, нужно запустить redis-сервер, reqsue-сервер и еще какую-то нибудь хрень (хотя бы по крону) которая будет эти задачи периодически пихать в очередь?
единственная разница между resque и вашим методом это наличиее redis'а
там все так же управляемые демоны, которые можно разбить по очередям например zip_queue, twitter_queue и запускать любое колличество ворокеров для каждой.
что же до цикличного выполнения каждые 5 минут, можно поставить плагин
github.com/bvandenbos/resque-scheduler
ваш способ хорош, но только при одной фоновой задаче, при двух уже появляются сложности контроля… кто упал, кто не выполнился и прочее… почему сразу не сделать правильно, если все равно прийдется сделать ;)
там все так же управляемые демоны, которые можно разбить по очередям например zip_queue, twitter_queue и запускать любое колличество ворокеров для каждой.
что же до цикличного выполнения каждые 5 минут, можно поставить плагин
github.com/bvandenbos/resque-scheduler
ваш способ хорош, но только при одной фоновой задаче, при двух уже появляются сложности контроля… кто упал, кто не выполнился и прочее… почему сразу не сделать правильно, если все равно прийдется сделать ;)
loop_dance и resquire это совершенно разные вещи у них различные цели и методы их достижения.
Насчет контроля вы вообще не правы — с контролем и параллельным запуском как раз таки все в порядке, каждого демона можно контролировать отдельно и через rake task и из приложения.
Главное достоинство loop_dance в том, что вы получаете подконтрольного автоматически запускаемого демона за 5 строк кода. Сделали и забыли. Не нужно лазить на сервак, редактировать крон, прописывать пути и т.п. и т.д.
Насчет контроля вы вообще не правы — с контролем и параллельным запуском как раз таки все в порядке, каждого демона можно контролировать отдельно и через rake task и из приложения.
Главное достоинство loop_dance в том, что вы получаете подконтрольного автоматически запускаемого демона за 5 строк кода. Сделали и забыли. Не нужно лазить на сервак, редактировать крон, прописывать пути и т.п. и т.д.
А уж ко всяких очередникам типа reqsue, delayed_job, workling и тп. эта софтина не имеет ВООБЩЕ никакого отношения и не в коем случае не претендует на их замену.
Вы что-то путатете фоновое периодическое выполнение задач с выполнением заданий по запросу.
Вы что-то путатете фоновое периодическое выполнение задач с выполнением заданий по запросу.
Спасибо за статью, отличный инструмент!
PS Может стоит перенести статью в блог Rails?
PS Может стоит перенести статью в блог Rails?
Насколько я понимаю, таски обрабатываются в очереди?
А крон вроде как параллельно запускает…
А крон вроде как параллельно запускает…
Верно. Если один так зависнет — остальные не выполнятся.
Кстати в этом большой плюс — гарантия что через некоторое время память на забьется тормознувшими тасками, что бывает при частом запуске по крону.
А если нужно параллельное выполнение, то задачу можно кинуть во второго танцора, который будет выполняться параллельно:
вторым танцором можно также управлять отдельно
А если нужно параллельное выполнение, то задачу можно кинуть во второго танцора, который будет выполняться параллельно:
class Dancer2 < LoopDance::Dancer
every 6.hours do
# делать что-то очень важное параллельно первому танцору
end
end
вторым танцором можно также управлять отдельно
А что значит «висеть в системе независим демоном»? Т.е. на «облаке» будет постоянно потреблять память и процессор? Или я что-то недопонимаю…
Можно ли с Танцором организовать отложное выполнение методов? Хочется выкинуть async-observer.
Мы используем github.com/kovyrin/loops
А вместо крона возможен даже такой вариант fourkitchens.com/blog/2010/05/09/drop-cron-use-hudson-instead
А вместо крона возможен даже такой вариант fourkitchens.com/blog/2010/05/09/drop-cron-use-hudson-instead
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
loop_dance — фоновый планировщик быстрого развертывания