Sidekiqで非業の死を遂げたキューを知る方法 - Qiita
前置き：Rubyのキューイングシステム Rails（Ruby）で非同期にキューイングしてくれるライブラリといえばSidekiqですよねっていうくらいSidekiqが好きなんですが、世の中のシェア的にはResqueなのかな。でも、Sidekiqの方が安定的に動かせているので僕は好きです（delayed_jobは知らない）。 ShoryukenというAWS SQSを使ったキューイングシステムもあり、RedisじゃなくてSQS使いたいっていう場合は、これも良いのかもしれないですね。まぁ、ローカルの場合面倒そうな感じもありますけど。 phstc/shoryuken まぁともかくSidekiqを導入してキューイングするっていうのは、もう超絶簡単にできるわけです。できるんですけど、実際にラフに運用していくと、キューがいつの間にかこけて処理待ちで埋まってたり、レアなケースで例外投げて死んでたりするわけで
ActiveJob から見るシリアライズとデシリアライズ - MUGENUP技術ブログ
皆さん、こんにちは。プルリクで間違った指摘をして大反省中 の osada です。 プルリクで間違った指摘をして大反省中です。 下記のコードで、何を指摘したか、お分かりになるでしょうか？ class NotificationJob < ActiveJob::Base queue_as :default def perform(notifiable, user) notifiable.notify(user) end end こんなことを言ってしまったのです。 オブジェクトを丸ごとシリアライズすると、redis の容量を圧迫し、 シリアライズ・デシリアライズにも時間が掛かるので、 クラス名とidを渡して、job の中で取り出して使って下さい。 この発言には2つ、間違いがありました。 1つ目は、オブジェクトが丸ごとシリアライズされると思っていたこと。 2つ目は、ActiveJob は クラス名と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
