APM は、リクエストが生産システムに入った後、アプリケーションに到達するまでの時間を追跡します。リクエストのライフサイクルのこの部分を リクエストキューイング と呼んでいます。お客様のプロダクションシステムの仕様に応じて、この時間の測定には、リクエストが入る実際のキューが含まれている場合もあれば、含まれていない場合もあります。また、他の機能（ロードバランシングや内部ネットワークのレイテンシーなど）を表している場合もあります。
リクエストキューイングを使用してスケーリングの問題を特定
リクエストキューにかかった時間を追跡することは、ある種のパフォーマンスやスケーリングの問題を特定するのに役立ちます（例）。
- フロントエンド Web サーバーが、アプリケーション ワーカーが利用可能になるまでの待機に時間を費やしている場合
- デプロイや再起動後、アプリケーション・ワーカーのウォームアップに余分な時間がかかる場合
リクエストキューイングを報告するためには、New Relic エージェント と サーバー を設定する必要があります。この情報は、選択したアプリケーションの Requests time Web トランザクションのチャート（APM の Applications リストからアプリを選択）や、ユーザーインターフェイスの他の場所に表示されます。チャートの凡例は、どの色がリクエストキューイングを表しているかを示しています。
Apdexの計算
リクエストキューイングとは、ブラウザがコンテンツをリクエストしてから、コンテンツを受信するまでの時間のことです。Apdexのスコアにはこれらの計算が反映されるため、リクエストキューの時間を個別に報告するかどうかを選択することができます。詳しくは、 Agent configuration をご覧ください。
クロック・スキュー
フロントエンド Web サーバー (Nginx など) とアプリケーションが同じ物理サーバー上に存在しない場合、報告されたリクエスト キューイングはクロック スキューの影響を受ける可能性があります。NTP は、 サーバー クロックの同期を維持する優れた方法を提供します。ただし、それらは依然として互いに対してドリフトします。New Relic エージェントはフロントエンド サーバーによって設定されたタイムスタンプに依存するため、そのサーバーのクロックがアプリ サーバーのクロックと厳密に同期されていない場合、リクエスト キューイングを過大または過小に報告する可能性があります。
これは、この機能の大きな問題のように思われるかもしれませんが、クロックスキューは、報告されたリクエストキューに突然のスパイクが発生することはほとんどありません。突然のスパイクは、一般的にアプリケーションが再起動されたときや、リクエストで過負荷になったときに発生します。私たちの経験では、リクエストキューのレポートは実際のパフォーマンス問題を特定するのに役立ちますが、このデータを解釈する際には必ずクロックスキューを考慮してください。