要求メトリックを使用する理由
要求メトリックは、個々のトランザクションのトラッキングを可能にするツールであり 、WebSphere® Application Server の各主要コンポーネントにおける処理時間を記録します。
始める前に
HTTP request/trade/scenario ------------------------------> 172 ms
Servlet/trade/scenario -----------------------------> 130 ms
EJB TradeEJB.getAccountData ---------------------> 38 ms
JDBC select --------------------------------> 7 ms

応答時間が関連付けられたこのようなトランザクション・フローを使用することにより、ユーザーはパフォーマンスに問題のある領域を特定し、リソース制約の問題をデバッグすることができます。例えばこのフローにより、トランザクションが、Web サーバー・プラグイン、Web コンテナー、Enterprise JavaBeans (EJB) コンテナー、またはバックエンド・データベースのどれにその時間のほとんどを費やしているかを判別できます。 各レベルで集められた応答時間には、そのレベルで費やされた時間と、下位のレベルで費やされた時間が含まれます。例えば、サーブレットの応答時間 (130 ミリ秒) には、エンタープライズ Bean および Java™ Database Connectivity で費やされる 38 ミリ秒も含まれます。このため、サーブレット・プロセスには 92 ミリ秒を要したことになります。
要求メトリックは、特定のトランザクションについて応答時間を追跡できます。要求メトリックは個々のトランザクションを追跡するため、使用するとシステムのパフォーマンスに影響します。 ただし、この機能は、要求フィルター操作機能を使用することによってマイグレーションすることができます。
例えば、ツールにより合成トランザクションを加えることができます。要求メトリックは、これらのトランザクションについて WebSphere Application Server 環境内での応答時間を追跡できます。合成トランザクションは、システムのパフォーマンス・テストに先行した準備として、管理者によってシステムに投入されたトランザクションです。この情報を使用して、管理者は Web サイトのパフォーマンスを調整し、修正処置を行うことができます。 これにより、要求メトリックが提供する情報は、特定の要求タイプのパフォーマンスが許容しきい値を超えた場合を検出するアラート・メカニズムとして使用することができます。 要求メトリック内のフィルター・メカニズムを使用することにより、特定の合成トランザクションにフォーカスし、このシナリオでのパフォーマンスの最適化を行えます。
このタスクについて
分離された問題領域がある場合は、要求メトリックのフィルター操作メカニズムを使用して、特にこれらの領域に焦点を合わせます。例えば、特定のサーブレットまたは EJB メソッドに分離された問題がある場合、URI (Uniform Resource Identifier) アルゴリズムまたは EJB フィルターを使用して、そのサーブレットまたは EJB メソッドに対してのみ計測機能を使用可能にすることができます。 このフィルター操作メカニズムは、さらに焦点を合わせたパフォーマンス分析をサポートします。
- ソース IP フィルター
- URI フィルター
- EJB メソッド名フィルター
- JMS パラメーター・フィルター
- Web サービス・パラメーター・フィルター
フィルター操作が使用可能な場合、フィルターと一致する要求のみが要求メトリック・データを生成し、ログ・レコードを作成し、ARM インターフェースを呼び出します。 稼働中のシステムに処理を追加し (具体的にはトレース情報を生成し)、システムに打撃を与える可能性がある他のソースからの要求を無視して、通常の負荷に関連する特定のタイプの要求のパフォーマンスを評価することができます。
手順
- このセクションの詳しい説明を見直して、要求メトリックを詳しく学習します。
- 要求メトリックを構成および使用可能にします。
- パフォーマンス・データを取得し、アプリケーション・フローをモニターします。
- 追加のインスツルメンテーション・ポイントを必要とする可能性のあるアプリケーションを追跡するために、モニターを拡張します。
例
次の例を参照しながら、要求メトリックの使用法について学習します。
この例では、HitCount サーブレットおよび Increment エンタープライズ Bean を 2 つの異なるアプリケーション・サーバー・プロセスでデプロイします。 次の図に示すように、Web コンテナー層および Enterprise JavaBeans (EJB) コンテナー層は、2 つの異なるアプリケーション・サーバーで 稼働しています。そのような構成をセットアップするには、WebSphere Application Server Network Deployment をインストールします。

Web サーバーと Web コンテナー層の両方が、マシン 192.168.0.1 で稼働し、 Enterprise JavaBeans (EJB) コンテナー層が 2 番目の マシン 192.168.0.2 で稼働していると想定しています。クライアント要求は、 異なるマシン、例えば、192.168.0.3、または他のマシンから送信される可能性 があります。
ソース IP フィルターの使用を示すには、 1 つのソース IP フィルター (192.168.0.3) を定義して使用可能にします。 マシン 192.168.0.3 から発信される要求を http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT を介してトレースできます。 ただし、他のマシンから発信される要求は、 ソース IP アドレスがフィルター・リスト内にないためトレースされません。
ソース IP フィルターを作成することによって初めて、そのソース IP アドレスからの要求が有効にトレースされます。 このツールは、負荷がかかっているシステムでのパフォーマンス問題の検出に有効となります。 通常の負荷が他の IP アドレスから発信されている場合は、 その IP アドレスからの要求がトレースされるということはありません。 要求を生成するように定義済みのソース IP アドレスを使用して、 負荷のかかったシステムのトレース記録を、負荷のかかっていない実行からのトレース記録と比較することによって、 さまざまなホップにおけるパフォーマンス・ボトルネックを調べることができます。 この能力により、複雑なデプロイメント環境の中で、 作業を適切なノードとプロセスの調整に集中させることができます。
管理コンソールを使 用して要求メトリックが使用可能になっていることを確認してください。 さらに、トレース・レベルが少なくとも hops (プロセス境界での書き込み要求トレース) に設定されていることも確認してください。 以前にリストされた構成を使用して、マシン 192.168.0.3 から HitCount サーブレットを介して要求 http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT を送信します。
- Web サーバー・プラグインのトレース記録は、マシン 192.168.0.1 のプラグインのログ・ファイル (デフォルト・ロケーションは plugins_root/logs/web_server_name/http_plugin.log ) に表示されます。
サーブレットのトレース記録は、マシン 192.168.0.1 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
サーブレットのトレース記録は、マシン 192.168.0.1 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
増分 Bean メソッド起動のトレース記録は、マシン 192.168.0.2 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
増分 Bean メソッド起動のトレース記録は、マシン 192.168.0.2 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
PLUGIN:
parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=1
type=HTTP detail=/hitcount elapsed=90 bytesIn=0 bytesOut=2252
Application server (web container tier)
PMRM0003I: parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1
type=URI detail=/hitcount elapsed=60
PMRM0003I:
parent:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1
-
current:ver=1,ip=192.168.0.2,time=1016556190505,pid=9321,reqid=40,event=1
type=EJB
detail=com.ibm.defaultapplication.Increment.increment elapsed=40