Rails Фоновая задача накладная

Question

Проведено ли какое-либо сравнение накладных расходов на различные методы обработки фона?

Предпосылки/RB, Старлинг, Workling MemcacheQ Beanstalk фона Работа (Bj) delayed_job (Dj)

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

Answer 1

Он будет меняться в зависимости от вашего приложения Rails.

Большинство этих процессоров зависят от ваших объектов Rails, по существу загружая весь экземпляр Rails в память. Ваша память App будет зависеть от количества моделей, от влияния любых плагинов и преобладающих климатических условий вашей среды.

У меня был фрагмент размером 256 Мбайт, работающий на нескольких Mongrels и BackgroundRB, и обнаружил, что фоновый процесс используется в той же памяти, что и экземпляр Mongrel.

Один из вариантов, который мне всегда нравился, заключается в том, чтобы поместить запланированную логику в контроллер и вызвать это через Cron с помощью wget или Curl. Вы можете использовать существующее Rails-приложение, и на его настройке очень мало накладных расходов. Единственная причина, по которой я не пошел с этим вариантом в вышеуказанном случае, - это требование для попадания в очередь каждые 5 секунд (Cron может запускаться только каждую минуту).

Answer 2

Меня также интересовало бы всестороннее сравнение, но я могу сказать, что BackgroundRB считается устаревшим его автором. В EngineYard они специально рекомендуют BackgroundJob после того, как у него возникли проблемы с BackgroundRB. Я ничего не слышал о других вариантах, которые вы упомянули.

Answer 3

Для низкого обслуживания мне нравится Background Job. Он работает в вашем Rails-процессе или через cron, поэтому для мониторинга не существует никаких процессов-демонов. На моем сервере Bj в настоящее время использует 35636 RSS (примерно один процесс Rails).

Я всегда удивляюсь, когда слышу о людях, использующих BackgrounDRB, потому что это в основном не поддерживается.