• ログイン今すぐ開始

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

リクエストのキューイングとフロントエンドタイムのトラッキング

APM は、リクエストが生産システムに入った後、アプリケーションに到達するまでの時間を追跡します。リクエストのライフサイクルのこの部分を リクエストキューイング と呼んでいます。お客様のプロダクションシステムの仕様に応じて、この時間の測定には、リクエストが入る実際のキューが含まれている場合もあれば、含まれていない場合もあります。また、他の機能(ロードバランシングや内部ネットワークのレイテンシーなど)を表している場合もあります。

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

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

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

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

Apdexの計算

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

クロック・スキュー

フロントエンドのウェブサーバー(Nginxなど)とアプリケーションが同じ物理サーバー上に存在しない場合、報告されたリクエストキューがクロックスキューの影響を受けることがあります。 NTP は、サーバーのクロックを同期させる優れた方法です。しかし、それでも互いの時計は相対的にずれてしまいます。New Relic エージェントは、フロントエンドサーバーによって設定されたタイムスタンプに依存しているため、フロントエンドサーバーの時計がアプリサーバーの時計と密接に同期していない場合、リクエストキューイングを過不足なく報告する可能性があります。

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

Copyright © 2022 New Relic Inc.

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