こんにちは。クラウドワークスの八木です。

今回は、ActiveRecord のパフォーマンス改善に関する gem を作ったので、それについて紹介したいと思います。先にオチを書いちゃいますが、この Gem を入れるだけで必ずパフォーマンスよくなるとか、そこまでのものではありません（仮に、そんな銀の弾丸があれば、 Rails 本体にリクエストを出すべきですし....）。特定のケースにおいて改善が期待される、というタイプのものです。

どんなgem

ActiveRecordのpreloadを使う際、アプリケーションの仕様上不必要なSQLのクエリの発行を避けることができるようになる active_record_association_query_economizer という gemです。

github.com

例をあげて説明します。

ある RPG のゲームで、ユーザー (User) の職業が魔法使い (wizard) のときのみ魔法 (magic) が使える、という設定があるとします。user_id=1, 2 のユーザーは魔法使いなので魔法が使えるが、 user_id=3 のユーザーは戦士なので魔法が使えない、という具合です。サイトには、ユーザーの一覧を表示するページが用意されています。その中で「各ユーザーの名前の横に、使える魔法を表示したい」としましょう。

すると、きっとこんなコードを書くことになります。

Controller:

@users = User.last(25)

View:

<% @users.each do |user| %>
  <%= user.name %>
  <ul>
    <% user.magics.each do |magic| %>
      <li><%= magic.name %></li>

users の各 user に対して magics を参照しているので、このままではクエリがたくさん発行をされてしまいます。いわゆるN+1問題というやつです。そこで、preloadを使ったりすると思います。

Controller:

@users = User.last(25).preload(:magics)

クエリはこんな感じになります。

SELECT users.* FROM users ORDER BY id DESC LIMIT 25
SELECT magics.* FROM magics WHERE user_id IN (1, 2, 3, 4, ...)

このときに、魔法使いじゃない、user_id=3 のユーザーに注目しましょう。preload のクエリには user_id IN (..., 3, ...) とあるので、magics の中から user_id=3 のレコードを探しています。しかし、この例における「魔法使いじゃないと魔法を使えない」という仕様からすると、これは必要のない検索です。今回作った active_record_association_query_economizer では、このような必要のない検索を減らすことができるようになります。

この magics の例では、IN句のコストがほんのちょっと減るだけなので、ほとんど効果はないでしょう。では、同じページに「職業が戦士のユーザーで絞り込む」という機能があった場合はどうでしょうか。その場合は preload のクエリがそのまま全部不要になります¹。その他、 preload 対象のテーブルにレコードが少なければ少ないほど削減量が大きくなります。

使い方

active_record_association_query_economizer を追加して、アソシエーション定義のところに下記のように preload_if オプションを記述します。

class User
  has_many :magics, preload_if: :wizard?

以上です。これで、preload によるクエリ発行前に、 wizard? の戻り値によって id のフィルタリングが実行され、仕様上必要なもののみ preloadが行われるようになります。

クエリはこのようになります。

SELECT users.* FROM users ORDER BY id DESC LIMIT 25
SELECT magics.* FROM magics WHERE user_id IN (1, 2, 4, ...)

Symbol のサンプルを示しましたが、Proc も記述できます。Proc を書いた場合、引数に渡ってくるのはこのモデルのインスタンスです。

サービスへの導入

弊社のサービス crowdworks.jp に適用した例をご紹介したいと思います。一定期間の特定テーブルへの preload クエリを集計して、効果の参考としました。

サービスで使っているモデル Foo とモデル Bar の間には、 foo has_one bar で表現される関連が定義されており、一日に約137万件のpreloadクエリが発行されていました。

SELECT bars.* FROM bars WHERE foo_id IN (1, 2, 3, 4, ...)

このようなクエリが1日に 137 万件発行されてしました。そのうち、テーブル bars にレコードが一つもないようなクエリは、実に 119 万件もありました。このクエリは、gem の導入により一切発行されなくなりました。クエリの発行数を検索レコード数別に見ても、ほとんどのクエリが検索レコード数20以下に収まっています（下図）。

f:id:negito6:20171104210024p:plain:w480