Rails/ActiveRecord バッチ処理の最適化 - Hack Your Design!
目次 検証環境前提条件オリジナルコード ベンチマーク最適化1: 簡単な最適化 ベンチマーク最適化2: where & each を使う ベンチマーク最適化3: find_each を使う ベンチマーク最適化4: in_batches & update_all を使う ベンチマーク最適化5: where & update_all ベンチマーク最終結果「ActiveRecordデータ処理アンチパターン」で発表します参考リンクRailsのバッチ処理最適化の記事書いたら需要あるかな — toshimaru (@toshimaru_e) December 2, 2017ということで今日はRailsバッチ処理の最適化について書いてみたいと思います。 検証環境コードの検証に使った環境は下記の通りです。 macOS High Sierra (2.3 GHz Intel Core i5 / メモリ8G)Ru
RailsアプリケーションをLAN内に公開する - Hack Your Design!
$ rails server --binding=0.0.0.0 => Booting WEBrick => Rails 4.2.3 application starting in development on http://0.0.0.0:3000 => Run `rails server -h` for more startup options => Ctrl-C to shutdown server このコマンドを使うことで同じLAN内にいるクライアントからRailsが起動しているマシンのローカルIPをポート番号とともに（例: 192.168.1.xx:3000）を叩けば、アプリケーションへとアクセス可能になります。 なぜ0.0.0.0？rails serverコマンドはデフォルトでループバックアドレス、つまりlocalhost(127.0.0.1)にバインドされます。ループバックア
Railsのfind_eachの挙動について調べた
目次 find_each とは素の find_eachorder付き find_eachlimit付き find_eachwhere付き find_eachまとめ参考Railsのfind_eachがどんな挙動をするか気になったので調べてみた。 find_each とはバッチ処理などにおいてActiveRecordで効率的に大量データを処理したいときに使うメソッド。大量データまるっと全部取ってきてメモリ展開して処理しちゃあアカンよねってことで、データを徐々に展開して処理したいときに使う。 Railsには find_each というメソッドが用意されています。通常の each メソッドを使用すると、全データをまとめてメモリに展開してから処理を開始します。そのため、十分にメモリに載るデータ量であれば何も問題ないですが、数百万、数千万というデータ量になってくるとメモリに載りきらずに溢れてしまって大
Rubyで独自例外を定義するときはStandardErrorを継承する
タイトルの通り、Rubyで独自例外を定義するときはExceptionではなく、StandardError を継承するしきたりとなっています。 # `Exception`ではなく class MyError1 < Exception; end # `StandardError`. class MyError2 < StandardError; end理由をコードでみてみます。 Exception を継承した場合class MyError1 < Exception; end begin raise MyError1 rescue => e puts "Exception handled! #{e}" end # => MyError1: MyError1MyError1 がrescue節でハンドリングされてませんね。こうしてみるとどうでしょう。 class MyError1 < Excepti
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
