60min.第13回「Background Job Worker座談会」 | けんちゃんくんさんのWeb日記
ursmから、このようなものが何故必要なのか、そしてidobataで実際にどう利用しているのか、ということを話してもらった。 なぜ必要なのか Railsのプロセスはだいたい200Mくらいはメモリを使うので、たとえばそれを32個上げるとするとそれだけで 200M * 32 でだいたい6Gくらいのメモリを使うことになる。(そして、メモリは普通有限なのだ) たとえば1秒かかる処理があると、同時に捌けるリクエストは32個になってしまい、33個目は1秒後に処理が開始されることになって、レスポンスを返すまで2秒かかる。 これが1秒ならまだいいが、普通、処理待ちをしている間にもどんどんリクエストは来るので、雪だるま式に処理待ちのリクエストが増えていくことだろう。 なので、同期処理が必要ない部分は、積極的に非同期処理に逃がしていかないといけない。 Background Job Workerはどれを使えばい
【Ruby on Rails】非同期処理についてその②。 〜マルチスレッドとかマルチプロセスを実装してみた〜 - 訳も知らないで
業務で非同期処理の実装が必要となったので、 前回ぼんやりマルチスレッド、マルチプロセスについて調べてみたのですが… 両方軽く実装してみたのでメモ。 実際に実装してみたところ、マルチプロセスでもマルチスレッドでも 処理時間自体は短縮されたのですが、 マルチプロセスだとメモリは食うしメモリ空間？を共有してくれないので スレッドのほうで実装してみました。 (マルチスレッドで十分なときはそれでいいってことかな？) 〜検証環境〜 Rails:3.2.11 ruby:1.9.3p392 Railsで普通に実装 マルチスレッドで実装 〜リファレンス〜 class Thread 〜とても参考になりました！〜 ActiveRecordを複数スレッド環境で利用する - tech.recompile.net 処理内容はDBからUserのid取ってきているだけです。 threads = [] 10.times.w
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rails seedファイルに大量のデータを早くいれる方法 - Qiita
