background_job.org

Background Jobs

まだRailsアプリケーションでbackground処理をやったことがないので調べてみました。

Resque

• https://github.com/resque/resque
• 2.0リリースに向けて開発途中
• バックエンドとしてRedisを使っている

実行までの流れ

• ワーカープロセスを起動しておく。
• メインのアプリケーションでqueueにjobを突っ込む
• ワーカーがqueueを見に来る。jobが作成されていたら実行する。

動かし方

• Redisのインストール
• ワーカープロセスの定義

  class Hello
    @queue = :resque_sample # Woeker起動時に指定するQUEUE名
  
    def self.perform(message)
      sleep 5
      logger = Logger.new(File.join(Rails.root, 'log', 'resque.log'))
      logger.info "Hello #{message}"
    end
  end
      

• 呼び出し

  Resque.enqueue(Hello, params[:m])
      

• ワーカーの起動

  QUEUE=resque_sample rake environment resque:work
      

  • 本番で使うときはGODとかで起動してやるのが良い

Delayed Job

• https://github.com/collectiveidea/delayed_job
• Resqueより昔からある
• 今のところVersion 4.0.0が最新
• 遅延実行の共通パターンのカプセル化が目的。
• Backendはいろいろ使える
  • ActiveRecord (DJ 3.0+)
  • DataMapper
  • IronMQ
  • Mongoid
  • MongoMapper
  • MongoMapper (DJ 3.0+, MongoMapper 0.11.0+)
  • Redis (DJ 3.0+, experimental)
• resqueと違ってqueueのpriorityを定義できる。
• デフォルトではメモリをほとんど使わないので、 リソースにはやさしいが、パフォーマンスはresqueに劣る

sidekiq

• https://github.com/mperham/sidekiq
• 上２つより後発
• 上２つとの違いを書いたFAQ
  • https://github.com/mperham/sidekiq/wiki/FAQ
• 設定もシンプル

  # app/workers/hard_worker.rb
  class HardWorker
    include Sidekiq::Worker
  
    def perform(name, count)
      puts 'Doing hard work'
    end
  end
      

  • 上のワーカーを定義し、呼び出すときは下のようにする

  HardWorker.perform_async('bob', 5)        
      

• resqueに似ているが、resqueはシングルスレッドプロセスなのに対し、 sidekiqはマルチスレッドプロセス
  • 使用メモリに対するパフォーマンスはsidekiqが上。
  • スレッドセーフであることは開発者側が確認しないといけない。

まとめ

• redisが使える環境ならsidekiqがいいんじゃないか。
• redis入れられない、 もしくはredis設定の手間をかけるほどではない小さな機能の場合はdelayed_job