背景

Heroku上でRuby on Railsを使い作成したウェブアプリケーションを運用している。しかしアプリケーションの一つの機能である画像のアップロードについてレスポンス時間が長く、ボタンの二度押しや複数同時アクセスがあった時に応答が返ってこないことやアップロードに失敗することがある。そこを解決するためにこのアプリケーションのパフォーマンスチューニングを行うが、定量的な測定が出来なければ改善したかどうかが施策後曖昧になってしまい、目標を達成できたのか（いつどこで施策をやめるのか）、どの施策が有効だったか分からず今後に活かせないことが考えられる。そこでここではRailsアプリケーションにおけるパフォーマンス測定について調査する。

他に参考にした記事

Rails アプリケーションのパフォーマンスについて RubyKaigi 2013 で発表しました | クックパッド開発者ブログ

RubyKaigi 2013で発表されたクックパッドの社員の方によるRailsアプリケーションチューニングについての資料。最近の資料でありRailsを大規模に使っているクックパッドの事例なので、とても資料価値が高いように思われる。

rails/rails-perftest

Rails 4にてgemに切りだされたパフォーマンス測定ライブラリ。

newrelic/rpm

New Relicでの測定が優れているという噂。Developer ModeとProduction Modeで表示される情報が違うらしい。

#368 MiniProfiler - RailsCasts

日本語の資料です。主にSQLクエリのプロファイリングを行うことができます。

#411 Performance Testing (pro) - RailsCasts

RailsCastsの有料記事です。

指標

チューニングする値について

サーバ側でチューニング可能な、リクエストが最後までサーバに辿り着いてから、サーバがレスポンスをクライアントに向けて送信し始めるまでの時間のチューニングを行う。ここではDOMのレンタリング時間や複数のコネクションを張ることによる遅延時間は対象に含めない。またクライアントから送られるデータのサイズによるネットワークの遅延時間も対象とならない。

レスポンスタイム（応答時間）の定義について

例えばクックパッドでは200ms以下にレスポンスタイムを抑える目標を持っていますが、この「レスポンスタイム」とはどのように計測したものなのか、まず考察しました。どうやら先日行われたRubyKaigi 2013でのIssei Narutaさんのスライドを見るに、前項での定義と同じだと思いました。よってここでもその定義に従おうと思います。ただ一部でクライアントがレスポンスを受信するまでの時間と定めている記事があり、これはネットワークでのデータ送受信にかかる時間が含まれ前述のレスポンスタイムの定義とは異なることから、各々の記事でどのようにレスポンスタイムが定義されているかについては、意識しなければならないと思いました。（情報処理試験における定義やISO/IEC9126における定義についても面白かったです）

実際

Apache JMeterで規定のリクエストを30回行い、サーバ側でレスポンスタイムを測ると共にJMeerでサンプルタイムを測り、それらの値をグラフ化及び平均化し比較及びチューニングを行った。