• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

リクエストのキューイングとフロントエンド時間の追跡

APM は、リクエストが本番システムに入ってからアプリケーションに到達するまでの時間を追跡します。 リクエストのライフサイクルのこの部分をrequest queuingと呼びます。 実稼働システムの詳細に応じて、この時間の測定には、リクエストが入る実際のキューが含まれる場合と含まれない場合があります。 また、他の機能 (負荷分散や内部ネットワーク レイテンシなど) を表す場合もあります。

リクエストキューイングを使用してスケーリングの問題を特定

リクエストキューにかかった時間を追跡することは、ある種のパフォーマンスやスケーリングの問題を特定するのに役立ちます(例)。

  • フロントエンド Web サーバーが、アプリケーション ワーカーが利用可能になるまでの待機に時間を費やしている場合
  • デプロイや再起動後、アプリケーション・ワーカーのウォームアップに余分な時間がかかる場合

リクエストのキューイングを報告するには、New Relicエージェントサーバーを構成する必要があります。 その後、選択したアプリケーションのウェブトランザクションの Requests time チャート ( APMの Applications リストからアプリを選択) と、ユーザー インターフェースの他の場所に情報が表示されます。 グラフの凡例は、どの色がリクエストのキューイングを表すかを示します。

Apdexの計算

リクエストキューイングとは、ブラウザがコンテンツをリクエストしてから、コンテンツを受信するまでの時間のことです。Apdexのスコアにはこれらの計算が反映されるため、リクエストキューの時間を個別に報告するかどうかを選択することができます。詳しくは、 Agent configuration をご覧ください。

クロック・スキュー

フロントエンド Web サーバー (Nginx など) とアプリケーションが同じ物理サーバー上に存在しない場合、報告されたリクエスト キューイングはクロック スキューの影響を受ける可能性があります。NTP は、 サーバー クロックの同期を維持する優れた方法を提供します。ただし、それらは依然として互いに対してドリフトします。New Relic エージェントはフロントエンド サーバーによって設定されたタイムスタンプに依存するため、そのサーバーのクロックがアプリ サーバーのクロックと厳密に同期されていない場合、リクエスト キューイングを過大または過小に報告する可能性があります。

これは、この機能の大きな問題のように思われるかもしれませんが、クロックスキューは、報告されたリクエストキューに突然のスパイクが発生することはほとんどありません。突然のスパイクは、一般的にアプリケーションが再起動されたときや、リクエストで過負荷になったときに発生します。私たちの経験では、リクエストキューのレポートは実際のパフォーマンス問題を特定するのに役立ちますが、このデータを解釈する際には必ずクロックスキューを考慮してください。

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.