Apdexは、ウェブアプリケーションやサービスのレスポンスタイムについて、ユーザー満足度を計測するための業界標準です。これは、平均レスポンスタイムなどの歪曲されやすい従来のメトリクスの代わりになる不満の割合やApdexスコアなどのメトリクスを介して、アプリケーションのユーザー満足度を確認するための簡素化されたサービスレベル契約（SLA）ソリューションです。
Apdexレベルの有用な閾値を設定すると、次のことが可能になります。
- エンドユーザーのアプリに対する全体的な満足度を一目で確認できます。
- 適切な量のトレースを取得して、トラブルシューティングを行い、アプリのパフォーマンスを改善します。
詳細については、この短いYouTubeビデオをご覧ください（約 3分50秒）。
Apdexの使用方法
Apdexスコアは、全リクエストについて満足のいくリクエスト件数と許容可能なリクエスト件数の比率です。満足のいくリクエストはすべて1つのリクエストとしてカウントされ、許容可能なリクエストはすべて満足したリクエストの半分としてカウントされます。
Apdexスコアは0～1の値を取り、0が最悪のスコアとなります（レスポンスタイムの100%が不満だった場合）。また、1が最高のスコアとなります（レスポンスタイムの100%が満足だった場合）。
Example Apdex score:
ホストが2分間で200件のリクエストを処理する場合。Apdex閾値T = 0.5秒（500ミリ秒）とします。この値は、ユーザーが自由に選択できます。
- 170件のリクエストが500ミリ秒以内に処理されたので、「満足」と分類されます。
- 20件のリクエストは500ミリ秒～2秒の間（2000ミリ秒）で処理されたので、「許容可能」と分類されます。
- 残りの10件は適切に処理されなかったか、処理時間が2秒を超過したため、「不満」と分類されます。
結果のApdexスコアは0.9：(170 + (20/2))/200 = 0.9。
重要
Apdeスコアの計算に使用した式は、高スループットアプリ用のものです。お使いのアプリのスループットが100 RPM未満の場合、安定したスコアを判別するのに十分なデータが収集されません。これにより、Apdexアラート条件の動作が想定外になる場合があります。
Apdexカウント
Apdexは3つの応答数を追跡します。
- Satisfied: レスポンスタイムがT以下である
- Tolerating: レスポンスタイムがTを超過し、4T以下である。この例では、4 x 1.2 = 4.8秒が最大許容レスポンスタイムになります
- Frustrated: レスポンスタイムが4Tより大きいか、リクエストがサーバーサイドエラーを返す。エラー率が高い場合は、平均レスポンスタイムが許容範囲であっても、Apdexスコアが低くなることがあります
設定ファイルのapdex_f値は、アプリケーションサーバーのApdex T値の4倍です。例えば、この閾値は、トランザクショントレースで役に立ちます。詳細については、New Relicエージェントの設定ファイルドキュメントをご覧ください。
時間の計算値は、アプリのT設定に応じて変わります。以下は、T = 1.2秒の例です。
Level | Multiplier | Time (T Example = 1.2) |
|---|---|---|
満足 | T以下 | <= 1.2秒 |
許容可能 | >T、<= 4T | 1.2 ～ 4.8秒 |
不満 | > 4T | 4.8秒を超える |
Apdexレベルを定義した後は、New Relicのいずれかのリソースを使用して、望ましくない顧客体験を示す変更点を特定して、トラブルシューティングを行ってください。
以下の項目に対して、複数のApdex T値を定義することができます。
Apdexによる測定 | コメント |
|---|---|
APMアプリケーション | APMはこれらのアプリのパフォーマンスをモニターします。そのApdex設定を定義するには、APM UIを使用します。ApdexはAPM Summaryページにあります。 |
Browserアプリケーション | ブラウザは、これらのアプリのエンドユーザー体験をモニターします。Apdexを使用してユーザーをモニターする代わりに、Core Web Vitalsをお勧めします。 |
キートランザクション | モニターすることを選んだ、御社の事業にとって重要なトランザクションになります。Key transactionsページでキートランザクションのApdex設定を定義できます。 重要キートランザクションのApdex設定によって、アプリのT値が上書きされます。詳細は、「キートランザクションApdex」をご覧ください。 |
Apdexアラート
Apdexのアラート条件を設定することもできます。Apdexスコアが定義した閾値を超えると、New Relicは通知メカニズム（チャネル）にアラートを送信します。
エラーページ
500: Application Errorなどのサーバーサイドエラーを返すすべてのリクエストは返信速度に関係なくストレスになる応答です。Apdexを使用してエラーの影響を視覚化してからNew Relicの組み込みのエラー解析ツールとエラープロファイルツールを使用して、エラーを識別して解決できます。
不満の割合
dissatisfaction percentageとは、あるトランザクションが原因で、アプリケーションのユーザーが体験した不満の合計件数の割合です。
Example Apdex dissatisfaction calculation:
不満（トランザクション） + 許容可能（トランザクション）/2
不満（アプリケーション） + 許容可能（アプリケーション）/2
不満の割合を視覚化するには、最も不満の割合が高いトランザクションから順に並べ替えします。
トランザクションが常に苛立たしいほど遅くても、滅多に訪問されるアプリケーションでない場合、アプリケーション全体の不満の割合に与える影響はほとんどありません。逆に、トランザクションは高速であってもスループットが高い場合は、それがアプリケーションのトラフィックの大部分を占めるために、アプリケーションの不満の割合に大きな影響を与えることがあります。
Apdex可視化のカスタマイズ
クエリビルダーを使用して、Apdexの可視化方法をカスタマイズします。
- Apdexデータを分析して共有するダッシュボードを作成します。
- NRQLクエリでApdexデータを分析します。
Apdex設定の変更
アプリケーションごとにApdex T値を定義できます。また、キートランザクションの個々のApdex T閾値も定義できます。
Apdex測定が重要である理由の概要と、アプリケーションに適した閾値を知る方法については、この短いYouTubeビデオ（約 3分40秒）をご覧ください。