要求メトリックを使用する理由

要求メトリックは、個々のトランザクションのトラッキングを可能にするツールであり 、WebSphere® Application Server の各主要コンポーネントにおける処理時間を記録します。

始める前に

要求メトリックによって追跡された情報は、後で検索や分析を行うためにログ・ファイルに保存したり、アプリケーション応答測定 (ARM) エージェントに送ったり、またはその両方を行うことができます。
トランザクションがシステム内を流れる際に、要求メトリックは情報を追加して、各コンポーネントからのログ・レコードを相関付けできるようにし、そのトランザクションの全体像を構築します。 結果は、以下の例のようになります。
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 メソッドに対してのみ計測機能を使用可能にすることができます。 このフィルター操作メカニズムは、さらに焦点を合わせたパフォーマンス分析をサポートします。

以下の 5 つのタイプのフィルターがサポートされています。
  • ソース IP フィルター
  • URI フィルター
  • EJB メソッド名フィルター
  • JMS パラメーター・フィルター
  • Web サービス・パラメーター・フィルター

フィルター操作が使用可能な場合、フィルターと一致する要求のみが要求メトリック・データを生成し、ログ・レコードを作成し、ARM インターフェースを呼び出します。 稼働中のシステムに処理を追加し (具体的にはトレース情報を生成し)、システムに打撃を与える可能性がある他のソースからの要求を無視して、通常の負荷に関連する特定のタイプの要求のパフォーマンスを評価することができます。

注: フィルターは、要求が最初に WebSphere Application Server に入る際のみ適用することができます。

手順

次の例を参照しながら、要求メトリックの使用法について学習します。

この例では、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 を送信します。

この例では、少なくとも以下の 3 つのトレース記録が生成されます。
  • Web サーバー・プラグインのトレース記録は、マシン 192.168.0.1 のプラグインのログ・ファイル (デフォルト・ロケーションは plugins_root/logs/web_server_name/http_plugin.log ) に表示されます。
  • [AIX Solaris HP-UX Linux Windows][z/OS]サーブレットのトレース記録は、マシン 192.168.0.1 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
  • [IBM i]サーブレットのトレース記録は、マシン 192.168.0.1 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
  • [AIX Solaris HP-UX Linux Windows][z/OS]増分 Bean メソッド起動のトレース記録は、マシン 192.168.0.2 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
  • [IBM i]増分 Bean メソッド起動のトレース記録は、マシン 192.168.0.2 のアプリケーション・サーバーのログ・ファイル (デフォルト・ロケーションは profile_root/logs/appserver/SystemOut.log) に表示されます。
注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
マシン 192.168.0.1 に表示される 2 つのトレース・レコー ドは、以下の例のようになります。
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 
マシン 192.168.0.2 に表示されるトレース・レコードは、 以下の例のようになります。
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

トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_requestmetrics
ファイル名:tprf_requestmetrics.html