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