Edited at

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

More than 5 years have passed since last update.


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アプリケーションのレスポンスタイム内訳

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

DBの処理時間が支配的なことがわかります.


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

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


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


その他


  • 他にもいろいろなデータ

  • 各グラフのうち,自分に必要なものだけを選んで一覧できる機能

  • パフォーマンスだけでなくサーバエラーの監視

  • 週ごとのサマリーやアラートのメールによる通知

  • データを日単位もしくは週単位で比較

  • 把握できていない機能が他にもいろいろありそう.


まとめ

New Relicのおかげでボトルネックがネットワーク時間であることがわかりました.

このボトルネックを排除するためには,転送するファイルの数およびサイズを減らす必要がありそうです,

なるべくブラウザ側でコンテンツをキャッシュさせたり,ファイルを圧縮したり...

アプリケーション側でキャッシュするとかSQLクエリの発行回数を減らすとかしてもあんまり意味なかったんや.

というわけでNew Relic便利!

明日の担当は@puriketu99さんです.

よろしくおねがいします.