サイトの表示が遅いと感じたら、ボトルネックを調べる為に解析ツールを使いましょう
WordPressのプラグインやテーマを開発されているプログラマー向けの内容となりますが、WordPressが動作する為に裏でいろんなことが行われているのが見られるので、なかなか興味深いです (^^)
ボトルネックを探しだせ
外側から徐々に内側へダイブしていきます
- ブラウザー解析ツール（PageSpeed, YSlow)
- データベース解析 （Query Monitor）
- PHP解析 プロファイラー（Xdebug、WebGrind）
ここで紹介する解析は、基本的には、ローカル環境のXAMPP上に構築した WordPress を対象にしています
それでは順に紹介していきます
ステップ１ ブラウザの解析ツール
外側から計測する
いろんなところで紹介されていますが、gtmetrix という PageSpeed, YSlow を使用してパフォーマンスを解析してくれるサイトがあります
公開しているサイトなら gtmetrix で PageSpeed, YSlow 同時に診断できますが、今回はローカル環境で解析していくのでブラウザの拡張機能を使います
YSlow
Yahoo が開発している解析ツールです
https://developer.yahoo.com/yslow/
ここのページから各ブラウザ用の拡張機能のリンクがあるので、クリックしてインストールします
後は解析したいページをブラウザで表示したら、ツールバーに追加された YSlow のアイコンをクリックすれば解析してくれます
詳しはこのサイトで紹介されています [パフォーマンス] サイトのパフォーマンス問題を発見できるYSlowというツールを使ってみた。指標の内容一覧など。
PageSpeed
google の開発している解析ツールです
PageSpeed Insights Browser Extensions
ここのページから各ブラウザ用の拡張機能のリンクがあるので、クリックしてインストールします
これはデベロッパーツールに追加される機能なので、ctrl Shift I キー３つを同時押しすると PageSpeed というタブが追加されているので、そこの 分析 という赤いボタンをクリックして解析を行います
詳しくはこのサイトで紹介されています PageSpeedを使ってWebサイトを最適化・高速化しよう
最初の段階は、この２つのツールで指摘された事項への対策を施します
リンクの紹介だけでステップ１は、いきなり手抜きしてしまいました (^_^;)
これらのツールは改善提案をしてくれますが、正直に言うとよくわからない項目もあるし、実現が難しいものもあります
それでも、出来ることはないか調べ、対応することである程度の高速化は出来るし、何がボトルネックとなっているのかもだんだんわかってきます (^^)
また、サーバー側での対策も大変有効なので、このあたりの記事も参考にして下さい
mod_deflate, mod_expires を使用してHTTP通信データ量を削減
この段階で判断出来る項目は下記のような内容となります
- サーバーの設定は適正か
- 画像のサイズや数は適正に使われているか
- 設定やプラグインによって遅くなっていないか
プラグインが原因の場合等では、何がボトルネックとなっていて本当にそれが必要なのか、あるいは代替手段はないか等様々な検討を行います
ステップ２ データベースのクエリー解析
ステップ１で様々な対策を行えば、そこそこ高速化出来ますが、まだ動作が遅い場合には、WordPressのデータベースのクエリーを解析していきます
MySQLデータベースの解析は、ログが有効にしてあれば MySQL Workbench 等で参照できます
ただ、あまり見やすいものではありません. これではちょっとつらいので、WordPressプラグインの Query Monitor がお勧めです
Query Monitor
これを使用すると簡単にデータベースのクエリーを見やすく表示してくれます
インストール
通常のプラグインと同じです。新規追加から Query Monitor を検索してインストールできます
設定
インストールするだけで設定はありませんが、ツールバーに結果の簡易表示と操作メニューが追加されるので、管理画面のユーザーのプロフィールでツールバー表示が有効になっているかは確認して下さい
実行
実行するのは簡単で、ブラウザから解析したいページを読み込むだけです
ツールバー上に結果が表示され、左からページの読み込み時間、サイズ、クエリー時間、クエリー数を表しています
さらにそこにマウスを持って行くとメニュー表示されるので表示したい項目をクリックすると詳細なデータを参照できます
クエリー
クエリーコマンドだけでなく、それを発行した元の関数名（例えば get_option 等）、実行時間も表示されます
また、スロークエリーがあれば分かりやすく強調表示されます
クエリー発行元の関数の統計情報もあります
これもなかなか便利です
Hook毎のアクション（そこにフックしている関数とその優先度）の一覧
これもいいです
使用している transient api での名称と有効期限等
これ以外にもいろんな情報を表示してくれます
じぇじぇじぇー 素晴らしすぎます (^^)
ここからデータベースがらみのボトルネックを見つけていきます
- どのようなクエリーが発行されているのか
- 想定外のクエリーが発行されていないか
- 遅い（時間のかかる）クエリーはなにか
- 何回も同じクエリーが発行されていないか
呼び出し元の関数名もわかるので、必要最小限のクエリーを発行するためにどうするかのヒントを沢山得ることが出来ると思います
これでプロファイラー機能もあれば鬼に金棒なのですが、プラグイン作者が将来的に機能追加するかもといっているので期待大です (^^)
ステップ３ 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/ というページの解析を行い時は
ブラウザで読み込ませると、先ほど設定した C:\xampp\tmp にプロファイル情報ファイルが生成されます
解析するにはツールが必要
作成された情報ファイルを見てもそのままでは理解できません。この解析するためのツールがいろいろあるようです
高機能なものでは、KCacheGrind という解析ツールがあるようです。ただ、KDE環境が必要なようなので使用したことはありません (^_^;)
ここでは、ブラウザを使用して解析できる webgrind を紹介します
webgrind
インストール
webgrind-release-1.0.zip をダウンロードして解凍します
解凍した webgrind をフォルダーごとドキュメントルートの htdocs 下にコピー
config.php 設定
Webgrindはconfig.phpファイルを編集することで設定できますが、Xdebugが今までの手順通りにインストールされているなら変更しなくても動作するはずなので修正は不要です
実行
ブラウザのアドレスバーにwebgrindのURLを入力します
webgrind はドキュメントルート下に設置しているので
http://localhost/webgrind/ とすると表示されます
既にプロファイル情報データを作成してあれば、ここで update ボタンをクリックすれば一番新しいプロファイル情報データが表示されます
使い方
わかる範囲でざっくりと説明します (^^)
プロファイル情報選択
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 部分をクリックして関数をソートします
一番上に main が 100% で表示されます
main からプログラムが始まり、関数から関数へより深く下位の階層へ呼び出されていく感じです
私も正確には理解出来ていませんが全体からみてどの程度上位層に位置する関数なのかの指標というふうに理解しています
違っているかも知れません (^_^;)
ソート表示
先ほど Total Inclusive Cost でソートしてみましたが、各表示項目ごとにソートすることが出来ます
| function | 種別ごとに並び替える |
| Invocation count | 呼び出し回数順に並び替え |
| Total self Cost | 個別処理時間順に並び替え |
| Total Inclusive Cost | 全体処理時間順に並び替え（階層） |
これらの情報を参照して改善点を見つけていきます
- Self Cost の大きい関数（ボトルネック関数）
- Invocation count 沢山呼ばれている関数
- ライブラリが適切に呼び出されているか
個別に追跡する
特定の関数を調べたければ、ブラウザの検索機能（Chrome なら ctrl F キーで検索ボックスが表示される）でキーワードを打ち込みサーチすることが出来ます
調べたい関数（例えば自作の関数 htmltagsplit_keyword）をクリックすると
- calls – この関数から呼び出している関数
- called from – この関数の呼び出し元関数
を見ることが出来ます
calls に表示された関数をクリックしていけば、より下位層で呼ばれている関数を順に調べていくことが出来ます
called from に表示された関数をクリックしていけば、どこから呼ばれているのか上位層の関数を追跡出来ます
また、右端のチャートのようなマークをクリックすると該当するソースコード部が表示されるのでPHPの処理内容を確認することが出来ます
時間のかかる処理を特定してより高速な処理に書き換えたり、無駄なことをやっていないかを調査します
チューニング
これらのツールを使い 測定 → 解析 → プログラム改良 を繰り返して高速化していきます
直せるかどうかは別にして、このぐらい調べれば何がボトルネックになっているかを見つけることは出来ると思います
以上
WordPressのボトルネックを見つける為の解析ツールの紹介でした (^^)
