ここに全部書いてます
ジョブキュー処理のResqueとDelayed Jobの使い分けの方針などはありますか？
- ある処理の途中でその処理は中断せずに別の処理を行うこと
- 時間がかかる処理は後回しにして早く応答だけしたい(特にWebアプリ)
- DelayedJob
- Resque
- Sidekiq
- ActiveRecordの使用が前提(もしくはmongoDB)
- ジョブ用の専用テーブルを作成してそこにキューイングしていく
- ジョブを処理するためのWorkerプロセスを予め起動しておき、それらがジョブを消化していく
- デモ
- ジョブ用のデータストアを別に持つ必要がなくてお手軽
- 他の永続化データと同居することになるのでDBに負荷がかかる(ジョブの登録/ロック/削除)
- 同じプロセスが残り続けるのでメモリリーク/フラグメンテーションの考慮が必要
- データストアにはRedisを使用
- Redis? -> インメモリKVS(データ構造色々/非同期永続化/マスタースレーブ構成)
- Workerプロセスはジョブ実行時に毎回forkしてそのプロセスで処理が行われる
- デモ
- 毎回forkするのでメモリリーク/フラグメンテーションが起こる処理なども平気
- Webの管理画面がある
- プラグイン豊富
- 毎回forkするのでオーバーヘッドがあり短時間のジョブに向かない
- 突然の死(ログ無し)
- 開発が滞っている？(PR貯まっている)
- データストアにはRedisを使用
- プロセスが複数のスレッドを生成し、各スレッドがジョブを処理する
- デモ
- 同時に動くプロセスが少なくなるのでメモリを節約できる
- プロセスのforkよりもスレッドの切り替えの方が早いのでIO待ちの多いジョブや短時間のジョブに向いている
- Webのリッチな管理画面
- ロゴがキモい
- プロセスはひとつなのでメモリリーク/フラグメンテーションの問題
- 0.1secかかるメール送信処理を10000ユーザに対して行う
- 色々かなりいい加減なんで参考程度に
| DelayedJob | Resque | Sidekiq |
|---|---|---|
| 1080 sec | 1158 sec | 1028 sec |
| DelayedJob | Resque | Sidekiq |
|---|---|---|
| 365 sec | 389 sec | 345 sec |
- お手軽にやりたい場合はDelayedJob
- Redis立てられる & 一つのジョブが重い場合にはResque
- Redis立てられる & 一つのジョブが軽い場合にはSidekiq
デモ用Railsプロジェクト hoco/compare_bg_job