2017/10/10

翻訳: New Relic を使って WordPress のパフォーマンスのボトルネックを探す方法

今回は、WordPress のパフォーマンスのボトルネックを New Relic を使って調査する記事の翻訳版です。New Relic には、WordPress 専用の UI が用意されているほど WordPress のパフォーマンス分析を重視しています。また、この記事は、一般的な New Relic を使ったパフォーマンスを分析の入門記事的な側面もあります。是非、New Relic APM を使って、パフォーマンスを分析をしたい方、興味ある方はご覧ください。参考になると思います。


タイトル: How to Find WordPress PHP Performance Bottlenecks with New Relic
著者: Jon Penland
公開日: 2017.10.04


この記事は、ゲスト著者である Jon Penland は、WordPress のホスティング会社である Kinsta 社のセールス&サポート責任者です。この投稿のオリジナルは、Kinsta のブログに掲載されています。

Kinsta では、サポートエンジニアは毎日 New Relic APM を使っています。顧客のサイトのプラグイン、テーマテンプレートファイル、データベースクエリ、外部呼び出し、そしてパフォーマンス上の問題を引き起こすコーディングエラーを特定するために、WordPress やその他のサイトの内部動作を掘り下げることができる強力なツールです。

私たちは、デベロッパーフレンドリーな WordPress のマネージドホスティングを提供していることに自信を持っています。そのため、この強力なツールを我々自身だけで使うようなことはしません。我々のプラットフォームを使っているユーザーは、自身の New Relic ライセンスを追加することで、この強力な可視性を手に入れることができます。お使いのホスティングプロバイダが New Relic インテグレーションを提供していない場合は、プライベート環境でサイトをホストしているならば、自身で New Relic を設定することで利用することができます。

しかし、New Relic の利用は始まりに過ぎません。New Relic APM を初めて使う場合は、この強力なツールを最大限に活用するためにヘルプが必要かもしれません。このチュートリアルのゴールは簡単です。New Relic APM を使って、WordPress の
サイトをどのように修正できるのかを示すことです。ナードになる準備ができていますか? では始めましょう!

New Relic APM の概要についての簡単な紹介

New Relic APM をインストールするには、PHP にエクステンションを追加します。そのエクステンションは、PHP で処理されたすべてのリクエストを受け取り、その情報を New Relic ダッシュボードに送信します。New Relic は、その情報を、サイト上のパフォーマンスの問題を診断するために使用するチャートとグラフ上に整理して表示します。 (New Relic は PHP の HHVM ではサポートされていないことに注意してください)。

では、New Relic の主要なデータの視覚化パーツを簡単に見てみましょう。

Overview: Overview はサイト全体のパフォーマンスを簡単に把握できるビューを提供します。この画面から特定の問題を診断することはできませんが、PHP、MySQL、外部呼び出しがどのように連携しているかを示す便利なビューにより、現在の状態を知ることができます。APM Overview ページの詳細についてはこちらをご覧ください。

Transactions: Transactions タブは、New Relic の中で最も便利なタブです。Transactions タブを好きになれるようにしましょう。ここから、遅いトランザクションを深掘りして、サイトを遅くしているデータベース呼び出し、外部リソース、コードのボトルネックを特定できます。特に興味深いのは、トランザクションビューの遅いトランザクションのリストです。そのリストは、Transactions タブのビューで一番下までスクロールすると、ページの右下部分にあります。

そこには、New Relic が収集した最も遅いトランザクションのリストがあります。現時点で、(私達のサイト上では)このセクションに処理時間の多いトランザクションは表示されませんが、少し後、あなたのサイトの問題を診断するために、このセクションを使用する方法を説明します。New Relic APM のトランザクションページについては、こちらをご覧ください。

WordPress hooks: WordPress のフックタブは、WordPress アクションフック がトリガーした PHP の全機能が消費した時間を可視化します。この情報は、フックを発射した機能を識別するために、オーバーロードフックから逆方向に辿って調べられるため、経験豊富な開発者にとって便利な情報となります。

WordPress plugins and themes: WordPress のプラグインとテーマタブでは、プラグインやアクティブなテーマが消費している PHP の処理時間を表示します。単一のプラグインや使っているサイトのテーマが、特大の処理時間を費っている場合は、このページから、すぐに問題を引き起こしてプラグインやテーマを見つけることができます。

注: New Relic UI の WordPress Plugins and themes タブは悪用される可能性があります。サイトのパフォーマンスの問題を調査するとき、最初にこのタブをチェックし、単純に最も時間の掛かっているプラグインを無効化するという作業を行いたいという誘惑にかられるでしょう。しかし、そうすると、New Relic 中の別の場所で見つかった貴重な情報を無視することになります。つまり、症状の治療ではなく、根本原因を見つけるのに似ています。プラグインは、設定ミスの問題により遅くなっているかもしれません。例えば、SMTP のポート番号の設定ミスによって会員管理プラグインが遅くなっているかもしれません。もしくは、プラグインが正常にアンインストールされていない可能性があります。これらの問題は、Transactions タブから、遅いトランザクションに深掘りし、調査することで正確な情報を引き出すことができます。それがわかれば、単に最も遅いからという理由でプラグインを無効化するという対策は取らなくなるでしょう。よって、このタブを活用することで、快適なパフォーマンスを確保できるようになりますが、New Relic が提供するその他の情報も無視しないようにしてください。

Databases: Databases タブでは、最も時間を消費しているクエリのデータベーステーブルやタイプを識別できます。これらのクエリを発行しているトランザクションとこの情報を結び付けを確認できます。データベース上で特大の負荷がある最適化とテンプレートファイルを必要とするデータベーステーブルを特定する際に、この情報が役立ちます。New Relic APM データベースのページ詳細については、こちらをご覧ください。

External services: ほとんどの WordPress サイトは、多くの外部サービスを利用しています。

  • プラグイン、テーマ、コアの更新は wordpress.org だけでなく、プラグインやテーマの開発者からも配信されています。
  • 多くのプラグインは、WPMU DEV’s Smush 画像最適化プラグイン(上記のスクリーンショットにある wpmudev.org) などのサードパーティの API を利用しています。
  • チャットプラグインは、通常、外部サービスを使っています。
  • 多くのサイトでは、コンテンツをネットワーク上で共有す際に、最適なプレゼンテーションやパフォーマンスをあげるため、ソーシャルメディアプラットフォームと統合しています

こういった外部サービスが応答を停止すると、あなたのサイト全体の影響を与え、サイト停止にさえなることがあります。

External services タブでは、どの外部サービスがもっとも時間を消費しているかを簡単に確認できます。この情報から、それが、スピードの問題(サービスが応答が遅い)か、量(外部ソースに大量の呼出しをしている)かを判断できます。そして、問題の解決の方向性を正しく判断できます。New Relic APM の外部サービスのページ詳細については、こちらをご覧ください。

Error analytics: Error analytics タブには、WordPress サイトのロード中に発生した PHP のエラーが報告されます。エラーは、クラス別に分類されているため、どのタイプのエラーが多いのか簡単に把握できます。エラーは、エラーを発生した実際のトランザクションと関連付けれられています。特定のエラーを選択すると、エラーが発生したトランザクションの完全なスタックトレースを見ることができます。

エラー分析機能は、より整理された PHP のエラーログ と考えることができます。ログから、PHP のエラーを生成したファイルと、それらのエラーが発生したトランザクションを追跡しようとすると、この機能は非常に貴重機能であることが分かります。New Relic のエラー分析については、こちらをご覧ください。

読み込みの遅いページのデバッグ

私たちのチームが New Relic を使って、デバッグする頻度がもっと多い問題は、ロードするのに非常に長い時間がかかっているページやプロセスを特定したい場合です。これを確認する場合は、New Relic APM の Transactions タブが最初に見るべきデータです。

読み込みの遅いページの診断は非常に簡単です。問題のトランザクションが、ページ上で最も遅いトランザクションである場合、すぐに確認できます。そうでない場合は、以下を試してみてください。

  1. ページ上で最も重要な取引を強調するためにキートランザクションを設定します。
  2. ページ上で、(キートランザクションに設定した)問題のあるトランザクションを実行します。
  3. パフォーマンスの低下の原因を特定するため、トランザクションの概要とトレースディテールを確認します。

この問題を診断するために、New Relic をどのように使っていくかをここから紹介していきます。

ステップ1: トランザクションを実行する。 個々のブログ記事の読み込みのみ毎回遅いサイトを持つクライアントがいる場合を例に説明していきます。他のページはすべて読み込みは問題ないが、個々の投稿ページのみ読み込みに数秒かかります。

最初のステップは、問題を再現することです。この場合、実際にサイトのブログポストにアクセスし、New Relicが必要なデータを収集するようにします。注: サイトが Kinsta プラットフォームに組み込まれているページキャッシュの使している場合、(事前に)各ページ読み込みのキャッシュをクリアしてください。そうしないと、アクセス時に、WordPress のページを生成せずに、キャッシュからページをロードしてしまいます。

ステップ2: 遅いトランザクションを探します。 遅いトランザクションを数回複製したら、New Relic UI にアクセスし、Transactions タブを選択します。New Relic ダッシュボードの右下の部分に遅いトランザクションのリストが表示されるまでスクロールダウンします。

詳細を確認するために対象のトランザクションをクリックします。

ステップ3: トランザクションの概要とトレースの詳細を確認する。 トランザクションを選択すると、トランザクションの要約(Summary)が表示されます。

Summary では、トランザクションで処理時間を費やしたコンポーネントのスナップショットの概要を見ることができます。この例のトランザクションの場合は、外部リソースである www.googleapis.com への呼び出しは、このトランザクションが完了するまでに掛かった 5350 ミリ秒の内の 5,000 ミリ秒掛かっていることが分かります。

これは有用な情報ですが、Trace details タブを見ると、何が起こっているかの正確な情報を知ることができます。

Trace details タブは、ページを生成するために PHP が実行した機能、データベースクエリ、外部呼出しを示す階層的なステップバイステップのフローを表示します。

この例のトランザクションの場合では、トレース詳細は、Google アナリティクスの URL への呼び出しが、プロセスを占有しているものであることを明らかにしています。このリクエストから逆算すると、それは gapp_get_post_pageviews という名前の PHP 関数によってこの処理は開始されていることがわかります。このトランザクションへの迅速な Google 検索処理は、Google Analytics Post Pageviews プラグインの一部であることが明らかになりました。このプラグインは、サイトにインストールされ、スティッキーヘッダーバーに表示カウンターを追加するために使われています。

そして、問題のサイト上のブログの記事の遅い読み込みに関連する主要成分であるスティッキーヘッダーバーにある表示カウンターだけを分離することができました。今や、このサイトの所有者は、個々のブログ記事の読み込みが遅い場合に、それを解決するために気にすべきコンポーネントを正確に知っています。

全体的な遅さの修正

我々の顧客に共通したよくあるトラブルシューティングの内、2番目の課題は、サイト全体の読み込みが遅いという不満を顧客が持っていることです。すべてのトランザクションのロードに時間が掛かっている場合、次の3つのうちの1つは、おそらく起こっています。

  1. サイトのサーバリソースが枯渇している
  2. プラグインやアクティブなテーマが問題を引き起こしている
  3. サイトのデータベースは、クエリの速度に追いつくために苦労している

Kinsta では、サーバリソースの問題はまれです。必要に応じて CPU と RAM を割り当て、サイトがそれらを必要なときに利用できるサーバリソースが十分にあることを確認するためにマシン全体の負荷を管理しています。サイトは、CPU や RAM が枯渇している場合は、これは New Relic は単一のリソース上を問題と指し示さないような全体的に遅いとう状況をを引き起こすことがあります。サイト全体が遅いと感じ、New Relic もサイトの全パーツが遅いことを示している場合は、サーバーの負荷を確認し、サーバリソースの不足かどうかを判断してください。

サイトが大量のサーバリソースを消費している場合には、次に、WordPress Plugins and themes タブ、External services タブ、Databases タブを使って、全体の遅さの問題を診断していきます。

ここでは、サイト全体が遅い場合に、これらの各タブを使って問題を診断していきます。

プラグインが原因によって全体が遅くなっている場合: プラグインがサイト全体を遅くしている原因である場合、症状はプラグインが実行している処理に基づいて変化するでしょう。しかし、多くの場合、遅いプラグインは WordPress サイトのすべてのページに影響を与えているように見えます。下の画像にあるサイトのデータの場合、全体の遅さは、サイトのすべてのフロントエンドページで見られました。これは、New Relic からサイト上でのプラグインのパフォーマンスについてわかることです。

すぐに adinjector プラグインは、次に遅いプラグインの15倍の処理時間を消費していることに気付くでしょう。

このようなデータを見ると、非効率なコードや何か非効率な部分があるプラグインであると判断しすぐに無効にしたくなるかもしれません。これは合っている場合もありますが、そうでない場合もあります。プラグインの設定ミス、遅いデータベース、応答が遅い外部リソースを使っているなど、プラグインの処理が遅くなる原因はいくつかあります。

よって、遅い反応のプラ​​グインを見たときは、もっと情報を集めるために、New Relic の他の画面を確認することをお勧めします。プラグインを無効にすることが、唯一のベストな方法であると決定を下す前に、トランザクション、データベース、外部リソースをチェックすべきです。

外部サービスが原因でサイト全体が遅くなっている場合: サイトはページビューの生成に、外部サービスへの呼び出しが必要であり、そのサービスが応答を停止したり、応答に時間がかかる場合、WordPress のサイト全体の読み込みが停止することさえありえます。

上記の画像は、遅いプラグインのスクリーンショットをとったサイトと同じサイトからの画像です。見てわかるように、1つの外部サービスが、外部のサービスを消費時間の大部分を占めています。

このケースでは、結論に飛びつく前に、情報を組み合わせて表示する必要性を示しています。この場合、呼び出されているサービスは、前のステップで特定できたプラグインの開発者へです。

この情報は、状況にいくつかの意味を追加します。それは、問題がプラグインのコードではないということです。むしろ、プラグインは、開発者のサイトに対して、多くの呼出しを行っており、それが処理時間の多くを占めているように見えます。

さらに一歩進めて、このサイトの遅いトランザクションを見れば、この外部の呼び出しは、問題のプラグインのライセンスのステータスをチェックしていることがわかります。そして、それは、この特定のプラグインのライセンスの有効期限が切れていることを示しています。いずれにせよ、我々は今 adinjector プラグインは、パフォーマンスの低下を引き起こしている原因であり、パフォーマンス低下は、プラグインのライセンスのステータスを確認するために、繰り返し、開発者のサイトを呼び出していることを、このサイトの所有者に助言できます。

データベースが原因で全体が遅くなっている場合: データベースの最適化が不十分である場合、WordPress のサイト全体が遅くなることがあります。私達が勧める最適化の1つは、MyISAM から InnoDB にデータベースを変更することです。New Relic では、このデータベース関連のパフォーマンスの遅さは、次の2つの場所に表示されることが多いです。

  • Overview で、大量の MySQL アクティビティが表示されることがあります。
  • Databases タブには、多くの時間を消費している1つ以上のデータベーステーブルが表示されます。

Overview 画面を見ることから始めましょう。パフォーマンスに問題のあるデータベースを持つサイトは、次のようになっています。

問題の原因となっているデータベーステーブルやクエリに関する情報を確認するには、Databases タブにアクセスします。

Databases タブには、最も時間を消費している、テーブルとクエリのタイプを見ることができます。リスト内の任意のエントリを選択すると、サンプルクエリを含む、より詳細な情報を見ることができます。

この場合、データは wp_options テーブルの自動ロードされたデータを指しています。案の定、wp_options テーブルを軽く分析すれば、250 メガバイト近くのデータが、このテーブルからの自動ロードで利用していることがわかります。まずは、このサイトのデータベースのメンテナンスと最適化を行うことが必要です。(Kinsta が行った wp_options テーブルの最適化と自動ロードデータの最適化については、Kinta の記事をご覧ください)

今すぐデバッグを開始しよう!

New Relic を使うと、WordPress サイト上のパフォーマンスのボトルネックを特定できるようになります。New Relic を最大限に活用するには、WorPress を知ることが重要です。各タブにレポートされている情報が何かを理解し、すべての情報が相互にどのように関係しているかを確認してください。New Relic には、WordPress の専用の機能に関するドキュメントがあります。そちらも是非、ご覧ください。

Qiita で New Relic Advent Calendar 2017 いろいろ書きました。特に、New Relic APM の入門的な連載を書きましたので、是非、ご覧ください。

New Relic 公式の日本 New Relic ユーザー会を立ち上げました。ワークショップの情報など日本のお客様向けに情報を発信していきますので、是非、参加ください。

過去記事

2018/09/13

翻訳: FutureStack18: New Relic 開発者向けプログラム-オープン化、シンプル化、活発化への道

今年も始まりました。New Relic の年次カンファレンス FutureStack 18。
この記事では、Elixir 用の New Relic APM エージェントの発表とデベロッパープログラムの発表がされています。

続きを読む

2018/08/27

翻訳: New Relic APM 新機能: 分散トレーシング

New Relic APM にDistributed Tracing (分散トレーシング)機能が追加されました。メニュー単位で機能が追加されたのはだいぶなかったのではないかと思います。マイクロサービスにおけるサービスをまたがったデータの流れを可視化できる機能のようです。是非、チェックしてみてください。

続きを読む

2018/05/18

SREcon18 と Rails デベロッパー向けアンケート結果の紹介

SRECon America カンファレンスにおけるアンケートの記事と Rails デベロッパーに対するアンケートの記事という2つの異なったレイヤーのアンケートに関する記事を見つけたので、ざっくり紹介します。違った視点での傾向が見れてなかなか面白いです。

続きを読む

2018/05/11

AWS Summit Tokyo を中心に直近の New Relic 関連イベントのご紹介

5/30 から始まる AWS summit Tokyo に参加するということで、海外から New Relic スタッフが来日し、イベント等を行います。是非、この機会に New Relic に興味のある人は参加してみてはいかがでしょうか。(基本、日本人スタッフいるので、日本語でも大丈夫なはず)

続きを読む

2018/03/17

翻訳: New Relic Browser JavaScript Error Analytics ベータ版 – エラーの早期発見、修正に役立つ

New Relic Browser の JS エラー機能が新しくなるようです (現在ベータ版)。APM で採用されているエラープロファイルが JS エラーにも対応したようです。これによって、エラーが起きている傾向が分析できるようになり、今後の JS のエラーが起きる前に対策が取りやすくなります。既存の PRO ユーザーはベータ版が使えるようなので、是非、使ってみてください。

続きを読む

 もっと見る