New Relic APMは、WordPressサイトの内部構造を掘り下げ、パフォーマンスの問題を引き起こしているプラグイン、テーマテンプレートファイル、データベースクエリ、外部呼び出し、コーディングエラーを確認できる強力なツールです。
New Relicライセンスをお持ちのKinstaのお客様は、MyKinstaにNew Relicを追加することができます。
New Relicをサポートしていないサーバーを利用している、あるいは自己ホスティング型のプライベート環境でサイトを稼働している場合は、自分で統合することも可能です。
とはいえ、New Relicを最大限に活用するには、これまで使用したことがない場合（使用した経験があっても）難しいかもしれません。そこで今回は、New Relic APMを使ってWordPressサイトのパフォーマンスに関する問題を確認し、修正する方法をご紹介します。
New Relic APMとは
New Relic APMは、WordPressサイトのパフォーマンスに関する詳しい情報を取得するためのウェブアプリケーションです。
New Relicをインストールするには、PHPに拡張機能を追加します。この拡張機能は、PHPによって処理されるすべてのリクエストをリッスンしてNew Relicに返します。受信したデータは一連のチャートとグラフに整理されるため、サイトのパフォーマンス問題を診断するのに役立ちます。なお、New RelicはHHVMではサポートされていません。
以下、New Relicでのデータの見え方を簡単にご紹介します。
概要（Overview）
「Overview（概要）」ページでは、ウェブサイトの全体的なパフォーマンスのスナップショットを見ることができます。このページから特定の問題を診断することはできませんが、PHP、MySQL、外部呼び出しがどのように連携しているかを把握するのに便利です。
このページの詳しい情報は、公式ドキュメントをご覧ください。
トランザクション（Transactions）
「Transactions（トランザクション）」ページは、New Relicで最も便利なページです。
遅いトランザクションを掘り下げ、データベース呼び出し、外部リソース、またはサイトの速度を低下させているコードのボトルネックを特定sすることができます。特に興味深いのは遅いトランザクションの一覧で、「Transactions」ページの下部にあります。
このセクションには、New Relicによってキャプチャされた最も遅いトランザクションが一覧表示されます。後ほど、このセクションを使ってサイトの問題を診断する方法を見ていきます。
このページに関する詳しい情報は、公式ドキュメントをご覧ください。
WordPress Hooks（フック）
WordPressの「Hooks（フック）」ページは、WordPressのアクションフックを介してトリガーされたPHP関数が費やした時間を可視化します。上級開発者はこのデータを元に、過負荷のフックから逆にどの関数がそのフックによって発火されるかを特定するのに役立ちます。
WordPress Plugins and themes（プラグインとテーマ）
WordPressの「Plugins and themes（プラグインとテーマ）」ページは、プラグインとテーマが消耗するPHP処理時間を表示します。特定のプラグインまたはテーマが膨大な時間を消費している場合、問題の原因となっているプラグインまたはテーマを素早く見つけることができます。
なお、この「Plugins and themes」ページは、最も誤用が多いページになります。
サイトのパフォーマンスの問題を調査する際、まずこのページを最初に確認し、パフォーマンスの妨げになるプラグインを単に無効化して解決したいと思うかもしれませんが、それでは宝の持ち腐れです。New Relicで取得できる貴重なデータを無駄にすることになり、根本的な原因の特定になりません。
例えば、会員管理プラグインが不正なSMTPポート番号の使用によって動作が遅くなるなど、プラグインの設定ミスによって動作が遅くなることがあります。あるいは、プラグインが正しくアンインストールされていない可能性も。このような情報は、先ほどの「Transactions」ページで遅いトランザクションを掘り下げることで導き出せます。単に最も時間のかかるプラグインを無効にするだけでは問題は解決されません。
そのため、このページだけに依存せず、他のデータもうまく活用していきましょう。
データベース（Databases）
「Databases（データベース）」ページでは、最も時間のかかるデータベーステーブルとクエリの種類が表示されます。このデータはそのクエリを実行しているトランザクションに関連付けられます。このデータを利用して、最適化の余地があるデータベーステーブルや、データベースに過大な負荷を与えているテンプレートファイルを特定することができます。
外部サービス（External services）
ほとんどのWordPressサイトは、以下のようなさまざまな外部サービスに依存します。
- プラグイン、テーマ、コアの更新は、wordpress.orgだけでなく、プラグインやテーマの開発者からも配信される
- 多くのプラグインは、WPMU DEVの画像最適化プラグインSmush（上のスクリーンショットの「smushpro.wpmudev.org」）のように、サードパーティAPIと統合されている
- チャットプラグインは一般的に外部サービスから提供されている
- 多くのサイトはSNSプラットフォームと統合されている（コンテンツが共有される際に適切な表示とパフォーマンスを実現）
これらの外部サービスのいずれかがスムーズに動作しなくなると、ウェブサイト全体が停止してしまうことがあります。
「External services（外部サービス）」ページでは、どの外部サービスが時間を消費しているかを一目で確認可能です。このデータを元に、速度の問題（サービスの応答が遅い）、あるいは量の問題（外部ソースへの呼び出しが多すぎる）であるのかを判断して、然るべき対処を行うことができます。
エラー分析（Error analytics）
「Error analytics（エラー分析）」ページでは、WordPressサイトの読み込み中に発生したPHPエラーを確認できます。エラーはクラスごとに分類され、発生したエラーの種類も簡単に把握できます。エラーは、エラーを引き起こしたトランザクションにも関連付けられ、特定のエラーを選択すると、トランザクションのスタックトレースも表示されます。
このエラー分析は、整理されたPHPのエラーログのようなもので、PHPエラーを引き起こしているファイルやトランザクションを特定するのに貴重なデータとなります。
読み込みの遅いページのデバッグ
New Relicを使ってデバッグを行う典型的な状況としては、特定のページやプロセスの読み込みに非常に時間がかかっている場合です。この状況ではまず、「Transactions」ページを開くことになります。
読み込みが遅いページを特定するのは非常に簡単です。
- 遅いトランザクションを複製する
- 遅いトランザクションを見つける
- トランザクションの概要とトレースの詳細を確認する
以下、問題を診断するための各ステップを詳しくご紹介します。
ステップ 1. トランザクションを複製する
例として、個々のブログ記事が読み込まれるたびに表示速度が遅くなるという実際にあった顧客の問題を見てみます。他のページはすべて正常に読み込まれるにもかかわらず、個々の記事の読み込みには数秒かかっていました。
最初のステップは、問題を再現することです。この場合、New Relicが必要な日付を確実にキャプチャするよう、単一のブログ記事に数回アクセスしてみます。
注）Kinstaのページキャッシュをご利用の場合は、問題を再現するため、各ページの読み込みの間にキャッシュをクリアしてください。
ステップ2. 遅いトランザクションを見つける
遅いトランザクションを何度か複製したら、New Relicにアクセスして、「Transactions」ページを開きます。ページを下にスクロールして、先ほどご紹介した「Transaction traces」セクションを確認します。
デバッグの対象となるトランザクションをクリックして、詳細を確認します。
ステップ 3. トランザクションの概要とトレースの詳細を確認する
トランザクションを選択すると、以下のように概要（Summary）が表示されます。
トランザクションの処理時間に影響を与えた要素のスナップショットが表示されます。この例の場合、トランザクションの完了に合計5,350ミリ秒かかったうち、外部リソース（www.googleapis.com）への呼び出しが5,000ミリ秒を占めていることがわかります。
「Summary」タブの横にある「Trace details（トレースの詳細）」タブには、何が起こっているかをより正確に知ることができます。
このタブでは、PHPがページを生成する際に処理する関数、データベースクエリ、外部呼び出しが階層的なウォーターフォールチャートで表示されます。
この例の場合は、Google アナリティクスのURLへの呼び出しが処理を妨げています。このリクエストを遡ると、gapp_get_post_pageviewsというPHP関数から始まっています。このトランザクションをGoogleで検索すると、Google Analytics Post Pageviewsプラグインの一部であることがわかりました。このプラグインは、固定されたヘッダーバーにビューカウンターを実装するものです。
このように、New Relicから取得したデータを元に、このビューカウンターが単一ブログ記事の読み込みを遅くしている主な原因であることを突き止めることができました。これで、ブログ記事の表示速度を改善するためにどの要素に対処すればいいのかが正確にわかります。
サイト全体の速度低下
サイト全体の読み込みが遅いというのもトラブルシューティングが必要な一般的な問題の1つ。すべてのトランザクションの読み込みに時間がかかる場合は、以下のいずれかが原因である可能性が高いです。
- サイトのサーバーリソースが不足している
- プラグインまたはテーマが問題を引き起こしている
- サイトのデータベースがクエリの速度に追いついていない
Kinstaをご利用の場合は、スケーラブルな仮想マシンが柔軟に負荷に対応するため、サーバーリソースが不足しているということはほとんどありませんが、サイトのCPUやRAMが不足している場合、サイト全体の速度が低下する可能性があります。したがって、New Relicのデータからあらゆる要素が原因になっていることがわかれば、サーバーリソースが不足しているかどうか、サーバーの負荷をチェックしてみてください。
サイトのサーバーに十分なリソースがある場合は、引き続きサイト全体の速度低下を診断するため、WordPressの「Plugins and themes」「External services」「Databases」タブを確認してみます。
以下、各タブで確認できる例を見てみましょう。
プラグインに起因する速度低下
プラグインがサイト速度の原因となっている場合は、プラグインが実行するアクティビティによって異なります。多くの場合、低速なプラグインはWordPressサイトのすべてのページに影響を与えます。下の例では、サイトのすべてのフロントエンドページで速度低下が見られます。
このグラフから、adinjectorプラグインがそのほかのプラグインの15倍以上の時間を消費していることが一目でわかります。
このようなデータを見ると、プラグインのコードの質が良くない、思い通りに機能しないなどと判断したいところですが、実は必ずしもそうではありません。プラグインの設定ミス、データベースの遅さ、外部リソースの反応の遅さなどが原因になっている可能性もあります。
したがって、反応が遅いプラグインを特定したら、New Relicのその他のページも確認して、追加情報を見つけることをおすすめします。トランザクション、データベース、外部リソースをすべて確認した上で、プラグインの削除が最善なのか、または唯一の方法であるのかを判断しましょう。
外部サービスに起因する速度低下
サイトがページビューを生成するために外部サービスへの呼び出しに依存していると、そのサービスが停止したり、応答に時間がかかったりすると、WordPressサイトが完全に停止してしまいます。
上のスクリーンショットは、先ほどのプラグインが原因であったサイトのものです。圧倒的に待ち時間の長い外部サービスが1つあることがわかります。
これがまさに、結論を出す前にデータを組み合わせた分析が必要になる理由で、この例で呼び出されているサービスは、最後のステップで特定したプラグインの開発者でした。
このデータを分析すると、プラグインのコード自体に問題があるわけではなく、プラグインが開発者のサイトを何度も呼び出しており、この呼び出しによって時間がかかっているようです。
さらに一歩進み、遅いトランザクションを確認してみると、この外部呼び出しは該当のプラグインのライセンス状況をチェックしているようでした。この特定のプラグインのライセンスの有効期限が切れている可能性を示唆しています。
この事例の結論としては、パフォーマンス低下の原因はadinjectorプラグインにあり、具体的にはライセンス状況を確認するために開発者のサイトへの呼び出しが繰り返されていることが原因で、速度が低下していると診断できます。
データベースの過負荷による速度低下
データベースの最適化が十分に行われていない場合もまた、WordPressサイト全体が遅くなる原因です。Kinstaで常に推奨している最適化の1つは、データベースをMyISAMからInnoDBへの移行です。New Relicでは、データベース関連の遅さは、通常以下2つの場所に表示されます。
- 「Overview」ページでMySQLのアクティビティが大量に表示されている
- 「Databases」ページで時間を消費している単一または複数のデータベーステーブルが表示されている
前者から見ていくと、問題のあるデータベースを持つサイトは以下のように表示されます。
どのデータベーステーブルやクエリが問題を引き起こしているのかを把握するには、「Databases」ページを開きます。
このタブで、最も時間がかかっているテーブルとクエリの種類がわかります。一覧内のエントリを選択すると、サンプルクエリを含む詳細を確認できます。
この場合は、wp_optionsテーブルの自動読み込みされたデータです。予想通り、wp_optionsテーブルを簡単に分析したところ、このテーブルから250MB近いデータが自動読み込みされていることが確認できました（wp_optionsテーブルと自動読み込みされたデータを最適化する方法はこちら）。
New Relicを使ってWordPressサイトをデバッグしてみよう
New Relicは、使い方さえわかれば、WordPressサイトのPHPパフォーマンスのボトルネックを特定するための頼もしいツールになります。New Relicを最大限に活用するには、WordPressを理解し、各タブで取得できるデータを読み取り、データ間の関連性も含め情報を全体的に分析することが重要です。
関連記事として、『WordPressサイトのパフォーマンス問題をデバッグする方法』もぜひご覧ください。
コメントを残す