shoryukenのconcurrencyと実際のスレッド数が違っていたので調べた - Qiita
concurrency: 4 delay: 60 queues: - [test_queue, 1] - [hoge_queue, 1] - [fuga_queue, 1] - [piyo_queue, 1] class TestWorker include Shoryuken::Worker # ... def perform thread_logger.info('perform!') end def thread_logger ActiveSupport::Logger.new("log/worker.thread.#{thread_number}.log") end def thread_number Thread.current.to_s.match(/Thread\:([\da-zA-Z]+)/)[1] end end shoryukenの処理はざっくりと以下のような流れになっ
Shoryuken を導入しようとして諦めた話 - Qiita
Rails で非同期処理といえば、 Sidekiq, Resque, DelayedJob あたりが有名かと思います。 DelayedJob は RDS をジョブキューとして利用できる1ため、インフラの準備が不要で比較的ライトに導入できますが、数万件のジョブを登録しようと思うと RDS にかなりの負荷がかかりますし、Insert もそれほど早くないため、ジョブキューとしてはあまり適しているとは言えません。 Redis などのインメモリーデータベースを用いれば、RDS に負荷をかけず、Insert の高速化も見込めますが、万が一 Redis がクラッシュした際には登録されていたキューは全て無くなりますし、そういった障害に対応するためには幾らかの運用コストが発生します。 ところで、 AWS には SQS というキューイングサービスが提供されています。 安価で堅牢な造りになっており、運用コストも
[Rails] Shoryuken + FakeSQSで非同期処理 - Qiita
Shoryukenにチャレンジしてみます。 ShoryukenはAWS SQSからジョブ取り出すワーカーを簡単に作っちゃおうっていうGemなんですが、 今回は本物のSQSは貧乏なので使わずにFake SQSというSQS（っぽいもの）をローカルで立てることができるGemを使ってローカルのみで動くShoryuken Workerを書いちゃいましょう。 登場人物 AWS SQS: すごく安くキューが使えるニクいやつ AWS-SDK: RubyからAWSを簡単に操作できるニクいやつ Fake SQS: SQSっぽいものをローカルに立てられるニクいやつ Shoryuken: SQSからジョブを取り出すニクいやつ 導入 あらかじめ適当なRailsプロジェクトを作っておきます。 いつも通りプロジェクトのGemfileに追記してbundle installします。
![[Rails] Shoryuken + FakeSQSで非同期処理 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/5072685e3b2d98d3c1406b5d8eeef2cdd92b5790/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUmFpbHMlNUQlMjBTaG9yeXVrZW4lMjAlMkIlMjBGYWtlU1FTJUUzJTgxJUE3JUU5JTlEJTlFJUU1JTkwJThDJUU2JTlDJTlGJUU1JTg3JUE2JUU3JTkwJTg2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz00NjJhYWZhNmQ3ZmJhZTAzNDVhYjFkNDgxMTMyYjczYQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBpZW1vbjdzdGFycyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZWNmMTQ0NzIzNTdlMGY5YzYzZmZkNGIyZDYxNjM4MzY%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D7db86610744b1fb765f3f04125814612)
Quickly Process API Requests with Shoryuken and SQS — SitePoint
July 11, 2016Quickly Process API Requests with Shoryuken and SQS Rails has lots of solutions for background jobs. One of these is a brilliant Gem called Sidekiq, which we have written about before on Sitepoint. Sidekiq is great and can solve most developer needs. It is especially useful as it takes over the heavy lifting from Rails. However, it has a few shortfalls: If you are not a Pro user ($750
→↓↘+パンチ - クラウドワークス エンジニアブログ
みなさんさようなら、インフラ部の @h3_poteto です。 今日は昇竜拳の話をします。 ↑昇竜拳 クラウドワークス本体のアプリはRailsで作られているのですが、その中にちょいちょい非同期処理が載せられています。 メール送ったり、Elasticsearchとの同期処理だったり、重いスカウト処理だったり。 DelayedJobだと限界が見えてきた その非同期処理として、今までは、DelayedJobを使っていたんですが、ジョブが多くなり、キューが多くなり、ワーカーが多くなるにつれて、どんどん重くなってきました。 ActiveRecordを介してDBにキューを貯めるという方式がどうにもキツイ。 DelayedJobは本当に気軽に非同期処理が出来て良いのですが、キューにRDBを使うところがすごくイケてないです（だから気軽にできるんですけど）。 エンキューが多くなればそれだけ書き込みも、また処
shoryuken gemで簡単にSQSを使ったJob Queue WorkerをRailsに作成する | DevelopersIO
丹内です。 掲題のとおり、SQSを簡単に使うことができるshoryuken gemを使ってみました。 前提 ruby 2.2.4 rails 4.2.5 マネジメントコンソールでSQSの作成 AWSマネジメントコンソールのSQS画面から新規にキューを作成します。 Shoryukenによる負荷が抑えられるよう、Receive Message Wait Timeの設定を忘れないようにしてください。 インストール Gemfileに以下のように書いてbundle installします。 gem 'shoryuken' group :development, :test do gem 'foreman' end あとで解説しますが、railsアプリとは別にworkerプロセスも立ち上げるので、便利になるようforemn gemもインストールしています。 Jobクラスを作成 Shoryuken::Wo
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cross-pollination · Issue #13 · ruby-shoryuken/shoryuken
Signals
Using Ruby and Amazon SQS FIFO Queues · Pablo Cantero
