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

公開:2015-02-22 / 制作・開発 テスト / ,
更新:2017-02-11

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

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

 

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

 

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

 

Debug Barとは

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

 

デバッグって何?

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

 

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

 

ふーむ、なるほど。

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

 

「Xserverから高負荷アラートが来た。その1~3」で紹介したブログを呼んでいただくとわかりますが、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」で検索し「今すぐインストール」ボタンをクリックします。

720-1

 

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

720-2

 

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

720-3

 

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

720-4

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

 

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

720-5

720-6

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

 

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

 

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

 

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

720-7

 

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

720-8

 

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

720-9

 

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

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

720-10

 

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

720-11

 

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

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

720-12

 

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

720-13

 

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

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

 

注意事項

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

 

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

720-21

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

 

 

調査(実践)

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

 

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

 

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

720-14

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

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

 

どこかの文献で、

 

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

 

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

 

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

 

調査にはProfilerを使います。

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

720-15

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

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

 

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

 

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

 

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

 

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

720-16

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

 

処理の名前を見てみると、「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”)」を記述

 

の対応を行って、ページをリロード。再度、DebugのProfilerを見てみると、

720-17

出ました!

タグクラウドの表示処理に時間がかかっていることがわかりました!

 

早速タグクラウドの処理を最新の1件しか出さないように見直して、再度Debugで見てみると、、

 

んん?

あんま変わらない。。。。。

 

設定弄っただけじゃあまり変化ないのかな???と思って前後の値を比較してみると、

720-22

なんと、人気記事のPopularのほうに効果が出ていることがわかりました。

(実行する毎に若干数値が変わるので何度か試してみましたがやはり人気記事の処理速度が上がっていました)

 

もしかしてその一個前の処理を改善すればいいってこと?

 

試したほうが早いので、タグクラウドの前の処理である、カテゴリ一覧の設定を見直したところ、

720-18

おぉ!

すげー早くなってる!

 

720-19

さっき、900msあった箇所が19msになってますね。

 

さっきの「一個前の処理を改善すればいいってこと?」の仮説が証明されました。

にしてもわかりづらい!

みなさんも利用する際は十分に気をつけてください。。。

 

Debug-Bar-Extenderの作者には、表示を何とかして欲しいと思います。

っと思ったらすでに4年以上アップデートないのね。。。

こりゃ別ツールを探したほうがいいかも。。。

 

まぁ、なんにせよ、これで2秒以内になり、当初の目的は達成されました!

めでたしめでたし。

 

所感

と、ここまで書いた内容を読み返してみましたが、なんだか簡単に見えますね。。。

ブログ用にまとめながらだからなのですが、実は結構苦労しました。

 

丸二日はこの作業に取られたと思います。

改めてエンジニアの気持ちがわかりました。

 

僕はプロジェクトマネージャーなので開発案件で自ら手を動かすことはないので、負荷テストの結果、表示が遅かったりすると、「原因特定」の作業を指示し、原因がわかったらエンジニアとソリューションを検討し、実行させます。

 

普段は、「アプリ・データベースのチューニングをしてくれ」と指示を出すだけなのでわかりませんでしたが、実際やってみると超超超超超大変であるということを身をもって思い知りました。。。

 

こんなに時間がかかるとは思ってませんでしたが、この経験が、エンジニアとのソリューション検討の際に生かされると思うと、早く新しい開発案件こないかなーと思ったりする今日この頃です。

Author:yukio iizuka
プロフィール画像
フリーランスとしてUX視点で業務支援しています。 HCD-Net認定 人間中心設計専門家 LEGO®︎ SERIOUS PLAY®︎ メソッドと教材活用トレーニング修了認定ファシリテーター Hi-Standard好きです。
http://yukioiizuka.com
mislead
MISLEADの記事に共感いただけましたら
いいねをお願いします。

コメント一覧

コメントはありません

コメントを残す

*

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください



       

© yukio iizuka All Rights Reserved...