【Rails】resque-schedulerでschedule・Delayedジョブを追加とか取得とか削除する。 - 訳も知らないで
Railsアプリケーションで何かバックグラウンドで 処理を実行させたい場合に便利なのが resqueですね！ ユーザーの登録が済んだらメールを送るとか、 データの変更があったら集計し直すとか、 そんな時に使うことが多いと思います。 で、バックグラウンドで実行するタスクをcronみたくスケジュールリングしておいたり、 予定したタイミングで実行させることが出来るのが resque-schedulerですね！！ そのスケジュール等を登録する方法を忘れてしまわないよう 今回書いてみました。 ※↓に書いてあることを使ってみただけの話ですので そっち参照してもらえれば問題ないかと(^_^;) 〜参考になりました！〜 bvandenbos/resque-scheduler · GitHub Module: ResqueScheduler — Documentation for bvandenbos/re
Resqueワーカーをデーモンとして動かす
先日の記事（Resqueを利用したRailsでの非同期処理/バッチ処理）の続きです。 簡単に振り返っておきましょう。今、localhost:3000でRailsアプリが動いています。ユーザーが/hello/worldにアクセスすると、すぐにレスポンスが返ってきます。しかし、数秒経過すると専用のログにテキストが書き込まれます。こういう仕組みを作りました。 この仕組みの鍵になるのが、Resqueというライブラリです。Railsアプリ側でクラスメソッドResque.enqueueを呼ぶと、非同期で実行したい処理（ジョブ）を登録できます。他方、Railsアプリとは別のプロセスでResqueワーカーというものが動いていて、数秒ごとに新しいジョブが登録されていないか監視しています。新しいジョブを見つけると、それを実行して、また監視作業に戻ります。 さて、前回はターミナルで resque:work とい
RailsでResque使い始めた - Masatomo Nakano Blog
これとこれの続き。この後、もう少し調査して、Resqueを実際のシステムの一部で使い始めてみたのでその感想とメモ。 前回までのあらすじ Resqueはバックグラウンドでジョブの実行をするもので、かなりの大規模サイトでかつ更新系の処理が多そうなシステムであるGithubで開発され使われている。よくある使い方としては、「Web UIを軽く見せるため、処理の依頼だけを受け付け、実際の処理はバックグラウンドで実行」「バッチ処理などで、大量のJobをQueueに突っ込んでおいて、(複数の)workerで並列で効率よく処理」などがある。 不安なところ Resqueの大きな特徴は、QueueをRDBMSではなくRedis上に作るところにある。Redisは、Memcacheのようにシンプルに使え、すべてのデータはメモリ上に展開されるのでとても速く、データはディスク上にも永続化されるので、何かあったときにも
#271 Resque - RailsCasts
Download: source codeProject Files in Zip (206 KB)mp4Full Size H.264 Video (18.8 MB)m4vSmaller H.264 Video (12.1 MB)webmFull Size VP8 Video (13.8 MB)ogvFull Size Theora Video (28 MB) 今回のエピソードではRails 3.1の新機能シリーズはひと休みして、Railsアプリケーションでバックグラウンドジョブを処理する優れた方法であるResqueを紹介します。今までのエピソードでもバックグラウンド処理を取り扱う方法をいくつか紹介しました。それぞれ微妙に違うニーズに対応しており、Resqueも例外ではありません。エピソードの最後で、異なるニーズに合った正しいツールを選択するチップを紹介しますが、とりあえずはResque
GitHub製Resqueを使用したRubyでのバックグラウンド処理(バッチ処理) - Masatomo Nakano Blog - Web開発を極める
そこそこの規模のWebシステムになってくるとバックグランド処理(batch処理)は欠かせないものになってくる。メールの送信、データの日次、月次、年次処理、削除(フラグ)データのpurgeやバックアップ、等々いろいろな物が出てくる。 現在はBackgrounDRbを使っているが、いろいろといまいちなので今回Resqueを評価してみた。ちょっと触った段階での第一印象をメモ。 まず、バッチ処理系で評価のポイントになってくる部分はなんだろうかと考えてみると、なんと言っても見通しのよさと異常系の処理だと思う。画面系と違い、バッチ処理は「見えにくい」ところで実行されるので、その二つが特に大事になってくる。「知らないうちに止まっていました」では困るのがバッチ処理。 たとえば、 異常時の処理無視?管理者に通知?リトライ? 復旧処理タスクの削除(問題を修復後)リトライ 状態の監視いくつのJobが残っているか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Hello World Resque (Railsにresqueを導入する) - Qiita