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

New Relic を使うと、リクエストが本番インフラに入った後とアプリケーションに到達する前の時間を追跡できます。リクエストのライフサイクルのこの部分はリクエストキューイングと呼ばれます。本番インフラの環境に応じて、この時間は、入力要求し、実際のキューを含むことができるか、(例えば、負荷分散や内部ネットワークの待ち時間など)他の機能を表すことができる。

パフォーマンスとスケーリングの問題

リクエストキューイングに費やされた時間を追跡すると、パフォーマンスとスケーリングの問題の特定の種類を同定するのに役に立ちます。例えば:

  • アプリケーションのワーカーが利用可能になるまでのフロントエンドの Web サーバーの待ち時間
  • デプロイまたは再起動後に、アプリケーションワーカーをウォームアップするのにかかる時間

リクエストキューイングをレポート対象とするには、New Relic エージェントサーバーの設定変更が必要です。設定後、情報は、Web トランザクションについて(New Relic APM の Applications リストから)選択したアプリケーションの Requests response time(リクエストの応答時間)チャートとUIの他の場所に表示されます。グラフの凡例は、リクエストキューイングを表す色を示している。

screen-request-queue.png
APM > Applications > (選択したアプリ) > Monitoring > Overview: デプロイ後にリクエストキューイングがスパイクした際のアプリのリクエストの応答時間のチャートの例です。リクエストキューイングのバンドは明るい緑色です。

Apdex の計算

リクエストキューイングは、ブラウザがコンテンツを受信時にコンテンツを要求したときからの時間です。Apdex スコアはこれらの計算を反映するので、リクエストの待ち時間を個別にレポートするかどうかを選択できます。詳しくは エージェントの設定 をご覧ください。

クロックスキュー

(Nginxのような)フロントエンドの Web サーバーとアプリケーションが同じ物理サーバー上に存在しない場合、レポートされるリクエストキューイングが、クロックスキューの影響を受けることがあります。NTP は同期してサーバーの時刻を維持します。しかしながら、依然として時刻は相対的にずれる可能性があります。New Relic エージェントは、フロントエンドサーバーに設定されたタイムスタンプに依存しています。よって、そのサーバー上のクロックがアプリケーションサーバー上のクロックと密接に同期していない場合は、リクエストキューイングを過大もしくは過小に報告するかもしれません。

これは機能の大きな問題に見えるかもしれません。しかしながら、クロックスキューが原因でリクエストキューのレポートが突然スパイクすることはほぼありません。アプリを再起動したり、リクエストが過負荷になると、通常、突然スパイクが発生します。New Relic の経験として、リクエストキューのレポートは、現実のパフォーマンス問題を特定するのに有効です。しかし、このデータを解釈する際にクロックスキューを考慮したほうがよいです。

関連情報

関連情報は次のとおりです。