KinstaのAPMツール
弊社のAPMツールを使用すると、WordPressサイトのPHPパフォーマンスのボトルネックを容易に特定することができます。New Relicなどのようなサードパーティ監視ツールは不要です。
すべてのプランに無料で付帯しており、WordPressサイトのワーカープロセス、MySQLデータベースクエリ、外部HTTP呼び出しなどに関する情報をタイムスタンプ付きで確認できます。サイトのトラブルシューティングに有用です。
読み込みの遅い特定のページを調べ、問題の根本原因を特定することができます。Kinsta APMを活用し、パフォーマンスの問題を解決する方法については以下をご覧ください。
なお、このAPMツールは、WordPressサイトの監視に特化して設計されているため、他のCMSやフレームワークで稼働するサイトを監視すると、正確な情報が得られない可能性があります。このため、WordPressサイトのみで使用することをお勧めしています。
APMツールの用語
Kinsta APMの使用方法をご紹介する前に、主要な用語の定義をご説明します。
APM
「アプリケーションパフォーマンス監視」の略で、アプリケーションのパフォーマンスデータと傾向を把握するためのツールです。Kinsta APMを使って、WordPressサイトのパフォーマンスに関する実用的なデータを収集できます。
リクエスト
Kinsta APMの文脈では、レンダリングするためにPHPの実行を要するWordPressサイトへのリクエストを指します。リクエストURLには、様々なクエリ文字列パラメータを使用でき、これが対応するトランザクションをトリガーします。
例えば、yourdomain.com/wp-cron.php?arg=1&arg2=2へのリクエストは、/wp-cron.phpのトランザクションをトリガーします。
トランザクション
WordPressサイトにリクエストを送信するバックエンドの処理を指します。例えば、/wp-login.php へのリクエストのトランザクションには、WordPressサイトのログインページを生成する複数のワーカープロセスが含まれます。
スパン
トランザクション内の単一のプロセスを指します。1つのトランザクションは、階層的に並んだ数百のスパンで構成されることがあります。
例えば、WooCommerceで顧客のアカウントページを生成するトランザクションの中身は、複数のデータベースクエリスパンである可能性があります。
トランザクションの例
特定のトランザクションエンドポイント（/single.php、/wp-cron.phpなど）への多くのリクエストの内の一つのリクエストを指します。APMでは、3つの例からご選択いただけます。
例えば、Kinsta APMが数十の/wp-cron.phpトランザクションを記録することがあります。その際には、最も遅いトランザクションが選択され、トランザクションの例となります。
トランザクショントレース
トランザクションの例で発生した、すべてのプロセスをタイムラインとして表示したものです。APMツールのトランザクショントレースは、スパンの期間とタイムスタンプを含むかたちで一覧表示されます。
スタックトレース
スタックトレースは、単一のスパンの内訳を詳しく説明したものです。細かな分析やデバッグの際に効果を発揮します。特定のPHPファイルやコードなど、実行されたPHPに関する非常に詳しい情報を確認することができます。
KinstaのAPMツールを利用する
APMツールは、デフォルトでは無効になっています。APMツールはサーバーリソースを消費するため、WordPressサイトのパフォーマンスの問題をトラブルシューティングする場合にのみ有効化してください。
Kinsta APMを有効化するには、MyKinstaにログイン後、該当のサイトを選択し、「APM」に移動します。「APMを有効化」をクリックしてください。
次に、監視する期間を決定します。2時間、4時間、12時間、24時間から選択可能です。Kinsta APMはサイトのパフォーマンスを低下させる恐れがあるため、長時間有効にしないようにご注意ください。期間を選択したら「監視の有効化」をクリックし、APMツールを起動します。
データの収集を開始するまで、5～10分ほどかかることがあります。しばらくすると、「APM」画面にデータが表示されます。
APMは、監視期間を過ぎると自動で停止します。設定した期間よりも早く無効にするには、3つの点をクリックし、ドロップダウンメニューから「無効化」をクリックしてください。
監視時間枠を変更する
デフォルトでは過去60分間の監視データが表示されますが、この時間枠は変更することができ、以下から選択可能です。
- 30分間
- 60分間
- 2時間
- 4時間
- 12時間
- 24時間
変更するには、「APM」画面右上にある時間枠のドロップダウンメニューをクリックし、表示される「時間枠の選択」画面で任意の期間を選択し、「時間枠を変更する」をクリックして、変更を保存してください。
監視データを更新する
APMツールには、設定された時間枠（過去30分、過去60分など）のパフォーマンス監視データが表示されます。混乱が起きないよう、このデータが自動で更新されることはありません。選択した時間枠の最新データを表示するには、画面上部の時間枠ドロップダウンメニューの横にある円形のやり直しアイコン（「データを更新」）をクリックします。
監視データを読む
データの記録はAPMツールが有効になるまで開始されないため、サイトのパフォーマンスデータが収集されるまでしばらく時間がかかります。5〜10分程度時間を置いた上で、監視データの確認を行うことをお勧めします。
監視データは、「トランザクション」「WordPress」「データベース」「外部」の4つのタブに分かれています。
すべてのタブで表示される共通の項目は以下の通りです。
- 合計時間（％）：選択した時間枠内にトランザクションエンドポイントによって使用された時間の割合。期間のパーセンテージは「期間（時間）」の値をベースにして計算されるため、個々のトランザクションの例の期間を表すものではありません。
- 合計時間：選択した時間枠内にトランザクションエンドポイントによって使用された合計時間。期間は、個々のトランザクションの例の期間を表すものではなく、エンドポイントへのすべてのリクエストの期間の合計を示すことにご注意ください。
- 最大時間： 選択した時間枠内の最も遅いトランザクションの例の期間。
- 平均時間：選択した時間枠内のすべてのトランザクションの例の期間の平均。
- 1分あたり：選択した時間枠内でトランザクションが1分あたりに実行された回数の平均。
以下、それぞれのタブで確認できるデータについてご紹介します。
トランザクションの例
「トランザクション」タブでは、選択した時間枠のトランザクションの例が最大3つ表示されます。
- 最も遅い例：最も遅いトランザクションの例
- 95パーセンタイル：95パーセンタイルのトランザクション（95%がこのトランザクションの例よりも高速）
- 50パーセンタイル：50パーセンタイルのトランザクション（50%がこのトランザクションの例よりも高速）。中央値とも呼ばれ、このトランザクションより速いトランザクションの数と、このトランザクションより遅いトランザクションの数がまったく同じであるため、トランザクションの一般的な長さと考えることができます。
1〜3つの例が表示され、最も遅い例と95パーセンタイルが同じトランザクションになることもあります。
「トランザクションの例」画面では、タイムスタンプ、トランザクションのエンドポイント、リクエストURL、期間など、各トランザクションの例に付随する情報も確認できます。
個々のトランザクションの例
モーダル内にある個々のトランザクションの例をクリックすると、それに関する情報を掲載したページが表示されます。この「トランザクションの例」の画面には、例についてのタイムスタンプ、トランザクションのエンドポイント、URL、期間、HTTPステータスコード、およびトランザクショントレースのタイムラインが表示されます。
- タイムスタンプ：トランザクションの例の日付と時刻
- トランザクション：トランザクションの例のPHPエンドポイント（/wp-cron.php、/single.phpなど）
- URL：トランザクションの例の具体的なURL
- 期間：トランザクションの例の期間（ミリ秒単位）
- 結果：トランザクションのHTTPステータスコード。「HTTP 200」が表示されると、トランザクションが正常に実行できたことを意味します。「HTTP 503」が表示された場合は、トランザクションがタイムアウトした可能性があります。
各トランザクションの例には、パーマリンク（一意のURL）があります。これによって、チームや開発者、または弊社カスタマーサポートへの特定のトランザクションの例を共有することが容易になります。注）チームメンバーや開発者などがトランザクションの例を確認するには、MyKinsta上でアクセス権限が必要になります。
トランザクショントレースのタイムライン
Kinsta APMでは、基本的なトランザクション情報だけでなく、より詳細なトランザクショントレースのタイムラインも確認することができます。トランザクショントレースのタイムラインでは、スパン（ワーカープロセス、MySQLデータベースクエリ、特定のトランザクションの例の外部呼び出し）が表示されます。
列にある名前をクリックすることで、スパンを「期間（時間）」または「期間（％）」で昇順または降順に並べ替えることができ、最も長い間実行されたトランザクションの特定に便利です。
各スパンの期間と相対タイムスタンプも表示されるため、リクエストの中でも最も遅く、最も問題のある部分を即座に見つけることができます。
トランザクションの例の合計期間については、以下の情報が表示されます。
- 時間が5％を超えるスパンはオレンジ色
- 時間が25%を超えるスパンは赤色
上記のデータは、該当する例で考えた時のスパンの相対的な期間です。したがって、赤色のデータが表示された場合、それは該当する例と比較したデータであることをご了承ください（サイトやウェブアプリ全体が必ずしも遅くなっているとは限りません）。
なお、MySQLおよびRedisのクエリの場合、0.001ミリ秒未満のスパンは含まれません。データベースに関連しないスパンについては、しきい値を1ミリ秒に設定しています。多数の高速である要素を記録すると、その処理自体がパフォーマンスに悪影響を与える可能性があり、加えてあまり有用なデータが得られないため、短いスパンを意図的に除外しています。
この詳細なトレースタイムラインは、ボトルネックを正確に突き止めることができるため、パフォーマンスの問題をトラブルシューティングする際に非常に有効です。
例えば、/wp-admin/admin-ajax.phpを要求したときに、SNS APIの呼び出しが原因で遅延が発生していると推測できたとします。これをもとに、SNSプラグインを無効にしてサイトのテストを続け、速度に違いが出るか確認することができます。
同様に、キャッシュプリロードプラグインが原因で/wp-cron.phpへの同じHTTPリクエストが何回も発生している場合には、その機能を無効にすることができます。
スパンの詳細
トランザクショントレースのタイムラインでスパンをクリックすると、スタックトレース全体と関連情報を確認できます。
例えば、MySQLクエリスパンをクリックすると、スタックトレースだけでなく、実行されたデータベースクエリも表示されます。スパンの中身を調べることにより、WordPressサイトでのPHPトランザクションについての詳しいデータを確認することができます。
APMツールでのデータの読み方や使用事例についてはこちらをご覧ください。
監視結果
「APM」画面の各タブでは、「トランザクション」「WordPress」「データベース」「外部」リクエストの特定データを確認することができます。
トランザクション
このタブでは、合計トランザクション時間と最も遅いトランザクションに関する情報が表示されます。
合計トランザクション時間
「合計トランザクション時間」では、選択した時間枠のトランザクション時間を視覚的に確認することができます。PHP、MySQL、Redis、および外部が色別で表示されます。また、選択した時間枠の平均トランザクション時間がセクション右上に表示されます。
最も遅いトランザクション
「合計トランザクション時間」の下にある「最も遅いトランザクション」には、最も遅いPHPトランザクション上位10件が表示されます。上でご紹介したすべてのタブに共通する項目に加え、「トランザクション」列には、最も時間のかかったリクエストのトランザクションエンドポイントが表示されます（/wp-cron.php、/wp-jsonなど）。
各トランザクションのエンドポイントをクリックして、トランザクションの例を表示すると、個々のトランザクションの例、トレースタイムライン、スパンの詳細、スタックトレースに移動できます。
WordPress
「WordPress」タブでは、WordPressのプラグインとフックに特化したデータが表示されます。
最も遅いWordPressプラグイン
1番左の列にプラグインのスラッグ（フォルダ/ディレクトリ名）、そして上でご紹介した共通項目が表示されます。各プラグインのスラッグをクリックすると、トランザクションの例が表示され、さらに個々のトランザクションの例、トレースタイムライン、スパンの詳細、スタックトレースを確認できます。
最も遅いWordPressフック
「最も遅いWordPressプラグイン」の下には、「最も遅いWordPressフック」の一覧が表示されます。WordPressフックとは、テーマやプラグインに含まれる関数で、コードの処理中の特定の場所でWordPressに変更を加えることができます。
フックは、アクションまたはフィルタのどちらかであり、このセクションのフックには、タイプ（アクションまたはフィルタ）の前に関数名が表示されます。フックをクリックするとトランザクションの例が表示され、さらに個々のトランザクションの例、トレースタイムライン、スパンの詳細、スタックトレースを確認できます。
データベース
「データベース」タブには、最も遅いデータベースクエリと最も遅いRedisキャッシュ（Redisが有効な場合）のデータが表示されます。
最も遅いデータベースクエリ
最も遅いデータベースクエリの上位10件が表示されます。クエリをクリックすると、トランザクションの例が表示され、さらに個々のトランザクションの例、トレースタイムライン、スパンの詳細、スタックトレースを確認できます。
最も遅いRedisキャッシュ
Redisアドオンをインストールしている場合は、Redisキャッシュに関するデータが表示されます。Redisアドオンを使用していない場合は、何も表示されません。キャッシュ項目をクリックするとトランザクションの例が表示され、さらに個々のトランザクションの例、トレースタイムライン、スパンの詳細、スタックトレースを確認できます。
外部リクエスト
サイトが行う外部リクエストのデータは、「外部」タブで確認可能です。外部リクエストとは、サイトが他のサイトやサーバーに送信するHTTPリクエストです。この呼び出しは、データの取得や送信、APIとの通信のためにプラグインやテーマによって実行されるのが一般的です。
1番左側の列にはURLが表示され、リクエストに使用されたHTTPメソッド（GET、POST、PUTなど）が続きます。URLをクリックすると、トランザクションの例が表示され、さらに個々のトランザクションの例、トレースタイムライン、スパンの詳細、スタックトレースを確認できます。
パフォーマンスの問題を特定する
APMツールは、サイトのトラブルシューティングを行うのに便利なツールです。ここからは、APMを使って問題を調査および分析し、サイト上のパフォーマンス上の問題をトラブルシューティングする方法をご紹介します。
はじめに
APMツールを使って問題のトラブルシューティングを行う前に、問題の種類に関係なく必要ないくつかのステップがあります。
- 現在発生していない問題であれば、再現できることを確認する。問題が発生するタイミングや、特定の操作（ページの編集、ECサイトのカートへの商品の追加、画像のアップロードなど）が問題の引き金になるようなパターンがないかどうかを確認しましょう。
- MyKinstaでAPMを有効化して、データの収集のために数分待ちます。APMは、それが有効になっている間のみデータを記録し、分析することができます。
- APMによりデータの収集が始まったら、問題を再現して必要な情報を記録します。
- Redisがサイトで有効になっている場合、WP RedisまたはRedis Object Cacheプラグインのいずれかを使用していることをご確認ください（ただし、両方同時に使用しないでください）。APMツールでは、その他のプラグインからRedisデータを収集し、表示することができない場合があります。
読み込みの遅いページまたはアクションを分析する
こんな例を考えてみましょう。ページの読み込みは速いのですが、単純な商品であれ、可変型の商品であれ、商品をカートに入れると、スローダウンしてしまいます。
いくつかの製品をカートに追加した後、APMの監視結果（「WordPressサイト」＞（サイト名）＞「APM」）を見てみると、/single-productトランザクションが最大5秒以上、平均2秒以上で、「最も遅いトランザクション」の上位にあることがわかります。
このトランザクションをクリックすると、「トランザクションの例」のポップアップが表示され、最も遅いトランザクション（一覧の中でも最初のもの）を選択して詳細を確認することができます。
「トランザクショントレースのタイムライン」が表示されます。ここで、トランザクションを「期間（時間）」でソートし、このトランザクションの例の中でどのプロセスが最も遅いかを確認できます。ここでは、update_card_paymentスパンがタイムライン上で最も遅いプロセスであり、5,535.61ミリ秒のトランザクションのうち5,002.21ミリ秒を占有していることがわかります。
そのスパンをクリックすると、「スパンの詳細」ポップアップが開き、そのスパンのスタックトレースが表示されます。
スパンの詳細でWordPressフックaction:woocommerce_add_to_cartがこのスパンと関連付けられていることがわかります。
この問題がどのプラグインやテーマと関連しているのかを突き止めるには、いくつかの方法があります。
コマンドラインに慣れている方は、grepコマンドで update_card_payment関数を検索し、その関数を含むプラグインやテーマのファイルを確認することができます。
または、「WordPress」タブの「合計時間」と「最大時間」が似たようなプラグインを探すこともできます。ほとんどの場合、一覧の一番上にあります。
「最も遅いWordPressプラグイン」一覧のプラグインを選択することで、一致しているかどうかを確認できます。「トランザクションの例」ポップアップのWordPressプラグインの列にプラグインが表示されていない場合は、最も遅いトランザクションを選択して、「トランザクショントレースのタイムライン」を表示します。
タイムラインを「期間」でソートし、同じ関数名（例：update_card_payment）が一覧の先頭または近くにあることを確認します。
全体的な遅延を調査する
サイトの全体的な遅さは、多くの場合、プラグインが原因であり、最初に確認しておきたい項目の1つです。プラグインが原因でサイトの速度が低下している場合、通常は「WordPress」タブ（「WordPressサイト」＞（サイト名）＞「APM」＞「WordPress」）を表示することで確認できます。以下のスクリーンショットでは、特定のプラグインの合計時間の割合が98%以上であり、最大および平均時間がかなり長い点が気になります。
このプラグインがサイト全体の遅延の原因である可能性があります。これを確認するには、プラグインを無効にしてサイトのパフォーマンスを観察し、十分なデータを収集した後にもう一度APMツールで結果を確認してみましょう。プラグインが正しく設定されているにもかかわらず、サイトが遅くなる場合には、プラグイン開発者に連絡して、問題の解決を求めることをお勧めします。
間欠的なサードパーティの問題を特定する
サイトが他の（サードパーティの）サーバーに行うHTTPリクエストは、外部リクエストと呼ばれます。プラグインやテーマは通常、スクリプトやスタイルシートの読み込み、またはAPIのためにこのリクエストを行います。
外部の問題の可能性をトラブルシューティングする場合の注意事項として、APMによる遅い外部トランザクションの記録は、サーバー側で実行されます。クライアント側のサイトにて、APMで記録されない多くの外部リクエストが行われる可能性があります。クライアント側の外部リクエストを調査するには、GTmetrixのようなサービスやブラウザに搭載された開発者ツールなどを使用する必要があります。
遅い外部リクエストを確認するには、「APM」画面の「外部」タブで「最も遅い外部リクエスト」を表示します。この例では、メディアライブラリで画像をアップロードする際に、一部のアップロードに5分以上かかるという遅さが確認されています。
まず、WordPress管理画面にログインしているだけの状態で、外部リクエストがどのようなものかを見てみます。メディアライブラリに画像をアップロードする前は、wp-cronへのPOSTリクエストが、最も遅いもので、最大時間は273.78ミリ秒、合計時間は1,957.81ミリ秒となっています。
サイズが 3MB～17MB の画像を複数アップロードすると、アップロードが完了するまでに数分かかります。外部リクエストを見てみると、smushpro.wpmudev.comへのPOSTリクエストが最も遅い外部リクエストで、最大時間は1,703.14ミリ秒、合計時間は82,710.85ミリ秒です。
そのトランザクションをクリックすると、「トランザクションの例」ポップアップが表示され、最も遅いトランザクション（一覧の最初のもの）を選択して詳細を確認することができます。
「トランザクショントレースのタイムライン」に移動し、トランザクションを「期間（時間）」 でソートして、最も遅いスパンを確認することができます。ここでは、smushpro.wpmudev.com へのいくつかのPOSTリクエストが最も遅く、POSTリクエストの合計が 7,168.58ミリ秒のトランザクションのうち6,712.64ミリ秒を占めていることがわかります。
ままた、各リクエストの所要時間が大きく異なり、最短で138.2ミリ秒、最長で1,703.14ミリ秒であることも確認できます。つまり、Smushプラグインが画像を最適化する際、それぞれの画像が外部リクエストを生成し、それが積み重なりサイトが遅くなる可能性が考えられます。
この場合、画像最適化のためのプラグインに頼るのではなく、アップロード前に画像を最適化することで、外部リクエストを大幅に減らすことができます。このような場合、利便性とサイトのパフォーマンスのどちらを重視するかを判断する必要があります。外部リクエストによって引き起こされる速度の低下を許容できるのであれば、プラグインを維持してもいいでしょう。サイトのパフォーマンスを改善したい、またはその必要がある場合は、プラグインを削除し、アップロードする前に画像を最適化するのが最善です。
APMに関するよくあるご質問
以下、Kinsta APMに関するよくあるご質問とその回答をご紹介します。
Kinsta APMを利用するにはどうすればいいですか？
弊社APMツールは、すべてのプランに追加料金なしで付帯しています。以下の手順で有効化することができます。
- MyKinstaにログインします。
- デバッグしたいサイトを選択します。
- 「APM」をクリックします。
- 「APMを有効化」ボタンをクリックします。
- 「監視の有効化」ポップアップで有効にする期間を選択します。
APMツールの使用はWordPressサイトの速度に影響しますか？
他のAPMツール同様、弊社APMのエージェントもサーバーのCPUとRAMを消費する可能性があるため、一時的にWordPressサイトの速度に影響がでる可能性があります。
このような理由から、サイトのパフォーマンスに関する問題を調べる間のみ、有効化することをお勧めします。
New Relicも引き続きサポートされますか？
New Relicの個人向けライセンスをお持ちのお客様向けに、New Relicも引き続きサポートしています。
Kinsta APMとNew Relicを同時に使用することはできますか？
原則、Kinsta APMとNew Relicの併用は推奨しておりません。同時に有効化しない限りは、必要に応じて、Kinsta APMとNew Relicを切り替えながらご利用いただくことは可能です。
他のCMSプラットフォームやフレームワークと互換性はありますか？
現時点で完全な互換性があるのは、WordPressのみとなります。
Bedrock（またはComposerを使用する他のサイト）でも動作しますか？
Bedrockでも動作しますが、WP-CLIがサイトのcomposer.jsonファイルの依存関係である場合は、弊社とWP-CLIのオートローダーが連携するよう、別途設定を行なってください。
"prepend-autoloader": falseprepend設定後、Bedrockサイトのconfig配列は、以下のようになります。
"config": {
"optimize-autoloader": true,
"preferred-install": "dist",
"prepend-autoloader": false
},APMツールの有効化後、サイトに予期せぬ動作が見られた場合はどうすればいいですか？
弊社では、あらゆるWordPressのバージョンとプラグインで広範なテストを実施していますが、プラグインのバージョンやカスタム開発環境との互換性の問題など、未知のエラーが発生する可能性もゼロではありません。
したがって、APMツールを有効化した後は、サイトが正常に動作しているかどうかを必ず再度ご確認ください。何かしらの不備が見られた場合は、すぐにAPMツールを無効化し、弊社カスタマーサポートまでご報告ください。
監視データの保存期間はどのくらいですか？
Kinsta APMのデータは14日間保持されます。24時間より古いデータを表示するには、「APM」画面右上にある時間枠のドロップダウンメニューをクリックし、「時間枠の選択」画面で「絶対」タブを選択し、過去14日以内の24時間の時間枠を選択して、「時間枠を変更する」をクリックしてください。
まとめ
Kinsta APMを使用すると、WordPressサイトのパフォーマンス面での問題に関する詳細データを取得することができます。一般的なHTTP 502エラーやタイムアウトエラーではなく、遅いリクエストの詳細などが表示されます。
すべてのプランに追加費用なしで付帯しているため、Query Monitorのようなプラグインをインストールしたり、New Relicのようなサードパーティサービスを契約したりせずに、パフォーマンスの問題をデバッグすることができます。
WordPressサイトのエラーを解決するため、開発者の手を借りている場合も、APMツールの詳細データを共有することによって、手間と費用の削減につながります。