Kinsta APMは、ウェブサイトのトラブルシューティングを行うのに便利なツールです。このページでは、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 msのトランザクションのうち5,002.21 msを占有していることが分かります。
そのスパンをクリックすると、「スパンの詳細」ポップアップが開き、そのスパンのスタックトレースが表示されます。
スパンの詳細で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のようなサービスやブラウザに搭載された開発者ツールなどを使用する必要があります。
遅い外部リクエストを確認するには、「モニタリング結果］の「外部」タブで「最も遅い外部リクエスト」を表示します。この例では、メディアライブラリで画像をアップロードする際に、一部のアップロードに5分以上かかるという遅さが確認されています。
まず、WordPress管理画面にログインしているだけの状態で、外部リクエストがどのようなものかを見てみます。メディアライブラリに画像をアップロードする前は、wp-cronへのPOSTリクエストが、最も遅いもので、最大時間は273.78ms、合計時間は1,957.81msとなっています。
サイズが 3MB～17MB の画像を複数アップロードすると、アップロードが完了するまでに数分かかります。外部リクエストを見てみると、smushpro.wpmudev.com への POST リクエストが最も遅い外部リクエストで、最大時間は1,703.14 ms、合計時間は82,710.85 ms です。
そのトランザクションをクリックすると、「トランザクションの例」ポップアップが表示され、最も遅いトランザクション（一覧の最初のもの）を選択して詳細を確認することができます。
「トランザクショントレースのタイムライン」に移動し、トランザクションを「期間 (時間)」 でソートして、最も遅いスパンを確認することができます。ここでは、smushpro.wpmudev.com へのいくつかのPOST リクエストが最も遅く、POST リクエストの合計が 7,168.58 msのトランザクションのうち6,712.64 msを占めていることがわかります。
また、各リクエストの所要時間が大きく異なり、最短で138.2 ms、最長で1,703.14 msであることも確認できます。つまり、Smush プラグインが画像を最適化する際に、それぞれの画像が外部リクエストを生成し、それが積み重なりサイトが遅くなる可能性が考えられます。
この場合、画像最適化のためのプラグインに頼るのではなく、アップロード前に画像を最適化することで、外部リクエストを大幅に減らすことができます。このような場合、利便性とサイトのパフォーマンスのどちらを重視するかを判断する必要があります。外部リクエストによって引き起こされる速度の低下を許容できるのであれば、プラグインを維持してもいいでしょう。サイトのパフォーマンスを向上させたい、あるいはその必要がある場合は、プラグインを削除し、アップロードする前に画像を最適化することが最良の選択肢です。
まとめ
今回ご紹介した例のように、APMツールを使用して、サイトのパフォーマンス上の問題をデバッグすることができます。それぞれの状況やサイトは異なりますが、ここで紹介した一般的なトラブルシューティングの方法を、お客様や開発者によるサイトパフォーマンスの問題追跡にお役立てください。