Rails: pluckでメモリを大幅に節約する（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Using pluck can save a bunch of memory - Andy Croll 原文公開日: 2018/09/16 著者: Andy Croll Active Recordのモデルは信じられないほど柔軟性が高く、機能が山ほど搭載されています。メソッドのAPIが大量にあるため、Active Recordの個別のオブジェクトはメモリに読み込まれると非常に場所を取ります。 Active Recordのモデルにフィールドがたった1つあるだけでも（たとえばidだけでも）、Railsが背後に控えているのです。 次のように書くのではなく 多数のオブジェクトをイテレーションしてメモリに全部読み込む。 Book.paperbacks.map { |book| book.title } #=> ["Eloquent Ruby"
Rails tips: 遅いクエリのログをDB設定変更なしで取るコツ（翻訳）｜TechRacho by BPS株式会社
アプリの種類を問わず、遅いクエリのログを読むのはパフォーマンス向上のためのリファクタリングで弱い部分を発見するよい方法のひとつです。 以前の私は、遅いクエリのログというとデータベースエンジンで生成されたログのことが念頭にありました。しかし、データベースの遅いクエリのログを取る独自のメカニズムを作れることをご存知でしょうか？RailsのActiveSupport::Notificationsモジュールを使うと、指定のイベントをサブスクライブできます。イベントのひとつに sql.active_recordがあり、これはデータベース操作のたびにトリガされます。 次のような感じで使えます。 ActiveSupport::Notifications.subscribe('sql.active_record') do |name, start, finish, id, payload| # inter
ActiveRecordのincludesは使わずにpreloadとeager_loadを使い分ける理由 - Qiita
はじめに ActiveRecordでN+1問題やスロークエリを解消するためにeager loadingを行う場合、普段Railsを使って開発されている方であれば、パッと思いつくのはincludesではないでしょうか？もしくは、preloadやeager_loadを使用しますよね。 この記事では、Webサイト表示パフォーマンスを保つため、ActiveRecordのメソッドの違いや、どいういう場合に使ったら良いのか、どいういう場合には使わない方が良いのかについて書きました。 実際に Railsアプリケーションを作成して解説していきます。 用語の説明と分類「ORM の Eager loading と Lazy loading」 Webサイト表示パフォーマンスを保つため、ORM（RailsではActiveRecord）では、Eager loading と Lazy laodingというものをサポー
ActiveRecordのjoinsとpreloadとincludesとeager_loadの違い - Qiita
ActiveRecordでN+1クエリを潰すためにeager loadingを行う場合、preloadやincludesやeager_loadが役に立つ。 Preload, Eagerload, Includes and Joinsという記事にそれらの違いがよくまとめられているんだけど、includesが挙動を変える条件があまり正確に書かれていなくて自信が持てなかったし、そもそも記事が古いのでRails4.1.5のソースを読んで調べた。 せっかく調べたので、全体を通して日本語でまとめてみようと思う。 User.joins(:posts).where(posts: { id: 1 }) # SELECT `users`.* FROM `users` INNER JOIN `posts` ON `posts`.`user_id` = `users`.`id` WHERE `posts`.`id
find_each と find_in_batches の違い - zdogma's diary
ことはじめ 大量のデータにアクセスして処理を行うとき、全てメモリに展開するとよろしくないので、 少しずつメモリに展開しながら処理をしよう、というのはよくあるケースだと思いますが、 Rails を使っている場合は下記の2メソッドが候補に上がるかと思います。 find_each find_in_batches それぞれの使い分けがいまいちわかっていなかったので、調べてみました。 それぞれのメソッドについて find_each デフォルトで1,000件 ( batch_size で指定する)ずつデータを取得し、 取得したデータを 1件ずつ 処理する。 User.find_each(batch_size: 2) { |user| p user } => User Load (0.3ms) SELECT `users`.* FROM `users` ORDER BY `users`.`id` ASC
リリース時の負荷対策 - Qiita
この記事は、ドリコム Advent Calendar 2014 - Adventar の22日目の記事です。 21日目は、ウッチーことtakao.uchikawaさんによる、「スマートフォンでの脱出ゲームの作り方」です。 自己紹介 シモーネと呼ばれています。 PHPとかJavaとかPerlとかで、ポータルサイトとか作ってました。 ドリコム来てからはRuby書いてましたが、今はPMやってます。 最近は、たまにサーバー入って、ちょっとコマンド叩く位。 ドリコム釣り部 裏部長やってます。 エリアトラウト、ヘラブナ、シーバス、投げ、ジギング、キャスティングなど、いろいろやってみて釣りを楽しんでます。 書くこと アプリリリース時の負荷対策を、忘れっぽい自分の為に、覚えている範囲でまとめてみます。 余談ですが、同じリリース時の負荷対策として、釣った魚を写真撮ってからリリースする場合の、魚への負荷対策方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロダクションの Rails サーバーの利用メモリがひたすら増加していくような挙動を観測したとき、どう対応するのがよいですか？
Rails で includes して N+1 問題対策 - Qiita