目次


WebSphere Portal 環境でのパフォーマンスのモニター

WebSphere Portal 環境でパフォーマンスの問題をモニターおよび測定するときの基本をわかりやすく説明するガイドです

Comments

最適のパフォーマンスを求めて WebSphere Portal 環境をチューニングするには、何がチューニングを必要としているのかを知る必要があります。この記事で取り上げるモニター方法は、WebSphere Portal のいくつかの主要エリアをカバーしています。WebSphere Portal 環境の真の動作を表示するだけでなく、ボトルネックや潜在的な問題を最終的に識別するために役立ちます。この記事ではモニター方法の概要を示しますが、特定の方法を詳細に掘り下げることはしません。この種の問題を解決するという課題を持つ多くの人々にとって、この記事は良いスタート地点となるでしょう。この記事の目的は、パフォーマンスの問題をタイムリーに、かつコスト効率の高い方法で解決できるよう十分なアプローチを示すことです。

メモ: The 「リソース」 セクションには、パフォーマンスのチューニング・プロセスを支援するいくつかのリンクが含まれます。

この記事では、パフォーマンスのモニターに関する次のトピックについて説明します。

  • キャッシュ
  • JVM モニター
  • データベース分析
  • クラスタリング
  • ログとデバッグ
  • カスタム・ページ・モニター
  • IBM Tivoli® Composite Application Manager (ITCAM)

キャッシュ

このセクションでは、ポータル内部キャッシュと Dynacache を中心に説明します。

内部ポータル・キャッシュ

WebSphere Portal は、WebSphere Application Server を通じてキャッシュを広範囲に使用する複合アプリケーションです。ご使用になっている環境でこれらのキャッシュをチューニングすることは、パフォーマンスの良いポータルを得るために重要です。標準のインストールでこれらのキャッシュをモニターすることは容易ではなく、特定のキャッシュの使用状況を確認するために、正しいログ・レベルの設定を何度も繰り返すことになります。このアプローチは非効率的な方法であり、面倒でしかも時間がかかる可能性があります。しかし、Internal Portal Cache Listing ポートレットと呼ばれるポートレットを使用すると、内部ポータル・キャッシュをモニターし、以下を含む重要なキャッシュ統計を表示できます。

  • 各キャッシュで現在キャッシュされているエントリーの数
  • 各キャッシュでキャッシュされたエントリーの最大数
  • 各キャッシュの構成済みのサイズ

図 1 は、ポートレットからのcsv形式で出力された結果です。

図 1. Portal Internal Cache Listing ポートレットのサンプル・イメージ
Portal Internal Cache Listing ポートレットのサンプル・イメージ
Portal Internal Cache Listing ポートレットのサンプル・イメージ

最適のパフォーマンスを達成するには、キャッシュ・サイズと存続時間に正しい値を設定することが重要です。

  • 特定のキャッシュが小さすぎると、WebSphere Portal サーバーが頻繁にデータベースにアクセスし、パフォーマンスが低下することがあります。
  • キャッシュが大きすぎると、JVM でメモリーが浪費され、低メモリー状態またはページングの増加が生じることがあります。どちらもパフォーマンスの低下を招きます。
  • キャッシュが頻繁に有効期限切れとなると、不要なパフォーマンス低下が生じることがあります。このため、キャッシュの存続時間の値も重要なチューニング項目です。

また、ポータルのキャッシュ動作、つまりパフォーマンスは、WebSphere Portal のバージョンをアップグレードすると変わる可能性があることに注意してください。パフォーマンスの調査時は常にキャッシュをチェックすることが重要で、Internal Portal Cache Listing ポートレットを使用すると、これを簡単に実行できます。

キャッシュ・サイズおよびパフォーマンスをチューニングするときは、このポートレットで得られたデータを WebSphere Portal Performance Tuning Guide (「リソース」参照) とともに使用します。このアプローチにより、特定の環境とワークロードのために最適の値を設定することができます。

Dynacache

WebSphere Application Server のキャッシュ・モニターも、アプリケーションのモニターを支援する有用なツールです。キャッシュが構成されているポートレットに対し、次の値を表示します。

  • ヒットとミスの数
  • キャッシュの使用度
  • LRU (最長未使用時間) アルゴリズムを使用してキャッシュから除去された項目数
  • サーブレットのキャッシュがオンかどうか

このツールから得られる値を図 2 に示します。

図 2. Dynacache の統計画面の例
Dynacache の統計画面の例
Dynacache の統計画面の例

ご存じのように、WebSphere Application Server でサーブレットのキャッシュが有効になっている場合は、ポートレットの出力をキャッシュできます。多くの場合、キャッシュは無効になっているか、キャッシュを利用するようポートレット自体が構成されていません。ポートレットのキャッシュの構成方法は本書の範囲外ですが、それを支援する有用な資料がいくつかあります (「リソース」セクションの「Caching Portlet Output」および「Develop high performance Web sites with both static and dynamic content using WebSphere Portal V5.1」を参照してください)。特定のポートレット、特にパーソナライゼーションを使用する場合は、キャッシュが望ましくない点に注意してください。ユーザー間でコンテンツを共有するポートレットについては、キャッシュによって全体のパフォーマンスが大幅に改善される可能性があります。

JVM モニター

どの Java™ 2 Platofrm, Enterprise Edition アプリケーション・サーバーでも、Java 仮想マシン (JVM) が、処理の大半を司るキー・コンポーネントとなっています。WebSphere Portal 環境では、レンダリングされる各ページは JVM によって処理されます。JVM にはさまざまなコンポーネントが関与しており、各コンポーネントが WebSphere Portal サイト全体のパフォーマンスに異なる影響を与えます。ヒープ、サーブレット・スレッド、および DB 接続プールなど、トップレベルのコンポーネントをモニターすることにより、JVM によって要求が処理されるときに何が発生するのかが明らかになります。また、潜在的なボトルネックの場所も示されます。

WebSphere の Performance Monitoring Infrastructure (「リソース」参照) を使用すると、さまざまな WebSphere Application Server コンポーネントおよび JVM の主要部分からのパフォーマンス・データを収集できます。このインフラストラクチャーを、パフォーマンス・データを表示およびモニターする Java クライアントの IBM Tivoli Performance Viewer (「リソース」参照) と組み合わせることにより、カスタム・コードをまったく書かずに PMI (Performance Monitoring Interface) のデータを表示できます。また、Tivoli Performance Viewer には、データに基づいてチューニングの変更を推奨するアドバイザーが含まれています。

もちろん、WebSphere によって提供される Java Management Extensions (JMX) API (「リソース」参照) を使用して、カスタムのモニター・コードを書くこともできます。最初の手順は、Performance Monitoring Service をオンにし、仕様レベルを low (低) に設定します。PMI サービスをオンにする方法の詳細については、WebSphere Library (「リソース」) を参照してください。JMX を使用すると、アプリケーション・サーバーのメトリックを自動的にポーリングし、分析用のデータを記録する Java コードを容易に記述できます。収集したデータは、コンマ区切り値 (CSV) ファイルに格納できます。このファイルは、Microsoft® Excel や OpenOffice など、ほとんどのグラフ用ツールにインポートできます。データをグラフ化すると、傾向とパターンを容易に識別できます。

管理クライアントを作成し、PMI 値を取得するサンプル・コードも、WebSphere Library に記載されています。また、developerWorks® の記事「Writing a Performance Monitoring Tool」も参照してください。これに含まれるサンプル・コードは、この記事の範囲外のものです。

モニターする価値があるメトリックとしては、Java Database Connectivity (JDBC)、JVM メモリー使用量、サーブレット送信スレッド、およびデータベース接続などがあります。IBM HTTP Server スレッド統計と組み合わせると、このレベルのモニターはホスティング環境の状況を調べる強力な方法となります。

ノードごとに 2 つのアプリケーション・サーバーを持つ 5 ノード構成の WebSphere Portal 環境を図 3 に示します。

図 3. JVM モニターのサンプル
JVM モニターのサンプル
JVM モニターのサンプル

データベース分析

データベースは、パフォーマンスに関連する問題を分析する際に、調べなければならないもう 1 つのキー・エリアです。WebSphere Portal はデータベースを広範囲に使用して情報を格納しています。特に、最良のパフォーマンスを得るには、次のデータベースをモニターし、この順番で最適化するとよいでしょう。

  • ポータル・データベース
  • LDAP データベース
  • アプリケーション固有のデータベース

これらの中で、IBM DB2® を使用しているデータベースがあれば、データベース・パフォーマンスのモニターおよびチューニングを支援するいくつかのオプションを利用できます。基本的なDB2 データベース・システム・モニターは次のとおりです。

  • Snapshot monitors. 特定の時点でのデータベースの状態をキャプチャーできます。
  • Event monitors. モニター・イベントの発生をキャプチャーし、ログに記録できます。

どちらのモニターの結果も、モニター・エレメントに格納されます。利用可能なモニター・エレメントは次のとおりです。

  • Counters. イベントの発生回数の合計を示します。
  • Gauges. 項目の現行値を示します。
  • Watermarks. 項目が到達した最小値と最大値を示します。
  • Information elements. 参照用の詳細情報を示します。
  • Timestamps. アクティビティーが発生した日時を示します。
  • Time elements. アクティビティーに費やされた合計時間を示します。

DB2 データベース・システム・モニターの詳細については、記事 「Performance Monitoring, Part 1: It's a Snap(shot)」および 「Performance Monitoring, Part 2.」を参照してください。

z/OS® で DB2 を実行している場合は、DB2 Performance Monitor for z/OS systems (「リソース」参照) をダウンロードする必要があります。このモニターは、長時間実行されている SQL ステートメント、競合のロック、およびストレージの消費量を識別する優れたツールです

通常のアクティビティー中のデータベース接続の数をモニターする必要があります。WebSphere Application Server 内の接続プール設定を適切にチューニングするには、接続ワークロードを知ることが重要です。図 4 に、カスタム・ツールでデータベース接続をモニターしている画面キャプチャーを示します。カスタム・ツールを記述する必要はないことに注意してください。このカスタマイズは、実動システムに直接アクセスできない開発者のために行われたものです。

図 4. さまざまなデータベースにおける DB 接続のモニター
さまざまなデータベースにおける DB 接続のモニター
さまざまなデータベースにおける DB 接続のモニター

クラスタリング

大規模な環境での問題のトラッキングは、面倒な作業になりがちです。1 つのクローンだけの問題を再現することは、困難な場合があります。WebSphere の ワークロード・マネージャー (WLM) はロード・バランシングを実行し、クラスターで利用可能な任意のクローンまたはアプリケーション用に定義されたセルにわりふることができます。WebSphere Application Server 用に定義された WebSphere ポートを通じてクローンを直接ヒットすることもできますが、ほとんどの環境ではファイアウォールによってこれがブロックされています。このブロックを回避するために、URL 照会ストリングに基づいてトラフィックをクローンにわりふる IBM HTTP Server (IHS) (Apache) ルールを使用できます。

最初に行うことは、クローンの名前を識別することです。WebSphere Application Server 管理コンソールで指定された名前を使用できます。また、クローンがサービスを受けているポートを知ることも必要です。図 5 を参照してください。

図 5. WebSphere Application Server 管理コンソール
WebSphere Application Server 管理コンソール
WebSphere Application Server 管理コンソール

この情報を入手した後、新しいスタンザを使用して IHS (Apache) 設定(conf) ファイルを編集できます。通常、http.conf ファイルは、「psef|grep http」を実行し、使用中の conf ファイルを識別することによって特定できます。新しい環境の場合は、インストールの説明を参照してください。この例では、キーワードは cloneID で、CloneNames は WebSphere_Portal および WebSphere_Portal_Clone_2、ポートは 9085/9086 です。ターゲットの WebSphere Application Server ホスト名は hostname.ibm.com です。リスト 1 を参照してください。

リスト 1. 新しいスタンザ
<LocationMatch "cloneID$" >
RewriteEngine on
RewriteCond %{QUERY_STRING} ^WebSphere_Portal_Clone_2
RewriteRule /(.*)/cloneID$ http://hostname.ibm.com:9086/$1 [P]

RewriteCond %{QUERY_STRING} ^WebSphere_Portal
RewriteRule /(.*)/cloneID$ http://hostname.ibm.com:9085/$1 [P]
</LocationMatch>

このスタンザはすべての IHS サーバーに追加されます。その後、このスタンザにより、特定のクローンとのセッション・アフィニティーを得られます。たとえば、このスタンザを使用するには、ポータル・アプリケーションにアクセスし、「?cloneID=WebSphere_Portal_Clone_2」を URL に追加します。この要求は WebSphere_Portal_Clone_2 に送信されます。

この方法は、多数のクローンがあり、問題をデバッグまたは再現しなければならない大規模な環境で役立ちます。つまり、要求の送信先を知るために各サーバーの各クローンを 1 つずつ検索したくない場合に適しています。また、クローン固有の問題を特定するとき、またはログのタイム・スタンプに基づいてコンポーネントのパフォーマンス時間を測定するときも、この方法は優れたツールとなります。

ログとデバッグ

ポータルおよび WebSphere のロギング

異なる Websphere Portal コンポーネントに対し、デバッグ・ロギングを有効にすることができます。これを行うには、プロパティー・ファイル <WP Root>/shared/app/config/log.properties を使用するか、WebSphere Application Server 管理コンソールの「トラブルシューティング」->「ログおよびトレース」->「<Application Server 名>」->「診断トレース・サービス」を使用します。コンソール内でデバッグ・ロギングを有効にするには、まず「トレースの使用可能化」を選択します。次に「traceString」 の名前と値のペアを入力し、特定のコンポーネントのためにデバッグ・ロギングを有効にします。出力ファイル名を指定した上で、「適用」をクリックしてください。トレース・ファイルはすぐに大きいサイズになることがあるので、指定する場所には、出力を格納するための十分なスペースが必要です。

コンソールの設定を図 6 に示します。

図 6. コンソールを使用したポータルのロギング
コンソールを使用したポータルのロギング
コンソールを使用したポータルのロギング

例として、2 つのタイプの traceString が役立ちます。

  • WMM. WebSphere メンバー・マネージャー (WMM) を有効にすると、外部メンバーシップ・リポジトリー (通常は LDAP サーバー) への呼び出しをチェックできるようになります。このタイプは、大規模な結果またはグループ内のグループを識別するために使用できます。

    traceString=com.ibm.websphere.wmm.*=all=enabled:com.ibm.ws.wmm.*=all=enabled:
    WSMM=all=enabled:com.ibm.ws.security.*=all=enabled
  • URL mapping. URL マッピングを有効にすると、ページ/ラベル要求ごとに呼び出される URL マッピングの量をモニターおよびカウントできるようになります。制御された環境でこのマッピングを実行すると、マッピング・キャッシュの制限をチューニングするための良い開始ポイントとなります。

    traceString=com.ibm.wps.mappingurl.*=all=enabled:
    com.ibm.wps.command.mappingurl.*=all=enabled:com.ibm.wps.engine.*=all=enabled

他の traceStrings の詳細については、WebSphere Portal Information Center の WebSphere Portal ランタイム・ロギングのトピック (「リソース」) を参照してください。また、WebSphere Portal 管理ユーザー・インターフェースの「ポータル分析」->「トレースの使用可能化」からも、WebSphere Portal トレースを有効にできます。これらのトレースはその場で適用され、再起動後は維持されません。しかし、デバッグには役に立ちます。図 7 を参照してください。

図 7. ランタイムのポータル・トレース
ランタイムのポータル・トレース
ランタイムのポータル・トレース

アプリケーション固有のロギング

アプリケーションが Log4J (「リソース」参照) を使用する場合は、サーバーをリサイクルせずに Log4J のロギング・レベルを動的に有効または無効にできるサーブレットがあります。このサーブレットを使用すると、トラブルシューティングと開発をより簡単にすることができます。次の手順に従います。

  1. サーブレットをインストールするには、まず、Apache Sandbox (「リソース」参照) からソース・コード (ConfigurationServlet.java) を入手します。
  2. このコードをコンパイルし、クラス・ファイルを <WP root>/shared/app/org/apache/log4j/servlet/ConfigurationServlet.class. に配置します。
  3. <WAS Root>/config/cells/<cellname>/applications/wps.ear/deployments/wps/wps.ear/WEB-INF/web.xml. にある web.xml を編集します。
  4. サーブレットのリストの最後に、リスト 2 に示すコードを追加します。

    リスト 2. サーブレットのリスト用のコード
    <servlet>
    <servlet-name>log4j</servlet-name>
    <display-name>Log4j configuration Servlet</display-name>
    <servlet-class>org.apache.log4j.servlet.ConfigurationServlet</servlet-class>
    </servlet>
  5. サーブレット・マッピングのリストの最後に、リスト 3 に示すコードを追加します。
    リスト 3. サーブレット・マッピングのリスト用のコード
    <servlet-mapping id="log4j-Config">
    <servlet-name>log4j</servlet-name>
    <url-pattern>/log4j/*</url-pattern>
    </servlet-mapping>

Aサーバーのリサイクル後、基本コンテキストの URIである http://<hostname>/wps/log4j を使用して、Log4J 構成を素早くロードし、ロギング・レベルを動的に設定できます。

インターフェースを図 8 に示します。

図 8. Log4J の動的なロギング設定
Log4J の動的なロギング設定
Log4J の動的なロギング設定

メモ: このバージョンは 1 つのクローンだけをサポートするため、クラスター環境を使用している場合は、ソースを変更することにより複数のクローンで使用できます。

カスタム・ページ・モニター

ロードが遅いページの原因を特定するとき、特に問題が散発的に発生する場合は、生成された HTML ソースにデバッグ・タイミング情報を追加すると効果的なことがあります。使用されるのは、以下に関するタイミングなどです。

  • 個々のポートレット
  • ポートレット全体
  • サーブレット・フィルター
  • マストヘッド
  • 左側のナビゲーション
  • カスタム・アプリケーション・プロセス

パフォーマンス・データを取得するために、カスタム・ページ・モニターの実装は必ずしも必要ありません。WebSphere Portal 内のパフォーマンス・モニター・インフラストラクチャーにより、必要なデータを得られる場合があります。たとえば、PMI を Web アプリケーション・レベルでのみ使用することにより、セッション数またはリクエストでの消費時間をモニターできます。

しかし、カスタム・モニターでは、タイミングを HTML コメントとして出力し、ソースを見るだけでコメントを確認できるようにすることが戦略となっています。実稼働環境でモニターしていない場合は、ページの HTML の一部としてタイミングを表示できます。実稼働環境でも、この方法はパフォーマンスに大きなオーバーヘッドをもたらさずにモニターできる効率的な方法であることがわかります。

このタイミング情報を追加する最も簡単な方法は、テーマ JSP を変更することです。WebSphere Portal のカスタム・テーマを持っていない場合は、次の場所で既存のテーマ JSP を入手できます。
/WebSphere/AppServer/installedApps/<clone>/wps.ear/wps.war/themes

たとえば、デバッグ・タイミング情報を追加するには、ファイルの最初の方にある次の行を使用して、テーマの Default.jsp を更新します。

<% long start = java.lang.System.currentTimeMillis(); %>

この更新により、ページのレンダリングの開始時刻が初期化されます。この時点からレンダリングに要した時間を出力するには、次の行を JSP の後半で使用します。

<!-- TOTAL TIME: <%= java.lang.System.currentTimeMillis() - start %>ms -->

アイデアとしては、このデバッグ情報に似たコードを、レンダリングされたページの主要エリアの回りに配置することです。次に、ページをレンダリングするときに、HTML ソースを表示することにより、各主要エリアのレンダリングに要した時間を把握できます。何を測定するのかという分析に基づき、特定の時点で start 変数の値をリセットすることが必要な場合もあります。たとえば、左側のナビゲーションまたはマストヘッドのリンクをレンダリングするのに要した時間を測定できます。カスタム・アプリケーションを実行している場合は、これらのレンダリング・フェーズでカスタム・コードを呼び出すことがあります。

この方法を用いて個々のポートレットでタイミングを設定するには、最初に、テーマの Default.jsp 内でコンテンツ・スペースをレンダリングする部分を見つけ、その直前でタイマーをリセットします。この例では、リスト 4 に示すように、すべてのポートレットのレンダリングに要した合計時間も出力します。

リスト 4. レンダリングに要した合計時間
<% start = java.lang.System.currentTimeMillis(); %>
<!--<CONTENTSPACE>--> <wps:screenRender /> 
<!--</CONTENTSPACE>-->
<!--  PORTLET TOTAL TIME: 
<%= java.lang.System.currentTimeMillis() - start %>ms -->

次に (これがポイントになりますが)、以下の場所にある WebSphere Portal サーバーの UnlayeredContainer-H.jsp ファイルを編集する必要があります。
/WebSphere/AppServer/installedApps/<clone>/wps.ear/wps.war/skins
model.render(child) へ呼び出しの直前または直後のしかるべき時点、つまりモデルへの繰り返し処理が行われている場所に、次の行を追加します。

<% start = java.lang.System.currentTimeMillis(); %>

<!-- PORTLET TIME: <%= java.lang.System.currentTimeMillis() - start %> -->

より長いコードの抜粋をリスト 5 に示します。

リスト 5. model.render(child) への呼び出し
for (Iterator iterator = model.getChildren(currentElement);iterator.hasNext();)
{
CompositionNode child = (CompositionNode) iterator.next ();
CompositionMetrics childMetrics = child.getMetrics();
start = java.lang.System.currentTimeMillis();
%>

<td valign="top" <% String width = 
(String)childMetrics.getValue(childMetrics.WIDTH);
if (width != null)
{
out.print ("width=\"");
out.print (width);
out.print ("\"");
} %>>
<% model.render (child); >
</td>
<!-- PORTLET TIME: <%= java.lang.System.currentTimeMillis() - start %> -->
<% } %>

このコードをここに挿入した効果として、ページ上でレンダリングされるポートレットごとに、ポートレットのレンダリングにかかった時間をミリ秒単位で表示する HTML コメントがページの下部に配置されます。JSP での変数のスコープにより、同じ start 変数を Default.jsp からはリセットしていない点に注意してください。

メモ: 個々のポートレットのレンダリング時間を表示するこの特定の方法は、ポートレットの並行レンダリングがオフのときにのみテストされました。

この方法で、デバッグ・タイミング情報を HTML コメントに追加する利点は何でしょうか。まず、この情報がコード内に格納されると、特に問題が散発的に発生する場合、ログ・ファイルやデバッグ出力を通じた解析よりも、個々のコンポーネントのタイミングへのアクセスがたいへん容易になります。特定の要求をバックエンドのログ・ファイルで照合することは、場合によっては困難です。この方法を用いると、ページのロードが遅いという問題が発生したとき、常に HTML ソースを手動またはプログラムでチェックすることにより、遅延の原因を特定し、最終的にページのロード時間の合計を個々のコンポーネントに分割することができます。

さらに、この方法を使用すると、ポーリングおよびページの定期的なロードによって WebSphere Portal ページを調べるカスタム・アプリケーションを作成しやすくなります。個々のコンポーネント・タイミングのパフォーマンスは、抽出、グラフ化、および長時間にわたる表示が可能です。この方法により、パフォーマンスの傾向とパフォーマンスのスパイク (急激な上昇) を把握できます。たとえば、1 つのケース・スタディーとして、特定の WebSphere Portal キャッシュが定期的に途中で期限切れになり、これによってカスタム・アプリケーション・コードでパフォーマンス・スパイクが発生することがありました。個々のコンポーネントをグラフ化することにより、この問題を容易に発見できました。

カスタム・ツールを記述するための Apache HTTP クライアント・ライブラリー

カスタム・モニターおよびグラフ・ツールを記述したい開発者は、オープン・ソースの Jakarta Apache HTTP クライアント・ライブラリー (「リソース」参照) を使用できます。

このクライアント・ライブラリーにより、開発者は HTTP プロトコルを用いた一般的なブラウザー対話を簡単な方法でプログラミングすることができます。また、このクライアント・ライブラリーは、Cookies、SSL、およびすべての HTTP コマンドをサポートしています。いかに簡単であるかを示すために、URL で HTTP GET を実行するコード・スニペットをリスト 6 に掲載します。

リスト 6. HTTP GET
HttpClient client = new HttpClient();
client.getState().setCookiePolicy(CookiePolicy.COMPATIBILITY);
GetMethod getMethod = new GetMethod(url);
getMethod.setFollowRedirects(true);
int statusCode = client.executeMethod(getMethod);
String htmlData = getMethod.getResponseBodyAsString();

この方法で測定できるものに制限はありません。カスタム・アプリケーションを実行している場合は、要求を処理するどのステップも測定できます。これらのステップのタイミングを属性として要求オブジェクトに追加し、次のようなコードを使用して、JSP で後から HTML コメントに出力します。

<!-- SERVLET FILTER TIME: <%= (((Long)request.getAttribute("servletEndTime")).longValue() - ((Long)request.getAttribute("servletStartTime")).longValue()) %>ms -->

メモ: 前の例では、カスタム・コードをアプリケーションに追加する必要があります。これにより、測定されたコンポーネントの適切な開始時刻と終了時刻が追加されます。つまり、この場合は、サーブレット・フィルターで費やされた合計時間になります。

このコードによって生成される情報の種類を示す例として、WebSphere Portal ページをポーリングし、HTML ソースから抽出した各コンポーネントのタイミングをグラフ化するカスタム・アプリケーションがあります。これを図 9 に示します。

図 9. カスタム・アプリケーションのタイミング・グラフ
カスタム・アプリケーションのタイミング・グラフ
カスタム・アプリケーションのタイミング・グラフ

IBM Tivoli Composite Application Manager

今日の多くのアプリケーションは非常に複雑で、さまざまなテクノロジーやソフトウェア (Web サーバー、アプリケーション・サーバー、データベース、およびバックエンド・システムなど) に基づいています。一般的なモニター・ツールは個々のエリアでは十分に機能しますが、これらの複合アプリケーションを全体的にモニターできるツールは多くありません。

Tivoli Composite Application Manager は、管理サーバーとデータ・コレクターの 2 つの主要コンポーネントで構成されています。データ・コレクターはアプリケーション・サーバーに配置されて目的の情報を収集するのに対し、管理サーバーはすべてのデータ・コレクターから情報を取り込み、その分析を可能にします。

Tivoli Composite Application Manager には、次のような機能があります。

  • オンデマンドのモニタリング (MOD: Monitoring on demand)。問題があると疑われるタイム・フレーム内で、一定の割合で要求のサンプリングをキャプチャーするスケジュールを設定できます。管理サーバー上でこのツールを使用すると、遅いトランザクションを特定および分析できます。オンデマンドのモニタリングにより、実動モード (基本データ) から、問題特定モード、そしてトレーシング・モードに至るまで、幅広い範囲でさまざまなモニター・レベルを設定できます。これにより、低レベルの詳細を得られます。
  • 処理中の要求の検索。システム上のリアルタイム要求を分析できます。
  • 履歴分析および傾向に基づき、アプリケーションのパフォーマンスを分析できます。
  • トラップを設定し、問題のエリアを特定してトラブルシューティングを実行できます。
  • メモリー診断により、メモリー・リークの検出および修正を支援します。
  • 問題分析に役立つ、すぐに使用できるレポート・ツールが用意されています。

Tivoli Composite Application Manager は、さまざまなアプリケーションおよびサブシステムにまたがる複合アプリケーションにとって有用なツールです。リアルタイム要求の分析、傾向の監視とアプリケーション内での問題特定の支援など、有益な情報をもたらします。

まとめ

Websphere Portal に関するパフォーマンスの問題を効率よく解決するには、環境を十分にモニターし、測定することが重要です。WebSphere Portal 環境を正確に把握することが、問題とその原因を理解する上で役立ちます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus, WebSphere
ArticleID=415459
ArticleTitle=WebSphere Portal 環境でのパフォーマンスのモニター
publish-date=07242009