J2EEパフォーマンス・チューニングの“虎の巻”・前編

≫ HP-UX 11i
Knowledge-on-Demand

≫コラム

≫連載
≫特集、特別企画

ドキュメント/ツール

HPラボ

≫Webキャスト

J2EEのトランザクションを解剖する

J2EEアプリケーションのパフォーマンス・チューニングにおいて、コア氏がまず強調するポイントは、トランザクションの「レスポンス時間の内訳」をドリルダウンする作業の必要性だ。図1は、J2EEアプリケーションにおけるユーザ・レスポンス時間がどのような処理に費やされるか示した図である。

図1：J2EEアプリケーションのレスポンス時間の内訳

ユーザから見たレスポンス時間は、「Web層」、「アプリケーション・サーバ」、「データベース」の各階層における処理時間を集約したものだ。よって、まずはこの3つの階層のそれぞれで、どの程度の時間が経過しているかを把握する。さらに必要に応じて、階層間の呼び出しに要する時間をはじめ、J2EEコンポーネントやJDBCドライバ単体での処理時間などを計測する。コア氏は「こうしたレスポンス時間の内訳を知ることが、システム全体のSLO(サービスレベル目標)を設定する基礎となる」と説明する。

どのような内容のトランザクションを実行しているのか理解しておくことも、不可欠なステップである。例えば高度に複雑なトランザクションや、長時間を要する大規模な検索など、それぞれがどのくらいの頻度で実行されるかを明らかにする。こうした理解を通じて、個々のアプリケーションに最適なアーキテクチャが次第にあぶり出されてくる。「例えば大規模な検索については、Fast Lane Readerパターンの導入も検討すべきだろう」とコア氏は述べる。ここで言うFast Lane Readerパターンとは、リードオンリーのデータベース・アクセスについてはEJBやO/Rマッピングをバイパスし、JDBCを利用して大量のレコードを効率よく取得するデザイン・パターンのことである。

	OpenView Transaction Analyzerを使う

こういったトランザクションの“解剖”のためのツールとして、コア氏はHPが提供するアプリケーション管理ソフトウェア「HP OpenView Transaction Analyzer(OVTA)」を利用している。OVTAは、J2EEアプリケーションにおけるトランザクションのトレースを実行し、個々のJ2EEコンポーネントに至る詳細レベルのパフォーマンスをGUI表示できるツールである。

OVTAでは、まず個々のHTTPリクエストに対するレスポンス時間の一覧が図2のように表示される。

図2：OVTAによるHTTPレスポンス時間の一覧表示

オレンジ色で表示されているHTTPリクエストは、レスポンス時間があらかじめ設定したSLOを超過しているものを表している。そこで各行の「Drill Down」ボタンをクリックすることで、SLO超過の原因を探るためのトランザクションのドリルダウンが可能になる(図3)。

図3：OVTAによるトランザクションのトレース

図3の例では、「/petstore/main.screen」というパスのページを表示するまでに要したレスポンス時間について、J2EEアプリケーションを構成する各階層(HTTP、JSP、サーブレット、EJB、JDBC)がどの程度の割合を占めているかグラフ表示されている。ここから、コード・レベルのコールグラフを分析することが可能だ(図4)。

図4：OVTAによるコールグラフの追跡

さらには、OVTA製品に備わるツール Java Diagnosticsを用いることで、より下位レベルのメソッド単位やスレッド単位の処理時間をはじめ、ガーベジ・コレクションの実行状況やオブジェクト割り当て状況までを追跡表示できる。コア氏は、「OVTAを利用することで、アプリケーションのどの部分で、どのようなタイミングで問題が発生しているかすばやく突き止められ、対処方法も速やかに明らかにできる」と、その有用性を評価している。

パフォーマンスの足を引っ張るそのほかの要因としては、レガシーシステム連携時のCICS(トランザクション処理ミドルウェア)の処理遅延や、ネットワークの遅延、そしてHTTPトラフィックの過多などがある。実際にコア氏が経験したある事例では、アプリケーションのレスポンスが思ったように向上しないという現象が発生していた。そこで同氏はOVTAを用いて個々のトランザクションの処理時間をトレースし、その原因がCICS側にあると特定できたという。

後半では、トランザクション・レベルからシステム・レベルへと視点を変えて、コア氏が明かすJavaパフォーマンス・チューニング技法を紹介する。