パフォーマンス監視サービスのNew Relicが超便利な件

  • 663
    いいね
  • 4
    コメント
この記事は最終更新日から1年以上が経過しています。

12/09/05 監視対象のWebサービスのURLを間違えていたため修正しました

RailsのAdvent Calendarを待ちわびていました.
今回は,WEB+DBの最新号のRails高速化記事で紹介されていたパフォーマンス監視サービスのNew Relicを使ってみた話です.

New Relicは.newrelic_rpmというgemをインストールすることにより,レスポンスタイムやスロークエリなど,パフォーマンスに関するさまざまな統計情報をNew Relicのサイトでみることができます.

Railsに限らずPythonやJavaなどいろいろな言語に対応しているようです.
さらに,HerokuやDotCloudなどのPaaSにも対応していてやばい.

HerokuのNew Relicプラグイン

Herokuにホストしたアプリケーションを監視するためにはNew Relicプラグインを導入する必要があります.
導入の手順はこちら(https://devcenter.heroku.com/articles/newrelic)

New Relicプラグインには無料版と有料版があり,有料版のほうがデータの保存期間が長かったり,発行されたSQL文やEXPLAINの出力が見れたりするようです.
個人的には無料版で十分でした.

以下では7月に公開したDailyCodingというサービスを監視対象としています.

DailyCodingの環境

  • Rails 3.2.8
  • Unicorn
  • Heroku(無料)
  • 100PV/日(弱小)
  • 1テーブルのエントリ数はせいぜい数百個(弱小)

では,New Relicの主要なグラフを順番にみていきます.

ブラウザのページロード時間の内訳

ブラウザ

ブラウザのページロード時間 = Webアプリケーション処理時間 + ブラウザ-Webアプリケーションサーバ間のネットワーク時間
+ ブラウザのDOMの構築時間 + ブラウザのページレンダリング時間
となります.
明らかに通信時間がボトルネックであることがわかります.(DOM構築時間もそこそこ時間かかってる)
Herokuの東京リージョンまだー

Webアプリケーションのレスポンスタイム内訳

APサーバ

Ruby(Railsによるルーティング処理とかコントローラの処理とか),DBおよびWeb External(外部サイトへのリクエスト時間)などの処理時間の合計がWebアプリケーションとしてのレスポンスタイムとなります.
DBの処理時間が支配的なことがわかります.

DBのレスポンスタイム内訳

下の図はActiveRecordのクエリごとのレスポンスタイムを示しています.(正確には縦軸はレスポンスタイムではなく,トータルのDB時間のうちの当該クエリのレスポンスタイムの割合.多分,グラフをカスタムすれば縦軸をレスポンスタイムにできる?)

DB

Railsのコントローラのレスポンスタイム内訳

コントローラ

その他

  • 他にもいろいろなデータ
  • 各グラフのうち,自分に必要なものだけを選んで一覧できる機能
  • パフォーマンスだけでなくサーバエラーの監視
  • 週ごとのサマリーやアラートのメールによる通知
  • データを日単位もしくは週単位で比較
  • 把握できていない機能が他にもいろいろありそう.

まとめ

New Relicのおかげでボトルネックがネットワーク時間であることがわかりました.
このボトルネックを排除するためには,転送するファイルの数およびサイズを減らす必要がありそうです,
なるべくブラウザ側でコンテンツをキャッシュさせたり,ファイルを圧縮したり...
アプリケーション側でキャッシュするとかSQLクエリの発行回数を減らすとかしてもあんまり意味なかったんや.

というわけでNew Relic便利!

明日の担当は@puriketu99さんです.
よろしくおねがいします.