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

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

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

New Relicはリクエストが本番システムを通り、アプリケーションに到達するまでの時間を追跡することが可能です。リクエストのライフサイクルの上記部分はリクエストキューイングと言及されます。本番インフラストラクチャの特性により、この時間はリクエストが通る実際のキューを含むか、他の機能を表現しています(ロードバランシングや内部ネットワーク遅延等)。

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

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

  • フロントエンドWebサーバーが、アプリケーションワーカーが利用できるようになるまで待っている時
  • デプロイや再起動後、アプリケーションワーカーが立ち上がるのを待つため余分な時間が費やされている時

New Relicエージェントサーバーを設定し、リクエストキューイングを報告させる必要があります。その後、選択したアプリケーションのWebトランザクション用リクエスト時間チャートおよびユーザーインターフェースのその他の場所に情報が表示されます(New Relic APMのアプリケーション一覧から、アプリを選択します)。チャートのレジェンドは、どの色がリクエストキューイングを表現しているのかを示します。


【APM > アプリケーション > (選択したアプリ) > モニタリング > 概要:】これはデプロイメント後にリクエストキューイングのスパイクがあるアプリの【リクエスト応答時間チャート】の例です。リクエストキューイングの帯は明るい緑色です。

 

Apdex計算

リクエストキューイングは、ブラウザーがコンテンツをリクエストした時から、コンテンツを受け取った時までの時間です。Apdexスコアはこの計算を反映するため、リクエストキュー時間を別々にレポートするか一緒にするかを選択することができます。詳細に関しては、《エージェント設定》をご覧ください。

 

クロックスキュー

フロントエンドWebサーバー(Nginx等)とアプリケーションが同じ物理サーバー内に存在しない場合、報告されるリクエストキューイングはクロックスキューに影響される可能性があります。《NTP》はサーバーの時計を合わせるための素晴らしい方法を提供します。しかし、それでも次第にずれていきます。New Relicエージェントはフロントエンドサーバーに設定されたタイムスタンプに依存するため、サーバーの時計がアプリサーバーの時計と近い時間にシンクロされていない場合、リクエストキューイングより多くもしくは少なく報告する可能性があります。

これはこの機能の重要な問題のように感じられるかもしれません;しかし、クロックスキューは報告されたリクエストキューイングに突然のスパイクを起こす可能性はほとんどありません。突然のスパイクは通常、アプリが再起動した時、もしくはリクエストが超過している時に発生します。New Relicはこれまでにリクエスト キュー レポーティングが実際のパフォーマンスの問題を特定するのに役立つことを発見していますが、このデータを読み込む際はクロックスキューを念頭に置いてください。

 

関連情報

追加のドキュメンテーションリソースは次のとおりです。

  • ページ読み込みタイミングプロセス(リアルユーザーモニタリングもしくはRUMとも呼ばれる、ページ読み込みタイミングに関する詳細情報)
  • リクエスト キュー レポーティングを設定する(New Relicエージェントの設定ガイド)
  • リクエスト キュー サーバー設定例(Apache、Nginx、Varnish、F5ロードバランサー等のリクエストキューHTTPヘッダを設定します)

New Relic オンラインテクニカルコミュニティーでの New Relic APMに関するディスカッションにぜひご参加ください ! テクニカルコミュニティーはNew Relicツールセットについて議論し、トラブルシューティングを行うための公開プラットフォームです。

PROプランのすべての機能を
14日間無料でお試し

新規無料登録いただくとPROプランのすべての機能を
14日間無料でお試しいただけます。
クレジットカードなど決済情報の登録は不要です。

各プランの詳細はこちらからご確認ください。