キース・ジブリュースキー、カーステン・フレンズバーグ著

iSeries上で稼働する5250ベースのトランザクション・アプリケーションを開発またはサポートしている方は、アプリケーションの性能を管理するためのツールを自由に使用できます。WRKSYSSTS（Work with System Status）やWRKACTJOB（Work with Active Jobs）などといったシステム・コマンドは、トランザクションの応答時間やトランザクションのスループットなどの重要な性能指標に関する貴重な情報を提供します。

コアのオペレーティング・システムのユーティリティ以外にも、ライセンス製品のPerformance ToolsやiSeriesサービスのPerformance Management（PM）に含まれるレポート機能を使用することで、トランザクション性能指標を履歴順にトレースできます。この種のアプリケーションにおいて性能上の問題が明らかになったときは、STRPFRTRC（Start Performance Trace）コマンドによってトレース機能を起動し、個々のトランザクションを分析して、データベース・レコードやプログラムのロックなどといった性能のボトルネックとなっている原因を突き止めることができます。

しかし、Webサーバーやアプリケーション･サーバー、ODBCなどのデータベース･テクノロジを使用した新しいテクノロジによって、5250アプリケーションに変更が加えられた場合や、アプリケーションそのものがそれらのテクノロジに置き換えられた場合はどうでしょうか。WRKSYSSTSや一般的に利用されているPerformance Toolsなどのツールのレポート機能では5250以外の環境のトランザクション性能を測る指標が実装されていないため、トランザクション性能の分析を行うことがより難しくなります。

幸いなことに、iSeriesにはこうしたアプリケーション性能に関する新たな困難を乗り切るためのツールがあります。まずは性能エクスプローラ（PEX: Performance Explorer）と呼ばれる強力なツールです。PEXは長年にわたってOS/400上で利用されてきましたが、PEXをアプリケーション性能の分析に利用しようと考えるiSeriesのエキスパートはほとんどいませんでした。

PEXは、異なるビューや詳細レベルで性能を確認することを可能にするさまざまなモードで実行することができます。アプリケーションのトランザクション性能を測定する際に使用するモードはトレース・モードと呼ばれ、アプリケーションの稼働中あるいはシステム・リソースの使用中に発生するイベントと呼ばれるさまざまなアクティビティをトレースすることができます。トレース･イベントの1つにユーザー定義トランザクション･イベントがあります。ユーザー定義トランザクション・イベントをPEXで収集すると、アプリケーションのトランザクションが複数のサーバー・ジョブや複数のスレッドによって処理されているときのトランザクション性能を測定することができます。

PEXは各トランザクション・イベントに対して応答時間、CPU時間、データベースI/Oアクティビティ、データベース以外のI/Oアクティビティを把握します。これらのデータを使用することで、性能分析の担当者は各トランザクション性能の状態や、当該アプリケーションまたは他のアプリケーションを利用している複数のユーザー間の競合ロックによってトランザクションに支障が発生していないかを把握することができます。

PEXのトランザクション・イベントの機能を利用する前に、次の2つのステップを済ませておく必要があります。

1. トレースあるいは測定するアプリケーション・トランザクションを定義する。

2. ステップ1で定義したトランザクション用に、アプリケーション中にトランザクション
APIコールを組み込む。

アプリケーション・トランザクションの定義

トランザクションとはアプリケーション中でトレースあるいは測定する作業の単位です。まずトランザクションを定義し、次にその定義したトランザクションに基づいてアプリケーション中にトランザクションAPIコールを組み込みます。たとえば、財務アプリケーションを開発している場合に、勘定残高を問い合わせるコード部分をトランザクションと定義するケースや、預金残高を更新するコードをトランザクションとするケースなどが考えられるでしょう。

しかし、預金残高の更新に勘定残高の問合せが必要な場合はどうでしょうか。このような場合、2つの別々のトランザクションを定義すればよいのでしょうか。それとも両方の操作を含んだ1つのトランザクションを定義すればよいのでしょうか。答えはアプリケーション内の操作を測定する細かさをどれくらいに定義するかによって異なるため、どちらでもかまわないということになります。預金残高を更新する場合だけでなく、他の理由でも勘定残高の問合せを行うのであれば、その問合せを独立したトランザクションと定義したほうがよいでしょう。要はユーザーの定義次第なのです。

トランザクションAPIは、定義されたトランザクションを測定します。定義するトランザクションは当然のことながらアプリケーションによって異なります。たとえば、小売店舗用アプリケーションでは店の売上データを毎晩回収しているでしょう。この場合、「売上データ回収」トランザクションを定義して、各店舗からの回収をそれぞれ別のトランザクションとしてトレースし測定することができます。同様に、複数の仕入先から見積もりを取るためのアプリケーションでは、各見積り額を取得するのに使用した時間と資源をトレースして測定することができます。アプリケーション中で実際にどのように作業を実行するのか、それのみがトランザクション定義に対する制約になります。

アプリケーション中にトランザクションAPIコールを組み込む

アプリケーション中で測定するサーバー・トランザクションを定義したら、各トランザクションのコードの開始と終了箇所にAPIコールを組み込みます。すると、トランザクションの各開始・終了時点での応答時間、CPU時間、I/Oアクティビティ、占有/ロック・アクティビティが計算されます。

トランザクション開始APIは、QYPE STRT（OPMプログラム用）またはqypeStartTransaction（ILEプログラム用）という名前で、トランザクションの開始箇所に組み込まれます。トランザクション終了APIはQYPEENDTまたはqypeEndTransactionという名前でトランザクションの終了箇所に組み込まれます。1つのトランザクション処理が複数のスレッドやプログラムで行われる場合は、トランザクション・ログAPIを使用してトランザクションがスレッドから別のスレッドへ、あるいはプログラムから別のプログラムへと遷移するにしたがってそのトランザクションをトレースすることができます。トランザクション・ログAPIはQYPELOGTまたはqypeLogTransactionという名前です。トランザクションAPIの詳細は、publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?lang=enにあるiSeries Information Centerに記載されています。[Programming]→[APIs]→[APIs by Category]→[Performance Management]→[PEX APIs]の順にクリックしてください。

各APIにはApplication Trace Data（アプリケーション・トレース・データ）というパラメータがあり、これを使用するとトランザクションの重要な点について性能分析担当者が把握する際に役立つあらゆる関連情報をプログラマが取得することができます。本稿で後述する性能データ収集の例では、Application Trace Dataを使用してトランザクションを実行しているユーザーのユーザーIDとトランザクションがアクセスしている顧客IDを取得しています。これらは性能ボトルネックの原因を分析する際に貴重な情報となります。

たとえば、特定のユーザーが実行しているあるいは特定の顧客用に実行しているトランザクションの性能が悪いことがわかったとしましょう。トランザクション中で上記のデータを取得することで、性能低下の原因となっているユーザーや対象を識別するのに役立ちます。このパラメータに含まれるその他の重要な情報としては、トランザクションがアクセスしているファイル名やレコード番号などがあります。

コード例

PEX APIの導入を容易にし、APIコールインタフェースを簡素化するために、PEX APIをサービス・プログラムPEX001へとパッケージ化しました。このサービス・プログラムでは、すべてのPEX APIがプロトタイプ化されており、サブ・プロシージャを介して、トランザクション性能分析を実行する任意のプログラムから容易に呼び出せるようになっています。

またこのサービス・プログラムはトランザクションIDカウンター機能も提供しています。トランザクションIDは連続する（シーケンシャル）番号で、1つのPEXセッション内で、トランザクション開始、トランザクション・ログ、トランザクション終了の一連のAPIコールを一意に識別します。トランザクションIDカウンター機能には以下の3つのプロシージャが含まれています。

・ Initialize Transaction ID：カウンターID（1つのカウンターシーケンスを識別するもの）を入力としてカウンター記憶域へのポインタを返す。
・ Get Transaction ID：カウンター記憶域へのポインタを入力とし、次のトランザクショIDを返す（複数のMI関数を使用してプロセスごとにカウンター記憶域プロセスへの参照が行われるようにする）。
・ Terminate Transaction ID：カウンター記憶域として使用されているリソースを解放する（この時点ではトランザクションIDを再び初期化しないと再利用できません。PEXセッション中でトランザクションIDを一意に保つには、そのセッション中でこれ以上トランザクション・データを収集する必要がなくなるまでトランザクションIDを終了しないでください）。

このサービス・プログラムを作成する方法についてはPEX001のソース・ヘッダをご覧ください。

性能分析用にプログラム中に組み込むコードスニペットを図1と図2に示します。アプリケーション・トレース・データ（AppTrcData）と性能カウンター（AppPfrCnt）パラメータは、それぞれその使用方法の例を示すために記載されています。

PEX001サービス・プログラムのプロトタイプはコピーブック（図1）に格納されています。プロトタイプをコピーブック中に組み込むことで、プログラムの必要な箇所にプロトタイプをすばやく組み込むことができ、何度も繰り返してコードを書く必要がありません。

図2はPEX API関数を使用して性能データを収集する方法の例を示します。PEX001サービス・プログラム中のPEX関数をプログラム中で利用するには、バインディング・ディレクトリとコピーブック・インストラクション（A）を指定します。性能データを収集するための一意のトランザクションIDを生成するのに必要なトランザクション・カウンターは、Bで初期化されます。

Cでは、StrTrnPexサブ・プロシージャを呼び出すことで測定対象のトランザクションの開始が記録され、トランザクションが終了する箇所（D）でEndTrnPexサブ・プロシージャがコールされます。これでPEX機能は特定のトランザクションに関連したすべての性能データが登録されたことになります。性能データの収集が完了すると、その情報は複数のデータファイル中に抽出され、性能分析レポートの生成などに利用されます。これについては後述します。

トランザクション性能データの収集

トランザクションAPIコールをアプリケーション中に組み込んだら、以下の手順でアプリケーションの実行中にトランザクション性能指標を収集することができます。

1. ADDPEXDFN（Add PEX Definition）コマンドを使用してPEXが収集するトランザクション・データを定義する。
2. STRPEXコマンドを使用してPEXを起動し、ステップ1で定義したトランザクション・データの収集が可能な状態にする。
3.　アプリケーションを実行する。
4.　ENDPEXコマンドを使用してPEXによるトランザクション指標の収集を終了し、トランザクション・データをPEXデータベースに書き出す。

前述した通り、PEXはさまざまなモード、さまざまな詳細レベルで実行することができます。したがってADDPEEXDFNコマンドを使用する方法はたくさんあります。ここでの目的はアプリケーションのトランザクション・データを収集することなので、ADDPEXDFNコマンドは次の通りに呼び出します。

ADDPEXDFN DFN(APPTXN)
　 TYPE(*TRACE) JOB((*ALL))
　 TRCTYPE(*SLTEVT) SLTEVT(*YES)
　 OSEVT((*USRTNS))

DFNパラメータにはSTRPEXコマンドがどのデータを収集するのかを識別するために使用される定義名が含まれています。OSEVTパラメータを指定すると、ユーザー（アプリケーション）のトランザクション・データ（*USRTNS）が収集されます。JOBパラメータに*ALLという値を指定すると、システム上で実行されているすべてのジョブに対してトランザクション・データが収集されます。あらかじめ定義された一連のジョブがアプリケーションに含まれている場合、*ALLの代わりにその中のジョブ名を指定することもできます。

次に、STRPEXコマンドを次のように呼び出して性能データの収集を開始します。

STRPEX SSNID(APPTXN1)
　 OPTION(*NEW) DFN(APPTXN)

SSNIDパラメータはデータ収集のための今回のセッションを一意に識別するための値です。DFNパラメータはADDPEXDFNコマンドに与えるDFNパラメータと同じです。

PEXが起動したら、PEX APIコールを含むすべてのアプリケーションに対してトランザクション・データが収集されます。PEXのセッションが終了すると、トランザクション・データはQAYPEMIUSR、QAYPETASKI、QAYPETIDX、QAYPERUNIの4つのデータベースに格納されます。

トランザクション性能データはENDPEXコマンドが次のように実行されるまでデータベース・ファイルに格納されません。

ENDPEX SSNID(APPTXN1) OPTION(*END)
　 DTAOPT(*LIB) DTALIB(TXNLIB)
DTAMBR(*SSNID) RPLDTA(*YES)
　 TEXT(‘My Transaction Data’)

この例では、トランザクション・データはDTALIBパラメータで指定したTXNLIBライブラリに格納されます。DTAMBRパラメータは格納するデータのデータベース・ファイル・メンバーを指定します。今回の場合、メンバー名はSSNIDパラメータの値と同じでAPPTXN1となります。SSNIDパラメータはSTRPEXコマンドに与えたSSNIDパラメータと同じでなければなりません。

注記: PEXを初めて起動すると、使用される可能性のあるすべてのPEXモードに対してデータベース・ファイルが作成されます。そのため、約50個のファイルが作成されますが、アプリケーションのトランザクション・イベントではそのうちの4つだけを使用します。

トランザクション･データを継続的に収集することは技術的には可能ですが、1日のうちのピーク時に1〜2時間程度データを収集するという使い方が一般的です。この場合、アプリケーションをあらかじめ決めた時間実行させるまでENDPEXコマンドの呼び出しを遅延させます。

トランザクション・データを収集したら、SQLクエリを使用してデータを処理、分析することができます。前述した通り、PEXは4つのデータベース･ファイルを作成します。この4つのファイルはトランザクション・データを解析する際には重要ですが、中でももっとも重要な性能情報は次の2つのファイルに収集されています。

　・ QAYPEMIUSR　：トランザクション・イベントの生データが含まれるファイル。
　・ QAYPETIDX　：データの収集中に生成された各イベントやトランザクションのタイム
　　スタンプ、CPU番号、TDE（タスクID）番号が含まれるファイル。

QAYPEMIUSRファイルとQAYPETIDXファイルは、QRECNという名前のレコード番号フィールドでジョインされています。トランザクション・データを分析する際に必要となるSQL文を処理するときにこのようにしてこの2つのファイルをジョインする必要があります。

SQLエイリアスの定義

SQLクエリを実行する前に、アクセスする必要のある各メンバーに対してSQL ALIASを定義します。これは、SQLがマルチ・メンバーのファイルをサポートしていないためです。別の方法として、OVRDBF CLコマンドを使用する方法もあります。今回の例の分析に必要なSQL ALIAS定義を以下に示します。

CREATE ALIAS MIUSR FOR
　 TXNLIB/QAYPEMIUSR(APPTXN1)

CREATE ALIAS TIDX FOR
　 TXNLIB/QAYPETIDX(APPTXN1)

注記: 次のセクションで述べるクエリ用のライブラリ･リスト中に、ここ（TXNLIB）で使用されるライブラリ名を入れておく必要があります。

クエリの実行

これでクエリを実行する準備が整いました。SQLセッションで、精査するフィールドを含んだクエリをビルドします。図5では、QAYPEMIUSRロー・トランザクション・ファイルのフィールドのサブセットがQAYPETIDXファイルのタイムスタンプとともに含まれています。このタイムスタンプはトランザクションの全体の応答時間を判断するのに使用します。クエリの結果はタイムスタンプとトランザクションID順にソートされます。

CPU時間やロック・カウンター、ジョブに複数のスレッドが含まれている場合はスレッド情報などといった、図5に示したフィールドよりも多くのフィールドに対してクエリを実行したい場合もあるでしょう。ただし今回の例では応答時間、データベースのロック･アクティビティ、アプリケーション固有のトレース・データに焦点を置きます。アプリケーション固有のトレース・データにはトランザクションを実行したユーザーIDと顧客IDが含まれています。PEXトランザクションAPIを含んだ2つのアプリケーション用に取得したデータに対してクエリを実行した結果を図6に示します。

1つ目のアプリケーションのアプリケーションIDはFinanceAppです。このアプリケーションは、顧客の支払い履歴、クレジットの上限、その他の財務基準を調査して、その顧客の信用度を分析します。2つ目のアプリケーションのアプリケーションIDはOrderEntryAppです。このアプリケーションは現在の在庫を調査して、在庫があれば顧客の注文を受け付けます。

図6では、9896と9900がもっとも長く実行されたトランザクションです。両方のトランザクションとも約0.28秒かかっていますが、ここに示したその他のトランザクションのほとんどは0.10以内で終わっています。これは、各トランザクションの開始時と終了時のタイムスタンプを見ればわかります。

ファイル中の3番目のレコードは9896トランザクションの開始時刻を示しています（TXNTYPEフィールドの値の1が、Start Transaction APIが呼び出されたことを意味するため）。ファイル中の4番目のレコードは9896トランザクションの終了時刻を示しています（TXNTYPEフィールドの値の2が、End Transaction APIが呼び出されたことを意味するため）。トランザクションの開始時のタイムスタンプと終了時のタイムスタンプの差を計算すれば、このトランザクション全体の応答時間がわかります。

では、9896トランザクションと9900トランザクションが他のトランザクションより余計に時間がかかっている原因は何でしょうか。これら2つのトランザクションが677回の非同期データベース読み出しと674回の非同期データベース読み出しを実行している点に注目してください。ここでも、トランザクションの開始時のタイムスタンプと終了時のタイムスタンプの差を計算しています。この2つのトランザクション以外のトランザクションはすべて200回未満の読み出しを実行しています。

F20を使用して右側にスクロールするとクエリ文で選択した追加のデータベース・カウンターを表示させることができます(図7)。前述の2つのトランザクションは、非同期データベース書き込みのほとんどと、同期データベース書き込みも数回実行しており、これは通常トランザクションが必要としていたデータが主記憶になかったためシステムがデータベース・レコードをディスクからメモリに読み込む必要があったことを意味しています。PEXトランザクション・データに対してクエリを実行することでわかったこれらのことを理解すると、特定のトランザクションが他のトランザクションに比べてなぜ余計時間がかかっているのかがわかります。

今回の例の場合、アプリケーション開発者は長時間かかっているトランザクションを実行しているアプリケーションを調査して、そのアプリケーション自体を改良するか、そのアプリケーションがアクセスしているデータを改善するかを判断したいと考えています。図6の列１で、これら2つのトランザクションがいずれもFinanceAppによって実行されていることがわかります。

最後にもう1つのコツ

各トランザクションに対するクエリは、必要以上に詳細になる場合もあります。まずはトランザクションの平均応答時間とスループットに関する情報を収集するところからはじめるとよいでしょう。そして、応答時間やスループット率が低いことがわかった場合、前述のテクニックを使用してここのトランザクションの性能を調査するとよいでしょう。

平均応答時間とスループットの統計情報を取得するには、Collection Servicesを実行し、QAPMUSRTNSに対してクエリを実行する必要があります。Collection Servicesを構成して、15秒から1時間の間の間隔で性能データを収集することができます。

QAPMUSRTNSファイルのフォーマットはiSeries情報センターの[Systems management]→[Performance]→[Applications for Performance Management]→[Performance database files]→[Data files containing time interval data]→[QAPMUSRTNS]に記載されています。また、Collection Servicesの詳細については、[Systems management]→[Performance]→[Applications for Performance Management]→[Collection Services]を参照してください。

アプリケーションの実行効率の改善

非5250アプリケーションのトランザクション性能を測定するのは複雑なタスクですが、i5/OSの新しいPEXトランザクションAPIを使用することでiSeriesサーバー上で実行されているアプリケーションについてはこのタスクが容易になりました。アプリケーション中でPEXトランザクションAPIを使用すると、トランザクションのスループット、応答時間、CPU消費率、などといった重要な性能統計情報を取得することができます。こうしたデータを容易に入手できることで、容量計画を今まで以上に上手く行ったり、性能ボトルネックを識別できるようになり、アプリケーションの実行効率が向上しユーザーの満足度も上がります。

キース・ジブリュースキー氏はミネソタ州にあるIBMロチェスター事業所のPOWERシステム性能部門のパフォーマンス・アナリスト兼ソフトウェア・アーキテクトです。同氏は1987年にIBMに入社し、1997年以降iSeriesやeServerの性能に関するさまざまな業務にかかわってきました。同氏は現在、i5/OS、AIX、Linux用のサイジング・ツールの開発を指揮しており、iSeriesの性能およびキャパシティ・プランニングに関して、IBMおよびビジネス・パートナーの営業やサポート・チームに技術的なガイダンスを提供しています。

カーステン・フレンズバーグ氏は、1992年からiSeriesのプログラマをしています。同氏は現在、米国に本社を置くCendant社のグループ会社であるNavasolというヨーロッパのバケーション・レンタル会社でiSeriesのプログラミング・チームのリーダーを勤めています。同氏はデンマークのコペンハーゲンに妻と2人の子供ジュリアン、エミリーと暮らしています。