Enter!バッチを起動しようと勢いよくキーを叩いたら、それはシフトキーだった。itmammothTweetRails製アプリは、1画面に結構な量の情報を表示しようものなら、すぐにパフォーマンスが悪くなってしまいます。基本を押さえておけばこういったことに陥らないのですが、Railsがあまりにもサクサク開発できちゃうもんですから、ついつい調子に乗って基本を忘れてしまいがち。自分を戒めるためにも、パフォーマンス・チューニングの基本をまとめておくことにします。i7)チューニングするデモアプリいまいち冴えないビジュアルのこのデモアプリ『Bookshelf(本棚)』を使用します。テーブルの1セル(td)に1冊の本が納められているつもりです。著者(Author)はN件の本(Book)を持つデモデータは本1,000件、著者も1,000件セル(td)の中に各本のタイトル(太字下線)、著者名を表示する各セル内をクリックすると、本の説明がアラートで表示される(Javascript)チューニング前チューニングを始める前に、最初の状態でどれぐらいのパフォーマンスなのか見ておきましょう。これは、簡易プロファイラを導入して計測することにします。1.0.3'endrack-mini-profilerとは便利な簡易プロファイラで、控えめな表示でゴキゲンなプロファイル情報を提供してくれる素敵なgemです。このgemを入れておくと以下の画面のように小さなウインドウが表示されるようになります。設定要らずなので楽チンですね。このプロファイラのおかげで、画面をレンダリングするのに4秒以上も掛かっていることが分かりました。チューニング1:includesさあそれではチューニングしていきましょう!まずは、一体何に時間がかかってるのかを知らなければなりません。実はこのプロファイラの小さなウインドウですが、クリックすることで詳細を確認することができるんです。sql」って出てきてます。books/_bookパーシャルをレンダリングする際にSQLを発行しているようですね。sql」リンクをクリックするとSQLの詳細が確認できます。authorを取得するSQLみたいですね。_bookパーシャルというのは本1冊分に相当するViewですが、この中に何か要因があるのでしょうか?_bookパーシャルの中を見てみましょう。%></div></div>プロファイラの表示を見るに、このソースの5行目にてSQLが発行されているようです。それらしいところは「book.author.name」という記述でしょう。これはauthorモデルが『遅延ローディング』されているということです。bookモデルからauthorモデルにアクセスして初めて、authorsテーブルに対するSQLを発行しているのです。いわゆる「N+1件問題」ですね。念のため、この画面を表示しているBooksコントローラ、さらにはBookモデルのソースも見ておきましょう。:titleendコントローラでは、Book.allで本を全件取得しています。Bookモデルでは、特に何もしていません。この画面の仕様上、Bookに紐付くAuthorは最初にまとめて取得しておいた方が効率が良さそうです。それぞれのファイルを編集します。endendwith_authorというスコープを作成しました。includes(:author)と記述することで、Bookモデルを取得時に親であるAuthorも合わせて取得してくれるようになります。それでは、再度画面を開いてみましょうか。ビンゴォ!あれだけ長かったSQL表示が無くなり、2つに減りましたね。パフォーマンスも劇的に改善しました。いやー気持ちいい!N+1件問題はエラーではないので、ついつい見逃しがちな問題です。Railsの便利さゆえに、知らず知らずのうちに引き起こしてしまう問題なのかもしれません。このrack-mini-profilerを導入さえしておけば、その手の問題をこまめにチェックすることができるのでオススメです。次回はさらにチューニングを進めていきたいと思います。今回使用したソースコードgithubに使用したソースコードを置いておきます。試してみたい方はどうぞ。https://github.com/itmammoth/ome-tuningタグ「V0_initial」が最初の状態、「V1_pt」がチューニング後の状態です。01:37テスト2コメントは受け付けていません。検索:プロフィールitmammothIT界のマンモスを目指しているフリーエンジニアです。麻婆豆腐/Ruby/Kotlin/麻婆春雨/Python好きです。最近カリフラワーも好きになりました。