WordPress サイトのボトルネックを見つける為の解析ツール紹介

サイトの表示が遅いと感じたら、ボトルネックを調べる為に解析ツールを使いましょう

WordPressのプラグインやテーマを開発されているプログラマー向けの内容となりますが、WordPressが動作する為に裏でいろんなことが行われているのが見られるので、なかなか興味深いです (^^)

ボトルネックを探しだせ

外側から徐々に内側へダイブしていきます

  1. ブラウザー解析ツール(PageSpeed, YSlow)
  2. データベース解析 (Query Monitor)
  3. PHP解析 プロファイラー(Xdebug、WebGrind)

ここで紹介する解析は、基本的には、ローカル環境のXAMPP上に構築した WordPress を対象にしています

それでは順に紹介していきます

ステップ1 ブラウザの解析ツール

外側から計測する

いろんなところで紹介されていますが、gtmetrix という PageSpeed, YSlow を使用してパフォーマンスを解析してくれるサイトがあります

公開しているサイトなら gtmetrix で PageSpeed, YSlow 同時に診断できますが、今回はローカル環境で解析していくのでブラウザの拡張機能を使います

YSlow

Yahoo が開発している解析ツールです

https://developer.yahoo.com/yslow/

ここのページから各ブラウザ用の拡張機能のリンクがあるので、クリックしてインストールします

後は解析したいページをブラウザで表示したら、ツールバーに追加された YSlow のアイコンをクリックすれば解析してくれます

詳しはこのサイトで紹介されています [パフォーマンス] サイトのパフォーマンス問題を発見できるYSlowというツールを使ってみた。指標の内容一覧など。

PageSpeed

google の開発している解析ツールです

PageSpeed Insights Browser Extensions

ここのページから各ブラウザ用の拡張機能のリンクがあるので、クリックしてインストールします

これはデベロッパーツールに追加される機能なので、ctrl Shift I キー3つを同時押しすると PageSpeed というタブが追加されているので、そこの 分析 という赤いボタンをクリックして解析を行います

詳しくはこのサイトで紹介されています PageSpeedを使ってWebサイトを最適化・高速化しよう

最初の段階は、この2つのツールで指摘された事項への対策を施します

リンクの紹介だけでステップ1は、いきなり手抜きしてしまいました (^_^;)

これらのツールは改善提案をしてくれますが、正直に言うとよくわからない項目もあるし、実現が難しいものもあります

それでも、出来ることはないか調べ、対応することである程度の高速化は出来るし、何がボトルネックとなっているのかもだんだんわかってきます (^^)

また、サーバー側での対策も大変有効なので、このあたりの記事も参考にして下さい

mod_deflate, mod_expires を使用してHTTP通信データ量を削減

この段階で判断出来る項目は下記のような内容となります

  • サーバーの設定は適正か
  • 画像のサイズや数は適正に使われているか
  • 設定やプラグインによって遅くなっていないか

プラグインが原因の場合等では、何がボトルネックとなっていて本当にそれが必要なのか、あるいは代替手段はないか等様々な検討を行います

ステップ2 データベースのクエリー解析

ステップ1で様々な対策を行えば、そこそこ高速化出来ますが、まだ動作が遅い場合には、WordPressのデータベースのクエリーを解析していきます

MySQLデータベースの解析は、ログが有効にしてあれば MySQL Workbench 等で参照できます

MySqlWorkBench_log

ただ、あまり見やすいものではありません. これではちょっとつらいので、WordPressプラグインの Query Monitor がお勧めです

Query Monitor

これを使用すると簡単にデータベースのクエリーを見やすく表示してくれます

インストール

通常のプラグインと同じです。新規追加から Query Monitor を検索してインストールできます

設定

インストールするだけで設定はありませんが、ツールバーに結果の簡易表示と操作メニューが追加されるので、管理画面のユーザーのプロフィールでツールバー表示が有効になっているかは確認して下さい

実行

実行するのは簡単で、ブラウザから解析したいページを読み込むだけです

QueryMonitor-stat

ツールバー上に結果が表示され、左からページの読み込み時間、サイズ、クエリー時間、クエリー数を表しています

さらにそこにマウスを持って行くとメニュー表示されるので表示したい項目をクリックすると詳細なデータを参照できます

QueryMonitor-menu

クエリー

クエリーコマンドだけでなく、それを発行した元の関数名(例えば get_option 等)、実行時間も表示されます

QueryMonitor-querylist

また、スロークエリーがあれば分かりやすく強調表示されます

クエリー発行元の関数の統計情報もあります

これもなかなか便利です

QueryMonitor-caller

Hook毎のアクション(そこにフックしている関数とその優先度)の一覧

これもいいです

QueryMonitor-hook

使用している transient api での名称と有効期限等

QueryMonitor-transient

これ以外にもいろんな情報を表示してくれます

じぇじぇじぇー 素晴らしすぎます  (^^)

 

ここからデータベースがらみのボトルネックを見つけていきます

  • どのようなクエリーが発行されているのか
  • 想定外のクエリーが発行されていないか
  • 遅い(時間のかかる)クエリーはなにか
  • 何回も同じクエリーが発行されていないか

呼び出し元の関数名もわかるので、必要最小限のクエリーを発行するためにどうするかのヒントを沢山得ることが出来ると思います

これでプロファイラー機能もあれば鬼に金棒なのですが、プラグイン作者が将来的に機能追加するかもといっているので期待大です (^^)

 

ステップ3 PHP解析 (Xdebug、WebGrind)

データベースでのボトルネックの解析が済んだらいよいよPHP言語レベルの解析です

注:PHP解析は実際のサイトで行うことは止めておいたほうがよいです (^^)

Xdebug 

準備

ちゅっと古い記事で現在はバージョンが更新されていますが、基本的には同じ手順で設定できるはずなので、下記記事を参考に xdebug が動作する環境を構築して下さい

これで WordPress のデバッグがとても便利に行えるようになるのですが、さらにプロファイル出来るように Xdebug に設定を追加します

XAMPPインストール先の php.ini ファイル(例, C:\xampp\php\php.ini)の一番後ろに記述されている xdebug の設定を修正します

[XDebug]
;zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
;xdebug.profiler_append = 0
;xdebug.profiler_enable = 1
;xdebug.profiler_enable_trigger = 0
;xdebug.profiler_output_dir = "C:\xampp\tmp"
;xdebug.profiler_output_name = "cachegrind.out.%t-%s"
;xdebug.remote_enable = 0
;xdebug.remote_handler = "dbgp"
;xdebug.remote_host = "127.0.0.1"
;xdebug.trace_output_dir = "C:\xampp\tmp"
zend_extension = "C:\xampp\php\ext\php_xdebug.dll"
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1
xdebug.profiler_output_dir = "C:\xampp\tmp"
xdebug.profiler_output_name = "cachegrind.out.%t"
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

 

常時プロファイラーが有効だと、生成されるファイルが大きくなりすぎてしまうので、特定のページの表示をトリガーとして実行させる用に設定します

profiler_enable = 0 で profiler_enable_trigger = 1 です

profiler_output_dir = C:\xampp\tmp は、プロファイルしたデータの保存ディレクトリです。デフォルトのままでOKです

profiler_output_name = cachegrind.out.%t は、作成されるプロファイル情報データのファイル名です。%t でファイル名にタイムスタンプを追加しています

 修正が済んだら Apacheサーバーを再起動します

参照

実行

ブラウザのアドレスバーに表示ページのURLを入力したらその後ろに ?XDEBUG_PROFILE をつけるとこれがトリガーとなりプロファイルが実行されます

例えば http://localhost/wordpress/ というページの解析を行い時は

http://localhost/wordpress/?XDEBUG_PROFILE と指定してあげます

ブラウザで読み込ませると、先ほど設定した C:\xampp\tmp にプロファイル情報ファイルが生成されます

解析するにはツールが必要

作成された情報ファイルを見てもそのままでは理解できません。この解析するためのツールがいろいろあるようです

高機能なものでは、KCacheGrind という解析ツールがあるようです。ただ、KDE環境が必要なようなので使用したことはありません (^_^;)

ここでは、ブラウザを使用して解析できる webgrind を紹介します

webgrind

webgrind-site

インストール

webgrind-release-1.0.zip をダウンロードして解凍します

解凍した webgrind をフォルダーごとドキュメントルートの htdocs 下にコピー

webgrind-install

config.php 設定

Webgrindはconfig.phpファイルを編集することで設定できますが、Xdebugが今までの手順通りにインストールされているなら変更しなくても動作するはずなので修正は不要です

実行

ブラウザのアドレスバーにwebgrindのURLを入力します

webgrind はドキュメントルート下に設置しているので

http://localhost/webgrind/ とすると表示されます

webgrind-index

既にプロファイル情報データを作成してあれば、ここで update ボタンをクリックすれば一番新しいプロファイル情報データが表示されます

webgrind-sample

使い方

わかる範囲でざっくりと説明します (^^)

プロファイル情報選択

Show  [90%] of [Auto (newest) ] in [percent]

この部分でファイルデータ表示量単位を指定しています

デフォルトでは Auto (newest) で一番新しいファイルとなっていますが、プルダウンすると複数のデータが有った場合は選択できます

また、最初の状態で時間のかかっている関数順に並んでいるので上位のどの程度を表示するかを(例えば90%)を指定します

表示単位は、percent / milliseconds / microseconds から指定します

設定を変えたら update ボタンをクリックすると再描画されます

表示内容

function 関数名

関数の種別が色で区別されています

ブルー internal PHP言語の標準関数
オレンジ procedural WordPressやpluginで定義された関数
グリーン class クラス定義メソッド関数
グレー include 外部ファイル(ライブラリ等)の読み込み

Invocation Count

その関数が呼び出された回数 

Total Self Cost

その関数自身の全体に対する処理時間の割合(%)、または実行時間(msec / usec)

表示単位を msec にしていれば、この Total Self Cost の総計が、そのページを表示するのにかかった時間となります。従って、上位に表示されている関数がボトルネックということになります

このローカル環境でのサンプル画像の場合だと、データベースへの接続と翻訳関連の処理がボトルネックとなっているのがわかります

Total Inclusive Cost

その関数の呼び出し先の処理を含む全体に対する処理時間の割合(%)

これは percent 単位の表示のほうがわかりやすいので例として表示単位を percent とした場合で見てみます

Total Inclusive Cost 部分をクリックして関数をソートします

webgrind-inclusive

一番上に main が 100% で表示されます

main からプログラムが始まり、関数から関数へより深く下位の階層へ呼び出されていく感じです

私も正確には理解出来ていませんが全体からみてどの程度上位層に位置する関数なのかの指標というふうに理解しています

違っているかも知れません (^_^;)

 ソート表示

先ほど Total Inclusive Cost でソートしてみましたが、各表示項目ごとにソートすることが出来ます

function 種別ごとに並び替える
Invocation count 呼び出し回数順に並び替え
Total self Cost 個別処理時間順に並び替え
Total Inclusive Cost 全体処理時間順に並び替え(階層)

これらの情報を参照して改善点を見つけていきます

  • Self Cost の大きい関数(ボトルネック関数)
  • Invocation count 沢山呼ばれている関数
  • ライブラリが適切に呼び出されているか
個別に追跡する

特定の関数を調べたければ、ブラウザの検索機能(Chrome なら ctrl F キーで検索ボックスが表示される)でキーワードを打ち込みサーチすることが出来ます

調べたい関数(例えば自作の関数  htmltagsplit_keyword)をクリックすると

webgrid-function

  • calls – この関数から呼び出している関数
  • called from – この関数の呼び出し元関数

を見ることが出来ます

calls に表示された関数をクリックしていけば、より下位層で呼ばれている関数を順に調べていくことが出来ます

called from に表示された関数をクリックしていけば、どこから呼ばれているのか上位層の関数を追跡出来ます

また、右端のチャートのようなマークをクリックすると該当するソースコード部が表示されるのでPHPの処理内容を確認することが出来ます

時間のかかる処理を特定してより高速な処理に書き換えたり、無駄なことをやっていないかを調査します

チューニング

これらのツールを使い 測定 → 解析 → プログラム改良 を繰り返して高速化していきます

直せるかどうかは別にして、このぐらい調べれば何がボトルネックになっているかを見つけることは出来ると思います

以上

WordPressのボトルネックを見つける為の解析ツールの紹介でした (^^)

 


まとめ記事紹介

search star user home refresh tag chevron-left chevron-right exclamation-triangle calendar comment folder thumb-tack navicon angle-double-up angle-double-down angle-up angle-down quote-left googleplus facebook instagram twitter rss