WordPressのサイト表示が遅い原因の調査 Debug Barプラグインの紹介

公開：2015-02-22 / 制作･開発テスト / MySQL, Xserver
更新：2017-02-11

WordPressを利用したサイトである程度集客に成功した方は、

サイトがなかなか表示されない。。。

という悩みを抱えたことがあるのではないでしょうか。

何を隠そう、僕もその一人です。

過去に、Xserverから高負荷アラートが来た。その１で紹介したとおり、WordPressのサイトで月間100万PVを達成したのですが、レンタルサーバ業者であるXserverから、

データベースにかかる負荷が高すぎます！

というアラートを受け、その場しのぎで対応した経緯があります。

ですが、やはりその場しのぎだったため、1ヵ月後にXserverから同じアラートを受けてしまいました。。。

（詳しくは、Xserverから高負荷アラートが来た。その３を参考にしてください）

今回は根治させるべく、きちんと原因を特定し対応することにいたしました。

本日は、対応にあたって利用したプラグイン「Debug Bar」を紹介したいと思います。

Debug Barとは

このプラグインは、その名のとおりデバッグを助けてくれるものです。

デバッグって何？

という人のためにwikipediaを引用しておきます。

デバッグ (debug) とはコンピュータプログラムや電気機器中のバグ・欠陥を発見および修正し、動作を仕様通りのものとするための作業である。

ふーむ、なるほど。

引用して気が付きましたが、僕がイメージしている作業とはちょっと違いますね。

「Xserverから高負荷アラートが来た。その１～３」で紹介したブログを呼んでいただくとわかりますが、Xserverからは、

あんたのとこのサイトはデータベースへの負荷をかけすぎだから何とかしてちょうだい

といわれただけで、僕の構築したWordPressサイトは、欠陥があるわけではなく仕様どおりに動いてくれています。

この対応は、アプリを見直してもいいし、Xserverの上位プランを契約変更してもよいわけです。

今回の指摘に対して、僕は、

お金をかけずに、サイト側で工夫することで何とかする。

と判断しました。

なので、僕がやろうとしているのは、「チューニング」ですね。

対象はデータベースです。

ちょっと脱線しましたが、僕がやろうとしている作業にあたって必要なプラグインであることは間違いないので、細かいことはおいておきます。

具体的に何ができるのか

Debug Bar単体だと、

各種ソフトウェアのバージョン
メモリ使用量の表示
SQLリクエストに対してのWordPressの処理
SQL のクエリの数と経過時間

程度しかわかりません。

ですが、「Debug-Bar-Extender」もあわせて利用することで

wp-config.php を修正せずに、データベースのパフォーマンスチェックができる（Debug Bar 単体だと、wp-config.phpへの記述が都度必要なので、手間がかかる）
WordPressの処理にかかる時間が計測できる（さらに、処理の途中に、任意で計測ポイントを設けることで、より詳細な処理時間を計ることができる）
PHPの変数の内容確認ができる

といったことまで可能になります。

これを利用することで、データベースに負荷をかけているクエリをあぶり出し、チューニング対象箇所とその対応案を検討できます。

（昔、プログラマー時代、perlでアプリケーション開発をしたことがあります。perlはインタプリタのため、デバッグは常にprintして確認していました。そんな経験があったためか、このプラグインを見つけたときは感動しました。。。）

導入方法

WordPress管理画面から、プラグインの新規追加で「Debug Bar」で検索し「今すぐインストール」ボタンをクリックします。

インストールが完了したら、プラグインを有効化をします。

以下の画面の通り、完了のメッセージが表示されると、画面右上に「Debug」というリンクが表示されます。

「Debug」をクリックすると、左メニューが「Object Cache」のみの状態で、以下のような表示になります。

この機能は今見えているページに対してdebugをしてくれるので、上の画面は、管理画面のプラグイン一覧ページにdebugになります。

なので、管理画面にログインした状態で投稿ページへ遷移し、Debugをクリックすると、

上の画面のとおり、「Request」の画面が表示され、エンコードされた文字列が見えます。

使うとわかりますが、正直「Debug Bar」単体だとあまり有効な使い方はできません。

今回の目的であるMySQLのどこに負荷がかかっているかを調べるためには、「Debug-Bar-Extender」のプラグインもインストール必要がありますので引き続き、「Debug-Bar-Extender」もインストールしていきます。

Debug Barと同様に「WordPress管理画面 > プラグインの新規追加」、「Debug-Bar-Extender」で検索し「今すぐインストール」ボタンをクリックします。

インストールが完了したら有効化します。

完了したら右上のDebugをクリックします。

すると、左側のメニューにいくつか追加されているのがわかります。

投稿ページで実際の表示を確認してみます。

先ほどと同様に投稿ページへ遷移し、Debugをクリックします。

左メニューの「Queries」がデフォルトで選択された状態で開かれ、画面上に大きくSQLクエリの実行数と実行時間が表示されています。

その下には、実行しているSQL文が見えます。

さらに「Profiler」をクリックすると、データベースへ接続していると思われるPHPのファイルが細かく表示れてるかと思います。

これで準備は整いました。

以降で、実際に調査をしてみたいと思います。

注意事項

プラグインをインストールし、有効化したのにも関わらず、画面右に「Debug」が表示されないことがあります。

その場合は、管理画面の左メニューの設定から「Debug-Bar-Extender」をクリックし、画面下の「Enable admin bar menu」を「YES」にすると表示されます。

（操作した覚えはないのですが、この状態になってハマったので同じ現象の方がいたら試してみてください）

調査（実践）

僕が使っているテストサイトである「penguinweb.net」だと、大した記事数もないので、そんなに重くありません。

なので別で運用しているサイトを使って調査をしてみたいと思います。

対象のサイトに、WordPressの管理画面にログインをしてから、画面右上のDebugをクリックします。

この画面キャプチャの通り、このページは表示する際に、28 個のSQLクエリを実行し、結果、2471.8ms(≒ 2,4秒）かかっていることがわかります。

ちなみに、1000ms = 1秒です。

どこかの文献で、

サイトを表示するのに２秒以上かかるとユーザは離脱する

というのを見たことがありますが、それを信じると、このサイトは離脱されてしまう可能性があるということになります。

それはまずいので、このページの表示を２秒以内にしてみたいと思います。

調査にはProfilerを使います。

Profilerをクリックすると、以下の通り「Summary」の後に「Flow」というものがあるのがわかります。

このSummaryですが、Debug-Bar-Extenderは、特に設定していないと主要な箇所チェックポイントを自動で配置してくれます。

Summaryはその主要なチェックポイント毎に、処理状況が見れるようになってます。

Flowは、WordPressがページを表示するときに実行している処理を上から順番に表示しています。

WordPressは通常、index.phpのテンプレートにheader.php , sidebar.php , footer.phpをインクルートしていますので、その処理順に表示をしてくれます。

Summaryだとちょっとどこの処理が重たいのかがわかりづらいので、Flowを1個づつみて処理時間がかかているものをピックアップします。

このサイトでは、処理に600msかかっている処理が２つ見つかりました。

このサイト内の処理を相対的にみると結構重い処理のようです。

処理の名前を見てみると、「Call Sidebar」「Call Footer」と書いてあります。

これは、名前から想起できると思いますが、それぞれ「get_sideber()」「get_footer()」の関数を呼び出ししている箇所になります。

フッターは、フッターサイトマップとcopyrightくらいしかないので、WordPressの機能上実行しないといけない処理だと思われるので、一旦ここでは諦め、サイドバーに絞ってさらなる調査をしていきます。

サイトバーには、「カテゴリ一覧」「タグクラウド」「人気記事の表示」の機能があり、いづれかの処理に負荷がかかっているということになります。

Debug-Bar-Extenderは、そういうときのために、被疑をかけるポイントをより明確にするために、チェックポイントを指定することが出来ます。以下のソースを被疑をかけたい処理の直前に記述すると、そのチェックポイントを通過するタイミングをProfilerに表示してくれます。

Debug_Bar_Extender::instance()->start()
調査開始位置の指定です。この地点から計測が開始されます。
Debug_Bar_Extender::instance()->checkpoint()
チェックポイントになります。ここを通った時点の時間が記録され、Profilerに表示されます。
Debug_Bar_Extender::instance()->end()
調査終了位置の指定です。この地点で計測が終了されます。

なので、

index.phpの「get_header()」の前に「Debug_Bar_Extender::instance()->start(“Start”)」を記述
index.phpの「get_footer()」の後に「Debug_Bar_Extender::instance()->end(“End”)」を記述
sidebar.phpのカテゴリ一覧の前に「Debug_Bar_Extender::instance()->checkpoint(“Category”)」を記述
sidebar.phpのタグクラウドの前に「Debug_Bar_Extender::instance()->checkpoint(“Tag”)」を記述
sidebar.phpの人気記事の前に「Debug_Bar_Extender::instance()->checkpoint(“Popular”)」を記述