Комментарии 15
Про скедулер не знал, спасибо :)
-1
Маленькое дополнение из собственного опыта. Если ставить задачу в resque в методах типа after_create, то можно столкнуться с тем что задача начнет выполняться раньше чем произойдет коммит в БД (вот такой он офигительно быстрый этот resque) и тогда объект еще не будет доступен для других соединений к БД, в том числе и для самого resque. В этом случае лучше использовать методы серии after_commit…
+5
Статья как раз вовремя, только что собрался прикручивать Delayed Job из-за поддержки расписаний по-умолчанию. Но раз существует resque_scheduler, тем более появился такой хороший мануал, то естественно выбираем Rescue :)
Автор, спасибо :)
Автор, спасибо :)
+1
А вот есть интересная штуковина от большого специалиста по «асинхронным рельсам»:
github.com/mperham/sidekiq
Это то же самое, но жрет памяти меньше т.к. не process per job, а thread per job.
github.com/mperham/sidekiq
Это то же самое, но жрет памяти меньше т.к. не process per job, а thread per job.
+2
DelayedJob перестал развиваться? оО Последний коммит 3 дня назад. github.com/collectiveidea/delayed_job Вкуснях в нем, конечно, поменьше, чем в Resque, но для большинства задач он вполне годится. И Redis не нужен, опять же.
+1
«Вкусностей» там в три раза больше, чем в rescue. Ну разве что веб-морды нет изкоробки.
0
*resque
0
А можете пару наиболее примечательных вкусностей, по опыту? сейчас как раз думаю что именно выбрать для очередей. Ваше мнение было бы кстати
0
Ну, если по-простому, то в Resque умеет сохранять только простые типы. Скажем, можно сделать так:
или так:
но нельзя так
В DJ есть очень сложный и навороченный сериалайзер. С его помощью можно сохранять практически любые объекты со стейтами. А так же делать такие штуки:
Этот код запомнит объект со всеми его состояниями, а потом запустит у этого объекта метод
Resque.enqueue MyCoolJob, post.id
или так:
Resque.enqueue MyCoolJob, 'string'
но нельзя так
Resque.enqueue MyCoolJob, post
В DJ есть очень сложный и навороченный сериалайзер. С его помощью можно сохранять практически любые объекты со стейтами. А так же делать такие штуки:
Post.create(params[:post]).delay.publish!
Этот код запомнит объект со всеми его состояниями, а потом запустит у этого объекта метод
publish!
. +1
А я юзаю DJ и крутой гем clockwork. Один раз поднял энвайрмент, и он висит в памяти, по таймеру добавляет задачу в DJ.
Выглядит как-то так:
Выглядит как-то так:
# config/clock.rb
require_relative './environment'
require 'clockwork'
include Clockwork
every(1.day, 'user.pages.update', at: '12:00'){ User.unblocked.all.each(&:update_pages_info!) }
every(6.hours, 'user.apps.persistence.check'){ Delayed::Job.enqueue UpdateApplicationPersistenceJob.new }
every(1.day, 'pages.refresh_likes_count', at: '23:00'){ Facebook::Page.update_likes_count! }
0
Defunkt кстати сам писал в описании Resque, что они до этого сидели на DJ и он их полностью устраивал и всем нравился. А Resque они начали писать, когда очереди разрослись слишком неприлично. Суть в том, что пока у тебя нет огромных нагрузок и тысяч очередей, DJ проще и удобнее. Кроме того, в нем офигенный сериалайзер. А Resque работает только с простыми типами.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем Resque в Rails