非同期およびスレッド処理アクティビティのモニタリング
さまざまな方法で非同期コールやマルチスレッド アクティビティのパフォーマンスをモニタできます。Splunk AppDynamics が何を非同期アクティビティとして認識し、アクティビティについてどのような情報を提供し、情報がコードレベルでスレッドの実行にどのように関連するかを理解することが重要です。
次のセクションでは、さまざまなスレッドおよび exit コールの実行シナリオにおいて利用可能な情報の種類について説明します。
非同期 exit コール
最も一般的なケースでは、非同期 exit コール呼び出しは、プライマリビジネストランザクションスレッド以外のスレッドにより生成されたスレッドによって行われた exit コールです。
この場合のプライマリスレッドとは、エントリポイントコールを受信するスレッドを指します。一般的なパターンは、アプリケーションの main() 関数がリクエストハンドラとして複数のスレッドを生成し、リクエストを受信して処理するというものです。例：
コントローラUIのフローマップには、この接続（非同期接続）は点線で表示されます。
Splunk AppDynamicsでは、呼び出されたコンテキストによってのみ当該コールが非同期コールであると認識されます。下図のように、 exit コールがスレッド2で生成された場合は、アプリケーション設計の全体の観点からは非同期であると考えられますが、ビジネストランザクションのコンテキストでは非同期であるとみなされません。
ビジネストランザクションがない場合、Splunk AppDynamics は非同期アクティビティをトラッキングしません。
Splunk AppDynamics では、非同期処理における Wait-for-Completion（スレッドがプライマリスレッドにレポートを返す）と Fire-and-Forget（生成されたスレッドより早く、プライマリスレッドが処理を完了する）という 2 つの一般的なパターンは区別されません。両方ともコントローラ UI では同じように表されますが、通常は実行時間によって区別されます。Wait-for-Completion トランザクションのプライマリスレッドは、いずれの子プロセスよりも長くなりますが、Fire-and-Forget のプライマリスレッドは、子プロセスよりも短い場合があります。
ロジカル非同期 exit コール
前のセクションで説明したシナリオには、（概念的に）Splunk AppDynamics モデルで非同期と考えられるバックエンドシステムへの exit コールの例外が存在します。
JMS などのメッセージキューのティアは論理的に非同期であると考えられるため、フローマップはメッセージキューへの接続も点線（非同期接続）で表示されます。したがって、以下の JMS exit コールはフローマップで非同期コールとして表示されますが、JDBC コールは非同期コールとして表示されません。
ティアにおける時間
exit コールは、マルチスレッドアプリケーションのパフォーマンスを理解する上での考慮事項の一つです。もう一つの考慮事項は、リクエストの処理にかかる実際の時間です。
たとえば、次の処理シナリオについて考えてみましょう。これは単一のティアであるとします。リクエスト処理において、エントリポイントのスレッドが複数の子スレッドを生成し、その子スレッドはプライマリスレッドにレポートを返して応答をまとめます。
トランザクションの場合、応答時間のメトリックは、リクエストがエントリポイントに到着してから応答が送信された時点までの時間を表します。ただし、この時間はユーザーエクスペリエンスを表すものとしては正確であるものの、多くのスレッドがトランザクションに参加しているため、システムの処理負荷は反映されていません。トランザクションのユーザーエクスペリエンスを基準にした場合、スレッドのパフォーマンス遅延が明白な場合とそうでない場合があります。
処理にかかる時間という観点からトランザクションの完全なコストを理解するには、ティアにおける時間というメトリックを使用することができます。このメトリックは、リクエストの処理に関する各スレッドの合計処理時間を示します。上図で言うと、スレッド 2、3、4 の値と、スレッド 1 のエントリポイントから応答までの処理時間の合計実行時間となります。
ティアにおける時間メトリックの値は、ビジネス トランザクション ダッシュボードの非同期タグにより示されます。
エンドツーエンドの処理
エントリポイントスレッドからの応答は、必ずしもビジネストランザクションの必然的な終了を表していない場合があります。
たとえば、リクエストハンドラのエントリポイントメソッドが、最終応答ハンドラとして機能するものも含め複数のスレッドを生成するアプリケーションについて考えてみましょう。リクエストハンドラはその後クライアントに予備的応答を返します。デフォルトでは、ビジネストランザクションの応答時間を測定するため時計を停止します。一方で、生成されたスレッドは応答ハンドラがクライアントに最終応答を生成するまで、つまり完了するまで実行します。
この場合、初期応答時間は論理的な実際のトランザクション実行時間よりかなり短くなります。
エンドツーエンドメトリックは、このプログラミングパターンを使用する実際のトランザクションを監視します。エンドツーエンドメトリックには、エンドツーエンドのトランザクション時間、1 分あたりのエンドツーエンド トランザクション実行数、およびエンドツーエンドのメッセージ処理イベントにおける遅延発生数が含まれます。
エンドツーエンドメトリックを有効にするには、「非同期トランザクション境界」で説明される方法で非同期トランザクションを設定します。