IBM Tivoli サービス マネジメン ト製品 Rational Performance Tester に

IBM Tivoli サービス マネジメン
ト製品
Rational Performance Tester に
よるパフォーマンス テストのベス
ト プラクティス
ホワイト ペーパー
文書バージョン 1.1
注意事項
本書に含まれる情報は、如何なる保証も行わずに、現状のまま配布されます。
®
®
®
本ペーパーは、IBM Tivoli サービス マネジメント製品に対する Rational
Performance Tester を使用したパフォーマンス テストのベスト プラクティスを提
示します。
本書は、次の IBM Tivoli サービス マネジメント製品に適用されます：
Ÿ IBM Maximo® Asset Management 7.1 および 7.5
Ÿ IBM SmartCloud Control Desk 7.5
Ÿ IBM Tivoli Change および Configuration Management Database 7.1 および 7.2
Ÿ IBM Tivoli Provisioning Manager 7.1 および 7.2
Ÿ IBM Tivoli Service Automation Manager 7.1 および 7.2
Ÿ IBM Tivoli Service Request Manager 7.1 および 7.2
© Copyright International Business Machines Corporation 2011. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA
ADP Schedule Contract with IBM Corp.
2012 年 4 月
ページ 2/ 43
目次
注意事項 ....................................................................................................................... 2
1
IBM Tivoli サービス マネジメント製品のパフォーマンス テストの重要性 .....................7
2
パフォーマンス ベンチマーク テストの目的の定義 ...............................................8
3
テスト方法の定義 ................................................................................................9
3.1
4
3.1.1
ベースライン測定 .................................................................................. 9
3.1.2
パフォーマンス ロード テスト ................................................................ 9
3.1.3
ストレス テスト .................................................................................... 10
3.1.4
耐久性テスト ....................................................................................... 10
3.1.5
サイジング テストと容量テスト ............................................................. 10
3.1.6
パフォーマンスのチューニングとデバッグ ............................................. 11
3.1.7
バッチ テスト ...................................................................................... 11
テスト ケース、作業負荷、およびシナリオ .......................................................... 12
4.1
テスト ケースの開発 ............................................................................ 12
4.2
作業負荷 ............................................................................................. 12
4.3
5
テスト タイプの定義 ............................................................................... 9
4.2.1
同時ユーザー数と同時に使用しているユーザー数 ............................... 13
4.2.2
リアルタイム対仮想ユーザー マッピング.............................................. 14
4.2.3
考える時間と遅延時間 ........................................................................ 14
テスト シナリオ .................................................................................... 15
ベンチマーク テスト環境の考慮事項 ................................................................. 16
5.1
アプリケーション サーバー ................................................................... 17
5.2
データベース サーバー ....................................................................... 17
2012 年 4 月
ページ 3/ 43
6
5.3
IBM Tivoli サービス マネジメント製品ビルド管理サーバー .................... 17
5.4
モニタリングの考慮事項 ....................................................................... 17
Rational Performance Tester に必要なテストの開発 .......................................... 18
6.1
6.2
ロード シミュレーション......................................................................... 18
6.1.1
ロード テスト コントローラー ................................................................ 18
6.1.2
ロード テスト ジェネレータ .................................................................. 18
6.1.3
ロード テスト データ ........................................................................... 18
テストの記録........................................................................................ 19
6.2.1
記録する前に ...................................................................................... 19
6.2.2
ワークスペース設定 ............................................................................ 19
6.2.3
レコーティング ..................................................................................... 19
6.2.3.1 キャッシング ........................................................................................ 19
6.2.3.2 トランザクション名 ................................................................................ 19
6.2.3.3 コメント ................................................................................................ 20
6.2.3.4 検索値の入力 ..................................................................................... 20
6.2.3.5 レコーディングを 2 つの バージョンに保存 ......................................... 20
6.3
新規レコーディングの編集 ................................................................... 20
6.3.1
テスト フロー ...................................................................................... 20
6.3.2
パラメーター ........................................................................................ 20
6.3.3
相関値................................................................................................ 21
6.3.4
正規表現の変更 ................................................................................. 21
6.3.5
条件コードでのデータ相関参照 ........................................................... 22
6.3.6
使わない参照の削除 .......................................................................... 22
6.3.7
テキストのチェック ............................................................................... 23
6.3.8
考える時間と遅延時間 ........................................................................ 23
6.3.9
セカンダリ イメージ ............................................................................. 23
6.3.10
カスタム コード ................................................................................... 23
6.3.11
参照の作成 ........................................................................................ 24
6.3.12
Maximo ページ シーケンス番号の処理 ............................................. 25
6.3.13
特殊な状況 ........................................................................................ 26
6.3.13.1 ポップアップ ウィンドウが表示される場合 ........................................... 26
2012 年 4 月
ページ 4/ 43
6.3.13.2 ポップアップの出現に一貫性がない場合 ............................................ 26
6.3.13.3 エラー メッセージ ボックスが表示される場合 ................................ 27
6.4
スケジュールを実行する ...................................................................... 27
6.4.1
システム クロック .................................................................................. 27
6.4.2
エクリプス設定 ...................................................................................... 27
6.4.3
エージェント設定 ................................................................................... 27
6.4.3.1 同一コンピューター上の複数のエージェント .......................................... 27
6.4.3.2 ワークスペースでの設定 ...................................................................... 28
6.4.3.3 Windows エージェント コンピューターでの設定 ................................... 28
6.4.3.3 Linux または AIX エージェント コンピューターでの設定 ..................... 29
6.4.3.5 エージェント選択 .................................................................................. 30
6.4.4 リソース モニタリング ............................................................................. 30
6.4.5 テスト ログ ........................................................................................... 30
6.4.6 統計とリソースのモニタリング間隔 .......................................................... 30
6.4.7 パフォーマンス要件 ................................................................................ 31
6.4.8 実行構成................................................................................................ 31
6.4.9 ユーザー コメント ................................................................................... 31
6.5
パフォーマンス結果 ............................................................................. 31
6.5.1 カスタム レポート ................................................................................... 32
6.5.2 パフォーマンス テスト結果の分析 ........................................................... 32
6.5.3 すべての時間範囲の比較 ....................................................................... 32
6.6
ワークスペースのその他の問題 ........................................................... 32
6.6.1 プロジェクトのクリーンアップ .................................................................... 32
7
パフォーマンス問題のトラブルシューティング ....................................................... 34
7.1
パフォーマンス問題の判別 ................................................................... 34
7.1.1 問題の判別テクニック ............................................................................. 34
7.1.2 問題の判別ツール .................................................................................. 35
7.2
システムのモニタリング ........................................................................ 37
7.2.1 モニタリング ﾂｰﾙ ................................................................................... 37
8
結果の分析 ........................................................................................................ 39
2012 年 4 月
ページ 5/ 43
9
Rational リソース ................................................................................................ 41
9.1
全般 .................................................................................................... 41
9.2
フォーラム ........................................................................................... 41
9.3
IBM サポート....................................................................................... 41
2012 年 4 月
ページ 6/ 43
1
IBM Tivoli サービス マネジメント製品の
パフォーマンス テストの重要性
よくある誤解に、顧客環境における IBM Tivoli サービス マネジメント製品のパフォーマン
ス テストは不要である。なぜなら製品は、IBM Tivoli パフォーマンス・拡張性チームによっ
て十分にテストされており、インストール時に最適なパフォーマンスが得られるように初期構
成されているから、というものがあります。
しかし、開発組織が実行する内部テストは、本番環境での条件を反映していなし可能性
があります。
内部テストでは、欠陥を発見し、製品が最大規模の組織に対応する拡張性を有しているかど
うかを調べ、各アプリケーションのパフォーマンス全体を調べることに重点が置かれていま
す。IBM Tivoli サービス マネジメント製品を本番環境に展開するお客様は、内部テストの結
果だけに依存するべきではありません。その代わりに、内部テストの結果をガイドラインとして
使用して、実際の本番環境で一般的なものとなるアプリケーションの組み合わせ、JVM の
数、ユーザー数、およびトランザクション数をサポートするのに必要となる最適な構成を判断
する必要があります。
本書は、お客様の環境で IBM Tivoli サービス マネジメント製品のパフォーマンス テスト
を実施するためのガイドラインを提供します。
ご自分でパフォーマンス テストを行う必要がある 4 つの一般的な理由：
Ÿ IBM Tivoli サービス マネジメント製品を新たに導入するためのサイズ見積りを
確認するため。
Ÿ IBM Tivoli サービス マネジメント製品が現在のビジネス処理の要件を満たすこと
ができるようにするとともに、既存のシステムのパフォーマンスを文書化するため。
Ÿ IBM Tivoli サービス マネジメント製品が将来の成長に伴うビジネス需要を満た
すことができるようにするとともに、組織がパフォーマンスのボトルネックを予測で
きるようにするため。
Ÿ 本番環境における現在のパフォーマンス問題を分析し、微調整し、デバッグする
ため。
ベ ス ト プ ラクテ ィス は 協 調 的 な 取 り組 み
本書は、IBM Tivoli パフォーマンス・拡張性チームと IBM Rational Performance Tester
エンジニアの中核グループとの協調的取り組みの結果として生まれました。本書は、お客様
の要望に応えるために作成されました。この共同作業は現在も進行しています。
2012 年 4 月
ページ 7/ 43
2
パフォーマンス ベンチマーク テストの目的の
定義
適切に定義された一連のパフォーマンス テストの目的は、どのようなパフォーマンス テスト
のプロジェクトにとっても、成功のために不可欠です。すべての要素を注意深く計画し、考慮
することは、すべてのプロジェクトの第一歩となります。失敗したプロジェクトの最もよくある理
由は、計画に費やした時間が少なすぎることです。
テストの結果によって答えが得られるビジネス上の質問事項を使って、テストの目的を定義し
てください。ビジネスの特定の質問事項に解答を与えるために、テストのすべての細部を設
計します。
以下に、取り扱う必要があるビジネス上の質問事項の例を示します。
Ÿ これが新規の展開の場合、展開されているアーキテクチャはビジネス要件を満た
しますか?
Ÿ これが新規展開の場合、IBM Tivoli サービス マネジメント製品は、特定の数の
同時ユーザーが、一定期間に与えられたトランザクション数を、現在配備されて
いるハードウェアで実行する場合に、満足できる応答時間を実現できますか?
Ÿ これが新規展開の場合、実行する予定の IBM Tivoli サービス マネジメント製
品に対して、また予定しているトランザクション量と同時ユーザーにとって、どのコ
ンポーネントがパフォーマンス全体のボトルネックになる可能性がありますか?
Ÿ これが既存の展開の場合、予定した数のトランザクションと同時ユーザーに対し
て、既存のハードウェアは受け入れられるパフォーマンスを供給するのに十分で
すか? あるいは、受け入れられるパフォーマンスを提供するために、新しいハー
ドウェアが必要ですか、または既存ハードウェアの再構成が必要ですか?
新規インストレーションを計画する場合、またはユーザー数の増加など、現在の IBM Tivoli
サービス マネジメント製品環境の変更を予定している場合は、アプリケーション全体をテスト
するために読み込む必要があります。ストレス テストおよび安定性テストは、本番環境に対し
て製品を構成する前に実行します。ただし、時間、費用、その他の制約のために、この種のテ
ストは必ずしも可能であるとは限りません。そのため、リスクや見返りが最も大きいビジネス上
の質問事項を特定し、それに応じてテストすることが重要になります。
プロジェクトのテスト プランで、対処するビジネスの質問事項とともに、テストの目的を文書化
します。テストが完了したら、テスト レポートで、ビジネスの各質問事項に対する簡潔な答えを
提供できるようにします。
2012 年 4 月
ページ 8/ 43
3
テスト方法の定義
3.1
テスト タイプの定義
実行するテストのタイプは、質問するビジネス質問事項によって決定されるようにします。次
のテスト タイプは、IBM Tivoli サービス マネジメント製品のパフォーマンス テスト プロジェ
クトで一般的に実施されます。独自のビジネスの質問事項により、その他のテストが必要に
なる場合があります。
3.1.1 ベースライン測定
他のテストを実行する前に、ベースライン測定を行います。ベースライン測定は、繰り返して
実行されるシングルユーザー テストで構成されます。このテスト タイプの目的は、テストが
予期したように機能しているか確認し、1人のユーザーが使用している場合でもうまく機能し
ていないアプリケーションの局面を特定できるようにすることです。この状況でアプリケーショ
ンが要件を満たしていない場合は、その問題を解決してから、より多くのユーザーを使ってそ
の他のテストを試みる必要があります。この不具合を除去するため、ハードウェアとソフトウェ
アの再構成が必要になる場合があります。
一連のシングルユーザー ベースライン測定を完了して、満足できる結果が得られたら、
“benchmark-under-load” テストを実行します。この種のテストでは、テスト スクリプトは本番
環境で予想される総アクティビティのサブセット (25% など) をシミュレートします。最初のテ
ストと同様に、アプリケーションのパフォーマンスに問題がある場合は、その問題を解決して
から、より大きなロード レベルを使ってその他のテストを実施する必要があります。
状況によっては、単一機能フローのシナリオをスケジュールすると役立つ場合があります。こ
のような状況の 1 つに、パフォーマンス テストが機能安定のカスタマイゼーションの実現と
同時に行われ、作業負荷の混合に含まれる前に、カスタマイゼーションがどのように行われ
るかを見たい場合があります。別の状況としては、混合モードのシナリオでパフォーマンス問
題が特定された場合が考えられます。パフォーマンス問題を特定の機能フローから分離する
には、単一機能フロー テストの実行が必要な場合があります。
3.1.2 パフォーマンス ロード テスト
ベースラインおよびベンチマークアンダーロード テストを完了すると、ロード テストの一式を
開始できます。これらのロード テストについて、IBM Tivoli パフォーマンス・拡張性チーム
は、次の少なくとも 5 つのロード ポイントの実行を推奨しています： 予想されるシステム ロ
ードの 50%、75%、100%、125%、および 150% をシミュレートする。この 5 つのロード
ポイントは、パフォーマンス曲線の「屈曲点」を特定するのに役立ちます。各ロード ポイント
は、個々のテストとしてテストを行うか、複数のロード レベルを提示する単一テストから 5 つ
のロード ポイントすべてを操作するため、パフォーマンス テスト ツールを使用してオプショ
ンをスケジュールすることができます。各方法には、それぞれ長所と短所があります。各ロー
ド ポイントを水平にして、次のロード ポイントに拡大縮小する前に、はっきりと観察できる長
さの期間の間、一定のユーザーロード/トランザクション率のままにすることができます。
ロード テストの目的は、トランザクションの応答時間を測定することであり、ロード条件の下
でビジネス要件やサービス レベル契約が満たされることを確認することです。またロード テ
ストは、明示されない可能性のある機能の欠陥を見つけることができます。トランザクション
の成功と失敗率をモニターすることにより、アプリケーションが予定どおりに機能しているかど
うかを調べるとともに、機能問題を起こす可能性のあるボトルネックを特定できます。
2012 年 4 月
ページ 9/ 43
ロード テストの設計は、テスト結果を理解して、最適パフォーマンスのために環境を調整する
上で重要なものとなります。下手に定義された作業負荷やテスト方法は、テスト結果に強い
影響を及ぼし、誤った結果を導く恐れがあります。
3.1.3 ストレス テスト
ロード テストでは、アプリケーションを使用する実際のユーザーの条件に近似したシミュレー
ションを使用して、ソフトウェアのパフォーマンスをテストすることに重点が置かれています。
一方、ストレス テストでは、障害が発生するときのサーバーの中断点と、アプリケーションの
動作のしかたを特定することに重点が置かれています。IBM Tivoli サービス マネジメント製
品のカスタマイズした展開は、テスト候補としてストレス テストに適しています。
ストレス テストでは、サーバーが中断するまで、同時ユーザー数を徐々に増やしていきま
す。ロード テストとは異なり、ストレス テスト時の「考える時間」やブラウザー キャッシュを考
慮する必要はありません。ストレス テストの所要時間はあらかじめ定められていません。す
べてのサーバー リソースが使い尽くされる時点まで、同時ユーザーを徐々に増やしていきま
す。ストレス テスト中にサーバー リソースをモニターし、障害が発生した後でシステム ログ
を分析して、障害を発生した条件を特定します。ストレス テストの結果は、システムが極端な
ロードの下で安定した状態を保つかどうか、パフォーマンスが劣化するかどうか、またはシス
テムがクラッシュするかどうかを示します。
システムにストレスにさらされると、お客様の環境に大きな影響を与える可能性があるため、
ストレス テストに続いて、プロジェクトの設計者と実装者による結果の詳細な分析を行う必要
があります。
3.1.4 耐久性テスト
耐久性テストは、ロード テストやストレス テストと異なります。耐久性テストは、かなりの数の
同時ユーザーが長時間に渡って実行する場合に、アプリケーションの動作を検査します。耐
久性テストの目的は、メモリー リーク、時間の経過によるパフォーマンスの劣化、およびシス
テム全体の安定性を調べることです。耐久性テストは一般的に、12 時間から 1週間の時間
範囲で実行されます。
耐久性テスト時にモニターする主な指標には、一貫したトランザクション応答時間、安定したメ
モリー使用、安定した CPU 使用率、一定したスループット レベル、サーバー クラッシュの
回避があります。
3.1.5 サイジング テストと容量テスト
サイジング テストと容量テストは、新規展開の適切なサイズを決定し、既存の環境が予想さ
れるシステム ロードの増加を吸収できるかどうかを調べるため、展開チームがテスト結果を
必要とする場合に重要になります。
IBM Tivoli サービス マネジメント製品では、サイジング テストの結果は一般的に JVM 当
りの同時ユーザー数、およびサーバー当りのトランザクション レートとして報告されます。
サイジング テストと容量テストは、標準のパフォーマンス テストとは異なるやり方で設計しま
す。各階層とともに、その階層の個々のコンポーネントに焦点を合わせて一連のテストを設計
することが重要です。たとえば、与えられた作業負荷に対する JVM 当りの最大同時ユーザ
ー数を調べるには、JVM 自体が限定要因となるようにする必要があります。これを実現する
1 つの方法は、CPU がその制限に達するかなり前に JVM が容量に達するように、システ
ム上の JVM の数を制限することです。JVM の能力を決定したら、JVM のカウントを増や
してボトルネックにならないようにし、CPU がボトルネックになるようにします。CPU が使用
率 100% になるまで同時ユーザー数を増やし続けます。その時点が、CPU 当りの同時ユ
ーザーの最大数として報告されます。各階層のすべてのコンポーネントが完全に特徴付けら
れるまで、この方法を続行します。
2012 年 4 月
ページ 10/ 43
コンポーネントと階層に加えて、IBM Tivoli サービス マネジメント製品のさまざまな組み
合わせを同じ方法でサイジングすることができます。各アプリケーションの各階層内のそ
れぞれのコンポーネントの特性を確立したら、さまざまなアプリケーションの統合された
テストを実行して、結果に別の次元を追加します。これは、アプリケーションの組み合わ
せが期待どおりに展開されるように、サイジングの「経験則」の評価に使用できる追加の
データを提供します。
3.1.6 パフォーマンスのチューニングとデバッグ
IBM Tivoli サービス マネジメント製品システムでのハードウェア リソースのクリエイティブ
な操作により、ボトルネックをコントロールできます。たとえば、JVM メモリーがボトルネック
であると判断した場合、1 つのサーバー クラスターで単一の JVM のみを起動すれば、
デバッグとチューニングはより簡単に、素早く行えるでしょう。そんなふうに、より小さなロー
ドで問題を再現することができます。
特定の使用ケースが期待通りに動作しない場合は、その使用ケースだけをテストし、消費さ
れたリソースを見抜き、より深い分析を行う上で役立つことがよくあります。その他のトラフィッ
クを制限すると、トレースやログをより簡単に調べることができます。
ログ、トレース、デバッグの詳細については、System Administrator Guide
を参照してください。
最新の IBM Tivoli サービス マネジメント製品のチューニング情報については、以下を参照
してください： Best Practices for System Performance 7x white paper.
3.1.7 バッチ テスト
バッチ テストは、インタラクティブではない IBM Tivoli サービス マネジメント製品のコンポー
ネントをテストします。バッチ テストは、IBM Tivoli サービス マネジメント製品のパフォーマ
ンス分析において重要な役割を果たすので、 除外しないでください。お客様展開時のデータ
ロード、外部ベンダーとの統合、および Integration Framework などのツールは、ミッドウェ
アとデータベース サーバーの両方に大きな影響を及ぼす可能性があります。
バッチ テストでは、サーバー階層とスループット レートのシステム リソースの消費に重点が
置かれます。必要に応じて、応答時間の SLA も検討します。このテスト方法では、シミュレ
ートするレコードのタイプ、メッセージのサイズ、およびトランザクションのフィード レートを明
確に定義します。テストの設計を間違えると、結果が大幅に異なる恐れがあります。
バッチ テストでは一般的に、標準的なパフォーマンス シミュレーション ツールを使用せず、
ある程度のプログラミング作成が必要になります。実装者、設計者、またはシミュレートされる
コンポーネントに精通した人と協力することが重要です。
2012 年 4 月
ページ 11/ 43
4
テスト ケース、作業負荷、およびシナリオ
4.1
テスト ケースの開発
パフォーマンス テストのテスト ケースを検討する場合は、テストされる使用ケースの数をで
きる限り少なくしますが、 ケースには、最も頻繁に使用される機能や、最も高いリスクを示
す機能を含める必要があります。パフォーマンス テストの目的は、機能テストの目的とは異
なります。機能テストでカバーされるレベルと同じレベルのパフォーマンス テストは、しばし
ば実行できないことがあります。これは、使用ケースからのパフォーマンス テスト スクリプト
の作成には時間がかかり、多くの労力を必要とするためです。最も頻繁に使用されるシナリ
オの 20% をテストすることに焦点を合わせます。シナリオの残りの 80% への取り組み
は、一般的にパフォーマンスに大きな改善をもたらしません。ある使用ケースのパフォーマ
ンス テスト スクリプトの目的は、最も一般的なユーザー フローを代表することであり、機能
テストでの場合のように、すべてのボタンを押すことでも、すべてのオプションを有効にする
ことでもありません。
これがアプリケーションのための初めてのパフォーマンス テストでない場合は、以前のパ
フォーマンス ベンチマークや既存の本番データをリリース間の結果を比較するための入
力として使用します。
テストでのログオンとログオフを構造化して、それらが本番環境で使用される方法と一致させ
ます。エンドユーザーが一般的に午前中に 1 回ログオンして、その接続を一日中維持する
場合は、スクリプトはその行動パターンを反映する必要があります。エンドユーザーが一般的
にログオンして、仕事を行い、その後にログオフする場合は、スクリプトはその行動パターン
を反映する必要があります。特定のログオンやログオフの使用ケースが必要な場合は、その
ケースのスクリプトを追加して、そのトランザクションが作業負荷の混合によってコントロール
され、測定されるようにします。
4.2
作業負荷
有効な作業負荷を作成することが課題となります。作業負荷は通常、プロダクション システ
ムからの履歴データ、ライブ システムのデータベース クエリー、およびアプリケーション サ
ポート要員との聞き取り調査を組み合わせて決定されます。作業負荷は、作業負荷分布と
作業負荷レートの 2 つの要素で構成されます。作業負荷分布は、テスト シナリオにあるす
べての使用ケースの混合割合です。作業負荷レートは、トランザクション レートにより決定さ
れます。たとえば、トランザクション数 x として、または月単位で作成された所定のタイプとし
て、さらにピーク時間に対して推定されます。
ユーザーの 20% が作業オーダーを作成することが分かるだけでは不十分です。作業オー
ダーが作成される割合を知る必要もあります。たとえば、時間当たりに作成される作業オー
ダーは 20 ですか、それとも 100 ですか?
2012 年 4 月
ページ 12/ 43
Scenario
S01
S02
S03
S04
S05
S06
Scenario description
Simple Search
Advanced Search
Simple Create
Advanced Create
Simple Close
Advanced Close
Weight factor
20%
10%
30%
20%
10%
10%
100%
サンプル作業負荷分布
Average Hourly Transaction Rates Peak Hour
S01 – Simple Search
2000
S02 – Advanced Search
650
S03 – Simple Create
900
S04 – Advanced Create
750
S05 – Simple Close
1700
S06 – Advanced Close
2000
Totals
8000
サンプル作業負荷トランザクション レート
テスト タイプやテストの目的に応じて、テスト プロジェクト中に複数の作業負荷を含めるこ
とができます。最も一般的な作業負荷タイプは、ターゲットの本番環境でのピーク時間の同
時ユーザー数とトランザクション数をシミュレートします。
実施用のテスト シナリオを作成する際に、シミュレートされる同時ユーザー数は定義された作
業負荷混合に従う必要があります。シミュレーション時の時間当たりのトランザクション レート
は、作業負荷混合を導くために行った分析に対応させてください。このレートは、ユーザー当り
の秒単位のトランザクション数、ユーザー当りの分単位のトランザクション数、またはユーザー
当りの時間単位のトランザクション数として報告することができます。
4.2.1 同時ユーザー数と同時に使用しているユーザー数
同時ユーザー数と同時に使用しているユーザー数の正しい数値を知ることは、アプリケー
ションのパフォーマンス テストにとって不可欠です。テストでは、同時ユーザー数と同時に
使用しているユーザー数を区別する必要があります。同時ユーザー数は、アプリケーショ
ンとのセッションをアクティブにしているユーザー数ですが、これにはアイドル状態のセッシ
ョンも含まれます。同時に使用しているユーザー数は、所定の時間に実際に作業を行って
いるユーザー数です。結果を分析する場合は、この区別が重要になります。
「同時ユーザー数」と「同時に使用しているユーザー数」の用語は厳密に定義されている
わけではありません。ある Web サイトの同時ユーザー数は 150 人であると言われた
場合、150 のリクエストが同時に処理されるものと想定することはできません。これは、
150 人のユーザーがその Web サイトにログオンしており、そのページと盛んにやり取り
を行っていることを意味しますが、 実際には、ユーザーの多くはページを読んだり、考え
たり、あるいは応答を入力しているため、同時にサーバーにロードすることはありません。
2012 年 4 月
ページ 13/ 43
4.2.2 リアルタイム対仮想ユーザー マッピング
シミュレートした仮想ユーザーを同等のリアルタイム ユーザーにマッピングして、現実的なロ
ード レベルを提供することは重要です。リアルタイムの使用履歴 (たとえば、アプリケーショ
ンのバージョンが既に本番環境にある場合など) があるアプリケーションについては、ピーク
トラフィック時のサーバー ロード (秒単位で処理されたリクエスト) を、パフォーマンス テスト
時にサーバーで生み出されたサーバー ロードと比較する必要があります。これにより、パフ
ォーマンス テスト時にシミュレートされたロードが実在のロードを代表しているか確認できま
す。テスト スクリプトでの考える時間を調整して、サーバーの適切なロードを作り出します。
詳細については、「考える時間と遅延時間」を参照してください。サーバー ロードを分析する
際に検討する 2 つのものは、秒単位のリクエスト数とアクティブなユーザー数です。
サーバーとアプリケーションが接続、ライブ維持設定、およびその他の作業負荷条件に関係
するリソースを処理する方法に応じて、2n ユーザーではなく n ユーザーを持ったリクエスト
と同じレートを生成すると、サーバーに大幅に異なるパフォーマンス ロードが生じる可能性が
あり、合計サーバー容量とクライアント応答時間に影響を及ぼします。これを明らかにするに
は、現実に開かれた接続数、およびその他の関連するアプリケーション リソース (セッション
数など) をモニターして、それらをパフォーマンス テスト時にシミュレートしたサーバー ロード
と比較します。サーバーおよびアプリケーションが与えられたリクエスト レートのユーザー数
に問題があるかどうかを調べるために、試験ランを実行できます。問題がなければ、無視で
きます。
秒単位のリクエストは、サーバーにより処理されたロードを測定する上で、より粒度の高い適
切な単位です。サーバーによって処理されるユーザー数は、ビジネス利害関係者に報告され
るメトリックです。パフォーマンス テスターは、サーバーによって処理されるリクエスト数に重
点を置く必要があります。
4.2.3 考える時間と遅延時間
「考える時間」は、ユーザーが考えるために使ったり、アプリケーションの別のページへ移動
するために使う時間です。テスト戦略を決定する際に考える時間を考慮します。
ユーザーの考える時間は、ユーザーが使用するアプリケーションの部分に応じて異なりま
す。ロード テストを実行する際に、構成された考える時間にランダム化係数を適用します。パ
フォーマンス テスト ツールは、テストの実行時に考える時間をランダム化するためのメカニ
ズムです。ツールは、インタラクションの間のこの一次停止を表すために、「think time (考え
る時間)」や「delay time (遅延時間)」などの用語を使用します。
Rational Performance Tester には「think time (考える時間)」および「delay time (遅延時
間)」の両方のコンセプトがあります。それらが記録されると、両方がテストに追加されます。
遅延時間は、さまざまなページ要素の間で固定された時間量です。考える時間は、アクション
間のユーザーの一時停止時間です。IBM Tivoli パフォーマンス・拡張性チームは両方の変
数を操作します。
ランダム化を導入するもう一つの方法は、ループ コントロール機能を設定してテストの各反
復をランダム化することです。IBM Tivoli パフォーマンス・拡張性チームはこれを使用して、
テスト時に予測したトランザクション レートが実現されるように、ユーザー当りの秒単位のトラ
ンザクション数をコントロールできます。ループ コントロール機能を使用する場合は、記録し
た考える時間を使用するようにスケジュールを設定するといいでしょう。これにより、ループ
コントロールがランダム化を提供します。ただし、実際のユーザーをより良くモデル化するに
は、一般的には両方を使用すべきです。
考える時間はサーバー ロードに影響します。考える時間を減らすと、サーバー ロードが増
えます。考える時間を増やすと、サーバー ロードが減少します。適切な考える時間を計算す
るには、ユーザー当りの秒単位の望ましいトランザクション数を知る必要があります。
2012 年 4 月
ページ 14/ 43
考える時間は、測定されるトランザクションの開始および終了以外のスクリプトに配置されるよ
うにします。そうでない場合は、考える時間はトランザクション応答時間の結果に含まれます。
Rational Performance Tester には、トランザクションに関連付けられた時間を測定する経過
時間 (時刻) とネット サーバー時間の2つのメトリックがあります。ネット サーバー時間は、
考える時間とその他の処理時間 (カスタム コード実行時間、および通常のクライアント・サー
バー応答時間に関連付けられていない参照収穫時間など) を除いた、ページの全応答時間
の合計と考えることができます。
4.3
テスト シナリオ
比較的少ないシステム リソースを使用して開始するテスト シナリオを設計し、その後でリソー
ス使用を徐々に増やしながら安定したピーク レベルに達するようにして、さらにリソース使用
を減らしていきます。安定した期間では、ターゲット ユーザー ロードは、現実的な考える時間
を使って、システムでさまざまなオペレーションを実行する必要があります。メトリックは、増加
時や減少時ではなく、安定ピーク時に取得する必要があります。十分なデータ サンプルを収
集してから、応答時間のメトリックについて結論を出します。任意の時点で応答時間が速くな
ったり遅くなったりする場合は、外部的な理由が存在する可能性があります 90パーセント台
の応答時間を使用した応答時間メトリックのレポートは、応答時間の急上昇を排除するガイド
ラインとなります。
2012 年 4 月
ページ 15/ 43
5
ベンチマーク テスト環境の考慮事項
パフォーマンス テスト環境は多くのコンポーネントにより構成されます。プロジェクトの計画段
階で、各コンポーネントを検討します。本番システムのミラー イメージが理想的ですが、利用
できない場合がよくあります。そのため、各コンポーネントに特別の注意を払って、テスト環境
から推定できる事柄を本番環境に適用できるようにします。対象とする本番環境を包括的に
理解することは、テスト環境を計画する上での前提条件となります。
テスト環境には、少なくとも次の機能が必要です：
Ÿ 本番環境と同じ全体的アーキテクチャ：
o
同じオペレーティング システムとミドルウェアのプラットフォーム。たとえば、
本番システムが VMs、AIX, DB2 などを使用している場合は、テスト構成も
これらを使用します。
o
同様の階層、ハードウェア比率、およびトポロジー。たとえば、アプリケー
ション サーバーに同じ数の JVM を使用し、同じ分散型データベースと
アプリケーション サーバーなどを使用します。
o
統合フレームワークと cron 設定に同じ構成：
たとえば、ユーザー インターフェースに使用される JVM と同じ物理サーバ
ーで、専用の JVM に対して専用のサーバーを使用します。
Ÿ ソフトウェア スタック バージョンを合わせる。つまり、オペレーティング システ
ム、ミドルウェア、および IBM Tivoli サービス マネジメント製品の同じバージョ
ン。
Ÿ データベースでの同等のデータ ボリュームと分配。
Ÿ 同じサーバー構成。たとえば、両方の環境で SSL を使用し、両方に同じ
maximo.properties ファイルがあり、両方に同じセキュリティ レイヤーがある
(ポリシー、ファイアウォール ルールなど)。
本番環境の特徴にしっかりと合わせないと、結果をテスト環境から本番環境へ正確に関連付け
ることができず、CPU やメモリーの消費がそれら 2 つの環境で異なる可能性があります。
本番環境とテスト環境で、サーバー マシンのシステム構成詳細を必ず特定します。CPU
数、CPU 性能 (クロック スピード)、RAM 容量、ディスク容量、ディスク上の使用可能な空
き容量、NIC カード容量、およびネットワーク帯域幅を特定します。パフォーマンス テストを
スケジュールする前に、これらの詳細を特定し、テスト計画書に文書化します。
パフォーマンス テストに成功するには、専用のテスト環境が必須となります。ランダムなアプ
リケーション トラフィックや不良プロセスはパフォーマンス結果をゆがめ、テストに混乱や相
違が生じる恐れがあります。サーバーとネットワーク コンポーネントはどちらも専用のリソー
スにすべきです。テストの主な注目点に帯域幅のテストが含まれている場合は、ネットワーク
を分離することが重要です。これは、LAN 上の全般的なトラフィック (テストによって生じるト
ラフィック以外) がテスト結果に影響を及ぼす恐れがあるためです。
2012 年 4 月
ページ 16/ 43
テスト環境を初めて構成する場合は、システム パフォーマンス ガイドラインのベスト プラク
ティスをハードウェアやソフトウェアに適用します。テスト プロセス時に行ったすべての変更を
文書化してください。
5.1
アプリケーション サーバー
特定のアプリケーションのチューニングやデバッグのテストに焦点を合わせていない場合は、
実行する標準的なロード テストに、本番システムで使用されるすべてのアプリケーションとプ
ロセスが含まれるようにします。包括的なテストは、パフォーマンス全体に対する期待を確認
する唯一の方法です。
IBM Tivoli サービス マネジメント製品の最新のチューニング情報については、次を参照して
ください： Best Practices for System Performance 7x white paper.
5.2
データベース サーバー
パフォーマンス テストの準備をする場合は、テスト データベースに十分なデータがある必要
があります。データベースに含まれているレコードが 100,000 レコードではなく、1,000 レコ
ードの場合には、SQL クエリーの実行時間は大幅に短くなる可能性があります。本番のデ
ータベースにテストされるものより大きいデータ ボリュームがある場合は、本番環境でのデ
ータベース パフォーマンスはテスト環境より大幅に低下する可能性があります。
テスト中にデータを使用できるように、テスト データベースに代表的なデータ量が存在するよ
うにします。テーブルでのレコードの配列方法やインデックスの付け方は、パフォーマンスに
影響を与えます。データベース メンテナンス ユーティリティを実行してから、データベースの
バックアップを作成します。テストの再現性を可能にするため、各テスト ランの前に、バックア
ップを使用して同じ状態にリストアします。
IBM Tivoli サービス マネジメント製品の最新のチューニング情報については、次を参照して
ください： Best Practices for System Performance 7x white paper.
5.3
IBM Tivoli サービス マネジメント製品ビルド
管理サーバー
パフォーマンス テスト時に、プロパティ ファイルの値を調整して、テストを展開するために複数
の EAR ファイルを構築したい場合があります。前の構成に戻す必要がある場合に備えて、変
更する可能性のあるファイルのコピーをとっておきます。行った変更は、文書化します。
5.4
モニタリングの考慮事項
一部のモニタリング ツールはシステムのパフォーマンスに影響を与える恐れがあります。パ
フォーマンスへのモニタリング ツールの影響を最小限にするため、モニターする対象を精選
します。サンプリング間隔の設定が小さすぎても、パフォーマンスに悪影響を及ぼす可能性
がありますが、間隔の設定が大きすぎると、潜在的なボトルネック状況を見逃す恐れがあり
ます。モニタリングをオンにしたときの結果と、モニタリングをオフにしたときの結果を比較し
て、モニタリングの影響を評価することは有効な実践法です。パフォーマンスのボトルネックを
探す場合は、モニタリング レベルの増加が必要になる場合があります。ただし、正式な結果
でない場合には、結果が有効になるように、必要なものにのみモニタリング レベルを下げる
といいでしょう。
2012 年 4 月
ページ 17/ 43
6
Rational Performance Tester に必要なテ
ストの開発
6.1
ロード シミュレーション
Rational Performance Tester などのロード テスト ツールには、一般的に次の 2 つの部
分があると考えられます：
Ÿ ロード テスト コントローラー。これは、必要なロードを作成し、操作するために使
用します。
Ÿ ロード テスト ジェネレーター。これは、実際のロードをサーバーに送信します。
シミュレートする予定の仮想ユーザーの数に応じて、ロード テスト コントローラーとロード テ
スト ジェネレーターは同じハードウェアに常駐できる場合があります。ハードウェアを専用に
する必要がある場合と、共有できる場合についての指針は、Rational Performance Tester
のマニュアルに記載されている場合があります。
6.1.1 ロード テスト コントローラー
ロード テスト コントローラーは、ワークベンチまたはワークスペースと呼ばれることがありま
す。Rational Performance Tester は、ワークベンチとしてロードを実行するコンピューター
を、またワークスペースとしてテストとスケジュールのコンテナを参照します。
6.1.2 ロード テスト ジェネレーター
ロード テスト ジェネレーターは、一般的にエージェントまたはドライバーと呼ばれ、いくつか
のシステムにインストールしてロードを分散することができます。1000 ユーザーのテストを実
行するには、複数のコンピューターにエージェントをインストールできます。各エージェントは、
仮想ユーザーのパーセンテージを作成するように構成できます。各エージェント コンピュータ
ーのリソース使用率は 70% 未満に保ちます。エージェント コンピューターのスループット
は、ネットワーク インターフェースの容量より適度に下に保ちます。これらのガイドラインのい
ずれかを超えると、結果が影響を受ける可能性があります。異なるそれぞれの IP アドレス
に作成されるユーザー ロードは、テスト中のサーバーに送信されます。ロード テスト コント
ローラーから、各ロード テスト ジェネレーターによって生成されるロードは、それを表示する
と集計されます。デフォルトでは、各ジェネレーターによって収集された個々の結果は、集計
の後で効率を良くするために廃棄されます。個々の結果を見るには、スケジュールの Only
Collect All Hosts Data (すべてのホスト データのみ収集) 統計フラグを消去します。それに
より、個々の結果が保持され、見ることができます。
6.1.3 ロード テスト データ
テスト データの複雑さに応じて、パフォーマンス テスト エンジニアまたはデータベース管理
者はデータを読み込むことができます。可能な場合は、本番システムのデータベース ダンプ
を使用してテスト データベースに読み込むことができます。データを生成して、Rational
Performance Tester データプールを作成するために、クエリーの記述が必要になる場合が
あります。このデータプールには、Rational Performance Tester のテストを実行する仮想ユ
ーザーによって使用されるデータが含まれます。
2012 年 4 月
ページ 18/ 43
6.2
テストの記録
6.2.1 記録する前に
テストを記録する前に、行う手順を文書化します。たとえば、フィルターにテキストを入力した
後で、次のフィールドに移動するか、Return キーを押しますか、それとも双眼鏡アイコンをク
リックするか、など。トランザクションの名前を定義して、複数のテストを含んだスケジュールを
実行する場合に、正しい順序でページ/トランザクション名が表示されるようにします。便利な
フォーマットは、<スクリプト名>_<ステップ番号>_<ステップ説明> です。例、
AM01_01_Login, or AM01_05_EnterStatusWAPPR.
6.2.2 ワークスペース設定
不要な自動データ相関関係を減らすには、ワークスペースの環境設定を変更します。
Rational Performance Tester を開き、「Windows」 > 「Preferences」 を選択します。左ペ
インで 「Test」 を展開し、続いて 「Test Generation」 および 「HTTP Test Generation」 を
展開します。右ペインで 「Data Correlation」 タブを選択します。「Optimize automatic data
correlation for execution」 を 「Efficiency」 に設定します。
また、ヒープ情報をステータス ラインに表示するよう環境を設定するため、「Windows」 >
「Preferences」 > 「General」 を選択し、「Show heap status」 を選択します。
6.2.3 レコーディング
6.2.3.1 キャッシング
Rational Performance Tester Release 8.2.1 には、新機能のページ キャッシュ エミュレー
ションが導入されています。サーバーがキャッシュに転送するすべての静的コンテンツ (最後
の変更または年齢) はエミュレーションによって処理されます。ページ キャッシュをエミュレー
トする機能は、テスト内のキャッシュのみを検討します。ユーザーがテストを終了し、それを再
実行すると、キャッシュは再ロードされます。以前のパフォーマンス テスト ペーパーでは、
IBM Tivoli サービス マネジメント製品はパフォーマンス テストの MaxAge フィルターを無
効にすることを推奨していましたが、現在では有効のままで Rational Performance Tester
でのキャッシュの使用に適するようになっています。そのため、MaxAge フィルターを有効の
ままにすることを推奨します。これは、IBM Tivoli サービス マネジメント製品をインストール
すると、デフォルト設定で有効になります。
レコーディングを開始する準備ができたら、レコーディング アイコンをクリックして、HTTP test
を選択します。レコーディングの前に、ブラウザーのキャッシュをクリアします。テストを再レコ
ードする必要がある場合は、次のレコーディングの前にもキャッシュをクリアします。
レコードされたページ数を書き留めて、それを期待したページ数と比較します。一部のアクシ
ョンは複数のページにレコードされます。必要に応じて、スクリプトを再レコードして、前のレコ
ーディングを上書きし、複数のページが考えられるレコーディングにコメントを配置します。
6.2.3.2 トランザクション名
レコーディング中に、一部のページに名前を付けます。名前はレコードされたページに適用さ
れます。この時、複数のページにレコードされたページには名前を付けないでください。テスト
をクリーンアップするときに、混乱を起こす場合があります。残りのページは、レコーディング
が完了してからエディターで名前を付けることができます。
2012 年 4 月
ページ 19/ 43
6.2.3.3 コ メ ン ト
レコーディング中に、コメントを入力します。コメントは、レコードされる次のアクションの前に来
ます。一部のステップは複数のページにレコードされるため、コメントはレコードされたテストを
理解する上で不可欠なものとなります。テストに注釈を付けて、分かりやすさを向上するもう
一つの方法は、Rational Performance Tester のスクリーンショット機能を使うことです。画
像は、オペレーションが実行されている時のアプリケーションの状態を伝える最適な方法にな
ります。
6.2.3.4 検索値の入力
アイテム番号や資産番号などの特定の値を持った検索をレコードする場合は、ファイルター
で値の前に等号 (=) を付けます。ワイルドカードで検索を行う場合は、文字列の後または前
にパーセント記号 (%) を付けます。
6.2.3.5 レコーディングを 2 つの バージョンに保存
すべてのステップが記録されたら、ブラウザーを閉じてレコーディングを終了します。「Save
As」(名前をつけて保存) を使用してスクリプトを別名で保存し、コピーしたファイルですべて
の変更を行います。これは、レコードされたテストを見るために、変更していない元のスクリプ
トに戻るときに必要になります。
6.3
新規レコーディングの編集
6.3.1 テスト フロー
複数のページにレコードされたステップがあり、アクションを区別する明確な方法がない場合
は、ページをマージすることができます。これを行うには、ページを強調表示して右クリックし、
「Merge Pages」(ページをマージ) を選択します。最初のページを送り先として選択します。
最初のページに名前が付いている場合は、もう一度名前を付ける必要があります。
また、レコードされたページを複数ページに分割しなければならない場合もあります。
レコーディング中に名前が付けられなかったページに名前を付けるには、ページの上にカー
ソルを置いて、Test Element Details (テスト要素の詳細) セクションの Page Title (ページ
タイトル) フィールドを編集します。
必要に応じてコメントを追加して、実行されたアクションがスクリプトを見る人に分かるようにし
ます。Add (追加) をクリックして、Comment (コメント) を選択し、強調表示したページの最後
のページ要素の後にコメントを追加します。Insert (挿入) をクリックして、Comment (コメント)
を選択し、強調表示したページの上にコメントを挿入します。
一般的なユーザーは、実行される各主要アクション間でログインやログアウトを行わないた
め、go_to_application か ら return_to_start_center までを囲むループを配置します。ま
た、next page/screen pages など、他の繰り返されるアクションにループを配置することもで
きます。
6.3.2 パラメーター
Rational Performance Tester は URL からホスト番号とポート番号を取得し、それらのほ
とんどをテスト変数の HOST および PORT にパラメーター化します。レコーディング時に
ポート番号が指定されていない場合は、デフォルトのポート番号 80 が使用されます。スケ
ジュールに複数のテストがあり、レコードしたものとは異なるホストに対してテストを実行する
予定の場合は、各値用の 2 つの列を持った datapool ファイルを作成します。datapool の
ポート列は空白にできません。
2012 年 4 月
ページ 20/ 43
スクリプトが検索の結果ではない特定のアイテムに対してアクションを実行する場合は、その
アイテムの番号をテスト変数か datapool のいずれかでパラメーター化する必要がありま
す。複数ユーザーがスクリプトを実行する場合は、ユーザー ID とパスワードの datapool
を作成します。
datapool をテストに追加する場合は、プロパティを設定するときにそれらがどのように使用され
るか検討します。datapool のオプションについては、オンライン ヘルプを検索してください。
datapool をテストに追加したら、datapool フィールドを指し示すようにテスト変数を変更します。
6.3.3 相関値
Rational Performance Tester に IBM Tivoli サービス マネジメント製品のスクリプティング
を成功させるには、uisessionids を相関させ、動的 UI 値 (MXid 値) を相関させることが
重要です。
Rational Performance Tester は多くの値を相関させる良好なジョブを行いますが、一般に
は相関させる他の多くの値があります。
レコーディング環境設定を Accuracy の代わりに Efficiency に設定することは、IBM Tivoli
サービス マネジメント製品のセッション id にとって非常に重要です。環境設定が Accuracy
に設定されており、何らかの理由でページが失敗すると、次のセッション id 相関関係は通常
失敗し、一つの失敗が別の失敗をもたらすように、残りのページの失敗を引き起こします。環
境設定が Efficiency に設定されている場合は、ログインにあった最初のセッション id を使
用します。
実行している IBM Tivoli サービス マネジメント製品のバージョンに応じて、すべての MXid
値を相関させる必要がない場合があります。IBM Tivoli サービス マネジメント製品バージョ
ン 7.5 以降を実行しており、静的 MXids (update maxpropvalue set propvalue='true' where
propname='mxe.webclient.staticid') を使用している場合は、大半の Mxids を相関させる必
要はありません。
Rational Performance Tester と IBM Tivoli サービスマネジメント製品の最近のバージョン
では、一部の MXid 値は自動的に相関されます。
テストの上部をクリックしてから、「Display Data Correlations」(データ相関を表示する) 表示
ボタンをクリックします。Datapool Candidate (データプール候補) (デフォルトでは緑のフォン
ト色) と記された各アイテムを見直します。相関が必要なものを調べるために、名前と値を検
討します。Most values named targetid および value と名付けられた大半の値は、
mx#### の形式を持っていれば、相関させる必要があります 静的 MXids を使用する場合
は、相関する値の形式は長くなり、イニシャル mx の後に英字と数字の両方の値が含まれ
ます。 すべてのユーザーが同じアクセス権およびアプリケーション特権を持たない場合は、
メニュー名である値は相関させる必要があります。currentfocus 候補は相関させる必要があ
りませんが、これらの値は targetids としてしばしば後で使用されるため、後で相関が必要
になります。
mx###[R:#] 形式の値は、配列内の選択項目です。常に同じ要素を使用する予定の場合
は、これは他の値のように相関させることができます。それ以外の場合は、ベース部分の
mx#### を相関させ、ランダムな値を選択するカスタム コードを作成します。
新たに作成された参照に内容を表す名前を付けます。参照を作成した後で、その値の他の
消費者を見つけ、それを新たに参照したアイテムで置き換えます。
6.3.4 正規表現の変更
必要なすべての相関を行ったら、表示を Display all test Contents (テスト コンテンツをすべ
て表示) に切り替えます。テストの上部をクリックしてから、「Display References」(参照を表
示) を右クリックします。
2012 年 4 月
ページ 21/ 43
Occurrence 列でカウントを確認します。作成された正規表現がより厳密になるように、正
規表現の編集が必要な場合があります。「Properties」(プロパティ) ボタンをクリックして、
正規表現を変更します。必要に応じて、正規表現にテキストを追加して、「Verify」(確認)
をクリックします。確認に合格すると、Rational Performance Tester は文字列を見つける
ことができます。Rational Performance Tester が更新するため、Specific occurrence
number (特定の出現番号) を更新する必要はありません。出現カウントを 1 にすること
ができない場合があります。一意性が達成できない場合は、番号を 1 けたにするために
真剣に取り組みます。
以下に、正規表現から一意の結果を得るためのヒントを示します。(.*?) の後に正
規表現を追加する"
[^>]*?title="<Matching_Text>"
[^>]*?accesskey='<Matching_Text>'
正規表現の前に以下の語句を置く：
input table
<Matching_Text>[^<]*?
<Matching_Text>.*
テストが作成された後に IBM Tivoli サービス マネジメント製品のビルド/リリース レベル
が変更された場合は、テストがもはや正しく実行されない可能性があります。その場合で
も、テストの再レコードは不要な場合がありません。おそらく、相関された MXid 値の正規
表現を変更する必要があります。表現をより厳しくするか、厳しさの緩和が必要な場合があ
ります。
Rational Performance Tester の不具合のため、Rational Performance Tester が正規表
現を作成する際にホスト名を使用する場合があります。テストが異なるホストに対して実行さ
れる可能性がある場合は、これらの各正規表現を変更します。これを行うには、テストの上
部に移動して、右クリックし、「Display references」(参照を表示) を選択します。. Regular
expression 列を調べます。表現にホスト名が含まれている場合は、それを変更します。現在
の正規表現に応じて、次の表現のいずれかが適切な代替表現になる可能性があります：
http.{0,1}://.*?(/[^?]*)/
http.{0,1}://.*?(/.*?)'
http.{0,1}://.*?(/.*?)"
http.{0,1}://.*?(/.*?)\]
6.3.5 条件コードでのデータ相関参照
条件付で実行されるコードにループがある場合は、そのループの後で発生する相関関係がループ
内のページに関連付けられないようにします。常に実行されるページに関連付けます。
6.3.6 使わない参照の削除
データ相関関係はテストの実行時にわずかながらオーバーヘッドを発生します。使わない相
関関係が多数ある場合は、それらを削除できます。Display References ウィンドウから、
Occurrence 列のカウントを確認します。出現カウントが空白の場合は、対応する参照は使
用されないため、削除することができます。参照を選択して、Disable (無効) アイコンをクリッ
クします。
2012 年 4 月
ページ 22/ 43
6.3.7 テキストのチェック
Rational Performance Tester のスクリプティングが成功するように、コンテンツの確認ポイ
ントを含めます。確認ポイントがないと、テストが正しく実行されることに誤った自信をもつ恐
れがあります。
各ページにコンテンツ確認ポイントを作成します。Response 200 – OK メッセージを持った
ページ要素を選択します。「Response 200 – OK」 をクリックします。「Add」(追加) ボタンを
クリックして、Content Verification Point (コンテンツ確認ポイント) を選択します。1つのペー
ジには、Response 200 – OK メッセージを持った複数のページ要素を含めることができま
す。一番適切なものを選択します。「Protocol data」で「Response Content」 タブまたは
「Browser」 タブを使って、使用する応答を決定します。右側のコンテンツ ウィンドウを調べ
て、そのページに固有のテキストを探します。確認ポイントを合格/不合格にする条件のプル
ダウン選択が正しく設定されるようにします。
6.3.8 考える時間と遅延時間
各ページのスクリプトにレコードされた考える時間をすべて削除します。通常はユーザーが画
面を読んだり、画面に入力する各アクションの前に、現実的な考える時間 (5 秒か10 秒) を
追加します。
各ページに関連付けられたリクエストを実行する直前に Rational Performance Tester が
適用する考える時間に加えて、ページ内でのクライアント (ブラウザー) の再生速度の遅延
を調整できます。テストのルートから、Test Element セクションの HTTP Options タブをクリ
ックします。再生速度を調整します。スライダーは、クライアント (ブラウザー) のより低速/高
速な処理を反映するように HTTP リクエストが送信される速度を調整します。スライダーを
左端まで移動すると、遅延はなくなります。この尺度はテストのすべてのリクエストに適用され
ます。
6.3.9 セカンダリ イメージ
Rational Performance Tester Release 8.2.1 には、ページ キャッシュ エミュレーション機能が
含まれています。以前のバージョンを使用する場合は、作業環境で希望するキャッシング容量に
応じて、イメージ ロードの無効化を検討できます。テストのルートから、Test Element セクション
の HTTP Options タブをクリックします。「Secondary request behavior」(セカンダリ リクエスト
動作) の横の 「Modify」(変更) をクリックしてから、「Images」(イメージ) を選択します。
「Disable」(無効) をクリックします。現行バージョンの Rational Performance Tester を使用する
場合は、この方法を使用する必要はありません。
6.3.10 カスタム コード
カスタム コードはさまざまな目的に使用できます。一般的な使用方法には、値のプリントアウ
ト、ランダム要素の選択、変数の値のチェック、ループの脱出などがあります。
カスタム コードの作成に、Java™ プログラマーは必要ありません。プログラミングの基本を
理解し、手始めにいくつかの例を知る必要があるだけです。コードを挿入するページにカーソ
ルを配置します。Insert (挿入) をクリックして、Custom Code (カスタム コード) を選択しま
す。Class name フィールドで、内容が分かる名前をコードに付けます。すべてのカスタム コ
ードは、Rational Performance Tester が使用するテスト パッケージとは別の、カスタム コ
ード専用のパッケージに入れることをお勧めします。Generate code (コードの生成) をクリッ
クすると、Rational Performance Tester はスケルトン (骨格だけのコード) を作成します。
次のコードは、渡された値をプリントアウトするコードの例です。
package mypkg;
2012 年 4 月
ページ 23/ 43
import com.ibm.rational.test.lt.kernel.services.ITestExecutionServices;
/**
* @author unknown
*/
public class PrintValue implements
com.ibm.rational.test.lt.kernel.custom.ICustomCod
e2 {
/**
* Instances of this will be created using the no-arg constructor.
*/
public PrintValue() {
}
/**
* For javadoc of ICustomCode2 and ITestExecutionServices interfaces, select
'Help Contents' in the
* Help menu and select 'Extending Rational Performance Tester
functionality' -> 'Extending test execution with custom code'
*/
public String exec(ITestExecutionServices tes, String[] args) {
return null;
}
}
ITestLogManager インターフェースは、カスタム コードのアクションからメッセージと確認ポイ
ントを TestLog (実行履歴) に記録します。次のインポート行をカスタム コードで使用します：
import com.ibm.rational.test.lt.kernel.services.ITestLogManager;
次の行を public String exec(ITestExecutionServices tes, String[] args) { と
return null; の間に追加します。
ITestLogManager tlm = tes.getTestLogManager();
String ValueToPrint = args[0];
tlm.reportMessage("Passed Value: "+
ValueToPrint);
これで、渡された値をプリントアウトするカスタム コードが作成されました。
詳細については、Rational Performance Tester マニュアルで 「Extending test execution
with custom code」 を検索してください。
6.3.11 参照の作成
テストにカスタム コードを使う場合は、カスタム コードに渡すアイテムの参照の作成が必要
になる場合があります。
キャプチャーしたい値を含んだ応答があるページ要素を選択します。そのページのサーバー
応答 (Response 200 – OK) へ移動します。コンテンツ ウィンドウにサーバー応答を表示す
るために、CTRL+Left Click と入力します。コンテンツ ウィンドウで右クリックして、Find を
選択してから In Content を選択します (CTRL+F はコンテンツ ウィンドウで機能しない場
合があります)。右側のコンテンツ ペインで欲しいテキストを検索します。値を検索したら、テ
キストを強調表示して、右クリックし、Create reference を選択します。
2012 年 4 月
ページ 24/ 43
場合によっては、応答コンテンツ全体をカスタム コードに渡す必要があります。その参照を
作成するには、カーソルをコンテンツ ウィンドウに置いて右クリックし、Create Field
Reference (フィールド参照を作成) を選択します。
6.3.12 Maximo ページ シーケンス番号の処理
Tivoli Process Automation Engine Release 7.5.0.1 は複数のリクエストを非同期的に送信
できます。すべてのリクエストが受信されるようにするため、pageseqnumber および
xhrseqnum の 2 つのシーケンス番号がすべての maximo.jsp のサーバー リクエストに
追加されました。 これらのシーケンス番号はユーザーに固有であり、セッション番号によって
追跡されます。テスト内でループする場合は、これらのシーケンス番号を操作する必要があり
ます。各新規ページは pageseqnum をインクリメントして、xhrseqnum をリセットする必要
があります。ページ内のすべてのリクエストは xhrseqnum をインクリメントする必要がありま
す。
データ相関関係のルールは一部の詳細を処理するために作成されています。pageseqnum
が存在するかどうかを確認するには、html ヘッダーを検索するルールを作成します。検索さ
れたら、テスト変数を作成し、pageseqnum ヘッダー値から変数への置換を作成します。類
似のルールを xhrseqnum 用に作成します。
ユーザー データ領域から変数を更新できるようにするには、仮想ユーザーの寿命に及ぶ変
数を定義する必要があります。スクリプトが呼び出されるごとに、変数も 0 (ゼロ) に初期化さ
れる必要があります。
変数はカスタム コードで操作できます。1つのルーチンで pageseqnum をインクリメントし
て、xhrseqnum リセットします。もう一方も xhrseqnum をインクリメントする必要がありま
す。各 maximo.jsp の前に、2 つのカスタム コード モジュールのいずれかが挿入される必
要があります。
次のカスタム コードの抜粋は pageseqnum を処理します。
public String exec(ITestExecutionServices tes, String[] args)
{ ITestLogManager tlm = tes.getTestLogManager();
IDataArea userDataArea = tes.findDataArea(IDataArea.VIRTUALUSER);
//
Get the variables value field.
String pageseqnum = userDataArea.get("pageseqnum").toString();
//
tlm.reportMessage("pageseqnum " +pageseqnum);
int PageSeqNum ;
int NewPageSeqNum ;
PageSeqNum = Integer.parseInt(pageseqnum);
//
tlm.reportMessage("pageseqnum "
+PageSeqNum); NewPageSeqNum = PageSeqNum + 1;
tlm.reportMessage("New pageseqnum: "+ NewPageSeqNum);
userDataArea.put("pageseqnum",
Integer.toString(NewPageSeqNum));
userDataArea.put("xhrseqnum", "1");
return null;
}
次のカスタム コードの抜粋は xhrseqnum を処理します。
public String exec(ITestExecutionServices tes, String[] args)
{ ITestLogManager tlm = tes.getTestLogManager();
IDataArea userDataArea = tes.findDataArea(IDataArea.VIRTUALUSER);
//
Get the variables value field.
String xhrseqnum = userDataArea.get("xhrseqnum").toString();
//
tlm.reportMessage("xhrseqnum " +xhrseqnum);
int XhrSeqNum ;
int NewXhrSeqNum ;
XhrSeqNum = Integer.parseInt(xhrseqnum);
//
tlm.reportMessage("xhrseqnum "
+XhrSeqNum); NewXhrSeqNum = XhrSeqNum + 1;
tlm.reportMessage("New xhrseqnum: "+ NewXhrSeqNum);
2012 年 4 月
ページ 25/ 43
userDataArea.put("xhrseqnum", Integer.toString(NewXhrSeqNum));
return null;
}
6.3.13 特殊な状況
自動化されたテストでの既知の問題として、IBM Tivoli サービス マネジメント製品が予期し
ないホップアップ ウィンドウを表示する場合があります。次の個々の状況を検討します。
Ÿ ポップアップが常に発生する場合、およびレコードされたテストにある場合。
Ÿ イベントを待っている間にポップアップが発生する場合。
Ÿ エラー メッセージ ボックスが表示される場合。
6.3.13.1
ポップアップ ウィンドウが表示される場合
ポップアップ ウィンドウが表示される1つのケースは、ワーク オーダー、購買請求書、または
発注書のステータスが変更されたときに、「Please Wait」ウィンドウが画面に表示される場合
です。IBM Tivoli サービス マネジメント製品コードでは、3 秒スリープ タイマーを持ったル
ープがあり、その場合は予期した応答のチェックがあります。
ステータス変更の場合は、テストが「Please Wait」ポップアップ ウィンドウをレコードします。
Response 200 ステータスを持ったシングル ページ要素があるはずです。Test Data フィー
ルドに、longopwait の targetid を持った longopcheckのイベントが表示されるはずです。
最初のページ要素の前に、3 秒の遅延を指定します。そのページ要素から応答全体への参
照を作成します。ページ要素の後に、エラーが表示される応答でテキストをチェックするカスタ
ム コードを挿入します。そのテキストの一部が見つかると、ループから抜け出すためのコー
ドを挿入します
tes.getLoopControl().breakLoop();.
問題が発生したことを知るために、リターン ステータスを設定します。リクエストが成功したこ
とを示すテキストの応答をチェックする追加のカスタム コードを挿入します。そのようなテキ
ストが見つかると、ループから抜け出すためのコードを挿入します。そのページ内で、遅延時
間、ページ要素、およびカスタム コードの両方の断片を含んだループを作成します。ロードし
た状態で予期した応答を返すのにかかると思われる最大時間量を決定します。ループの繰り
返しカウントをその時間の 1/3 に設定します。ループが完了するには、最低でも 3 秒かか
ることに注意してくｊださい。
そのページの応 答 時 間 は正 しくありません。最初の 3 秒の遅延は除外されます。
Rational Performance Tester は、最初のページ要素の送信から最後のページ要素の応答
の終わりまで計時します (応答から参照を抽出する正規表現処理時間、またはページ内に
埋め込まれたカスタム コードの実行時間など、オーバーヘッドが占める割合の調整ととも
に、これを行います)。追加の 3 秒を含めるため、結果を手動で調整する必要があります。
6.3.13.2
ポップアップの出現に一貫性がない場合
ポップアップ ウィンドウの出現に一貫性がない一例としては、「Please Wait」ウィンドウがフィ
ルター検索の後で表示される場合があります。「Please Wait」ポップアップ ウィンドウは、す
べての検索で表示されません。
実行している IBM Tivoli サービス マネジメント製品のバージョンによっては、次のプロパテ
ィを1つまたは複数設定することにより回避できます。
2012 年 4 月
ページ 26/ 43
Ÿ webclient.disablelongopquery=true
Ÿ webclient.longopquerydialogwaitetime=300000 (以前は 3000)
実行している IBM Tivoli サービス マネジメント製品のバージョンでこれらのプロパティを使
用できない場合は、この状況に対するコーディングがより難しくなります。ステップを記録でき
るとともに常にポップアップが出る状況を強制する必要があります。説明したように「Please
Wait」ページをコーディングするとともに、1 回繰り返すループを検索と「Please Wait」コード
を囲むように配置する必要があります。検索の後で、アイテムのリストがあるかどうかを調べ
るために、応答をチェックできます。リストがある場合は、ループから出ます。リストがない場
合は、続行して「Please Wait」ループを実行します。
初期バージョンの IBM Tivoli サービス マネジメント製品 7.x では、指定したプロパティ ス
テートメントと同じ効果がある databean.class ファイルの修正が必要でした。
6.3.13.3
エラー メッセージ ボックスが表示される場合
これは一番難しいなケースです。サーバーがエラーを返す可能性が予想できる場合は、応答
フィールド全体への参照を作成して、適切なアクションを行うカスタム コードに渡すことができ
ます。エラーが予測できない場合は、状況をデバッグして適切に処理するために、十分なロ
グを有効にする必要があります。
6.4
スケジュールを実行する
6.4.1 シ ス テ ム
クロック
テストするシステム内のすべてのコンピュータのシステム時刻を同期して、リソース モニタリ
ングが正しいタイムスタンプを使用するようにします。Rational Performance Tester はシス
テム クロックの小さな差異を処理できます。
6.4.2 エクリプス設定
段階の予期されるユーザー数が段階の終わりにアクティブでない場合は、段階的スケジュー
ルはデフォルトで段階の終わりに終了します。スケジュールの続行を許可する許容値を設定
できます。この値は、完了していないことが許可されるユーザーのパーセンテージであり、デ
フォルトは 0 です。この値を増やすと、エラーがあった場合に、テストのデバッグが可能にな
ります。
-DrptStopTolerance=10
フル エクリプス .ini ファイルは次の場所にあります： <Install_Directory>\SDP\eclipse.ini.
スリム化したエクリプス バージョンは次の場所にあります：
<Install_Directory>\SDP\rptse\eclipse.ini. 指定した変更を両方の Rational Performance
Tester eclipse.ini ファイルに行います。
6.4.3 エ ー ジ ェ ン ト 設 定
6.4.3.1
同一コンピューター上の複数のエージェント
エージェントが処理できるユーザーのボリュームはヒープ サイズによって制限されるため、1
つのコンピューターに複数のエージェントを配置して、ワークベンチ コンピューターのホスト
ファイルのエントリによるエージェントの区別が必要になる場合があります。CPU やメモリー
リソースが許可する以上のエージェントをコンピューターに配置しないでください。
2012 年 4 月
ページ 27/ 43
6.4.3.2
ワークスペースでの設定
ワークスペースにエージェントの場所を作成したら、次の行を挿入してエージェントのプロパテ
ィを変更します。
RPT_DEFAULT_MEMORY_SIZE = 1500
Linux™ エージェントの場合は、値に 3000 を使用できます。
一般的に、スケジュールでテスト中にループが行われるように RPT_VMARGS =
-DKEEP_ALIVE_ACROSS_TEST=TRUEを設定して、Rational Performance Tester がループ
繰り返し境界 (つまり、テスト境界) で接続を再利用するようにします。(デフォルトでは、
Rational Performance Tester はテストの終わりに接続を閉じます。) この動作は、作成さ
れる接続が少ないと、テスト中のエージェントとシステムの両方で作業量が大幅に減ります。
ただし、テストがブラウザー セッション (これは、終了時に接続を閉じます) を意味する場合
は、Rational Performance Tester のデフォルトの動作が正しいので、この設定で上書きす
るべきではありません。
仮想ユーザーがキープ アライブ タイムアウト内に接続を再利用しない場合は、サーバーは
接続を閉じる可能性があり、仮想ユーザーは新しい接続を作成する必要があります。
仮想ユーザーがサーバーのキープアライブ再利用制限を超える場合は、サーバーは接続を
閉じるため、仮想ユーザーは新しい接続を作成する必要があります。
IBM Tivoli サービス マネジメント製品の顧客が少なくとも一人いると、各繰り返しのための
新規接続の作成には、より少ないリソースが使用されていました。RPT_VMARGS =value
は、-DKEEP_ALIVE_ACROSS_LOOPS_WITHIN_TEST=FALSE (デフォルト) に置き換えられ
ました。状況はこれ以上調べられませんでしたが、おそらくループの時間周期と特定サーバ
ーのキープアライブ設定が組み合わされて、サーバーが常に閉じた接続を仮想ユーザーが
再利用しようと連続的に試みた状況が生み出されています。
6.4.3.3 Windows エージェント コンピューターでの設定
®
すべての Windows エージェント コンピューターに十分な TCP/IP ポートを確保します。
システム レジストリに以下の値を設定します：
TcpTimedWaitDelay
dword:0000001e
StrictTimeWaitSeqCheck
dword:00000001
MaxFreeTcbs
dword:00011940
MaxHashTableSize
dword:0000ffff
TcpWindowSize
dword:0000ffff
EnableDynamicBacklog
dword:00000001
MinimumDynamicBacklog
dword:00000032
MaximumDynamicBacklog
dword:000003eb
DynamicBacklogGrowthDelta dword:0000000a
Interfaces\TcpAckFrequency dword:00000001
(30)
(1)
(72000)
(65535)
(65535)
(1)
(20)
(1000)
(10)
(1)
Windows XP および Windows Server 2003 の場合は, 次のように設定します：
MaxUserPort
dword:0000ffff (65535)
これらの設定は次の場所にあります。
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/Tcpip/Parameters
Windows 7、Windows Server 2008、Windows Vista の場合は、デフォルトの動的ポート範
囲が変更されています。新しいデフォルト開始ポートは 49152、デフォルト終了ポートは
65535 です。デフォルトでは、以前の 5,000 ポートから、16,384 ポートが使用できるように
なりました。動的ポート範囲を表示するには、Command Prompt ウィンドウを起動して、
netsh コマンドを次のように使用します：
2012 年 4 月
ページ 28/ 43
netsh int ipv4 show dynamicport tcp
次のコマンドは、動的ポート範囲を許容される最大ポート数に変更します：
netsh int ipv4 set dynamicport tcp start=1025 num=64510
最小開始ポートは 1025 で、最大終了ポートは
65535 を超えることはできません。
6.4.3.4 Linux または AIX エージェント コンピューターでの設定
Linux、UNIX
®
または AIX
®
エージェントの場合は、ulimit -n 30000 または unlimited を
変更して、デフォルトの 1024 からのプロセス当りのファイル制限を変更します。
Linux
/etc/sysctl.conf を次のパラメーターに変更して、ファイルを保存します。次のコマンドを
実行します:
sysctl –p
net.ipv4.ip_local_port_range
net.core.rmem_default
net.core.wmem_default
net.core.wmem_max
net.core.rmem_max
net.core.netdev_max_backlog
net.ipv4.tcp_no_metrics_save
net.ipv4.tcp_rmem
net.ipv4.tcp_wmem
net.core.optmem_max
2048 65000
262144
262144
33554432
33554432
5000
1
4096
4096
40960
16777216
16777216
33554432
33554432
AIX
次のコマンドを以下の値で実行します。
no –p –o <parameter> = <value>
chdev -l sys0 -a maxuproc=<value>
sb_max clean_partial_conns 1
tcp_timewait
tcp_finwait2
tcp_keepidle
tcp_keepinit
tcp_nodelayack
tcp_keepintvl
tcp_ephemeral_low
tcp_sendspace
tcp_recvspace
rfc1323
Maxuproc
2012 年 4 月
30
60
600
40
1
10
1024
4096000
4096000
1
8192
ページ 29/ 43
6.4.3.5 エ ー ジ ェ ン ト 選 択
スケジュール グループを実行する場所を選択する場合は、ロード バランス、およびデータプ
ールの構成方法 (共有、プライベート、セグメント化) を検討します。
6.4.4 リソース モニタリング
Rational Performance Tester を使用すると、Tivoli Monitoring (インストールした場合) か
ら利用できる Windows PerfMon データ、Unix/Linux/AIX rstatd データ、DB2 データ、
®
Apache Tomcat データ、JVM データ、WebSphere PMI データ、およびその他のパフォー
マンス メトリックスを収集できます。
デフォルトでは、ほとんどのシステムで自動的に起動する rstat デーモンは構成されませ
ん。これを構成するには、ルート ユーザーとして次のステップを実行します：
Ÿ /etc/inetd.conf を編集して非コメント化するか、rstatd にエントリを追加します。
例： rstatd sunrpc_udp udp wait root /usr/sbin/rpc.rstatd rstatd
100001 1-3 2
Ÿ /etc/services を編集して非コメント化するか、rstatd にエントリを追加します。
例： rstatd 100001/udp 3
Ÿ サービスをリフレッシュ：
Ÿ rstatd を起動：
refresh -s inetd
/usr/sbin/rpc.rstatd
リソース モニターを作成する際に、さまざまなタイプのモニターをそれぞれのロケーション ア
セットに配置します。同じ場所に複数の PMI ポートを配置することはできません。それぞれ
を専用の場所に配置する必要があります。
収集するメトリックスを選択する場合は、分析を予定しているより多いデータを収集しないでく
ださい。また、データを頻繁に収集しないでください。
6.4.5 テスト ログ
データの収集が多すぎると、パフォーマンスに悪影響を及ぼすおそれがありますが、データの
収集が不十分な場合はデバッグが事実上不可能になります。本番環境や、ユーザー数が多
い場合は、ロギングを制限します。必ず What to Log (ログの対象) を Show errors and
failures (エラーと障害の表示) に設定し、Also show warnings (警告も表示) を All (すべて)
に設定します。
テストをデバッグする場合は、すべての領域のログ レベルを All (すべて) に設定し、意味の
あるユーザーの数やパーセンテージをモニターします。これらの設定は、すべてのページ
(不合格にならなかったページも含む) の応答に表示されます。
テストがデバッグされたら、ログレベルの And also show all other types (他のタイプもすべ
て表示) を Primary Test Actions (プライマリ テスト アクション) に設定します。モニターす
るユーザーのパーセンテージを減らして比較的小さな数にします。このような設定により、ロ
グされたユーザーのサブセットに対して不合格となったページの詳細を調べることができま
す。
6.4.6 統計とリソースのモニタリング間隔
スケジュールの Statistics タブのサンプリング間隔は、レポートのサンプリング間隔を設定し
ます。長期テストでは、統計サンプル間隔を 30 秒または 60 秒に増やします。極めて長い
テストを呼び出すと、Rational Performance Tester はその間隔を増やすようにプロンプトす
る場合があります。このプロンプトに提示された時間は指定する最低限の時間となります。た
だし、提示されたものより短いサンプル間隔が必要であると思う場合や、十分な CPU やメ
モリー リソースがワークベンチで使用できると思う場合は、より短い間隔を試すことができま
す。受け入れられるかどうかを見るため、ワークベンチのパフォーマンスを観察します。
2012 年 4 月
ページ 30/ 43
リソース モニタリングのポーリング間隔は、モニターのロケーション ドキュメントにある
Options タブで設定されます。長時間の実施の場合は、Windows Performance Monitor お
よび UNIX rstatd モニター間隔を少なくとも 30 秒または 60 秒に増やします。デフォルト
は 5 秒です。ポーリング間隔を統計サンプリング間隔と同じ値にすることもできます。
WebSphere PMI の間隔は 300 秒または 600 秒に設定します。DB2 の間隔は 300 秒
または 600 秒に設定します。その他のモニターする値を適度に増やします。
6.4.7 パフォーマンス要件
テストされる各アプリケーションは、テストの合否を決定する一連の基準が必要です。最低で
も、応答時間の値、合否の割合、およびアプリケーション サーバーとデータベース サーバー
での CPU 使用を設定します。さらに多くの要素をパフォーマンス要件として設定できます。
要件を満たしているかどうかの情報は、パフォーマンス レポートの結果から入手できます。
6.4.8 実行構成
実行構成を使用すると、結果をデフォルトの場所からサブフォルダーに移動する場合の破損
の可能性を最小限にすることができます。実行構成ファイルにより、スケジュール名に実行日
時を付けたものより内容が分かる名前をテスト結果に付けることができます。
Run メニューから Run Configuration (実行構成) を選択します。左ペインの左端の New
launch configuration アイコンをクリックします。右ペインで構成に名前を付けます。
Schedule (スケジュール) タブで実行するスケジュールを選択します。Test Log (テスト ログ)
タブで、Use defaults (デフォルトを使用) の横のチェック ボックスを消去します。Name フィ
ールドでテスト結果名を指定します。実行の日時が名前に追加されます。結果を保管する場
所を指定します。新規ディレクトリを希望する場合は、それを作成してから実行構成を作成し
ます。Apply (適用) ボタンをクリックします。実行構成を初めて使用する場合は、Run (実行)
ボタンをクリックする必要があります。その後で、run アイコン (緑の円の中に矢印) の右の
ドロップダウン メニューから構成名を入手できます。
6.4.9 ユーザー コメント
スケジュールが呼び出されるか、作成されると、Performance Test Results (パフォーマンス
テスト結果) ウィンドウに User Comments (ユーザー コメント) フィールドが表示されます。
このフィールドを使用して、テストが実行された環境を記述します。このフィールドは、
Rational Performance Tester リリース 8.2.1 の時点で、パフォーマンス レポートの結果に
使用できます。
6.5
パフォーマンス結果
レポートは実行時に自動的に表示されます。環境設定 (Window > Preferences > Test >
Performance Test Reports) は、アクティブな時間範囲または実行全体で結果を表示する
かどうかをコントロールします。
レポートは、閉じると保存されません。Rational Performance Tester のレポートは保存され
たクエリーに似ています。特定の結果に関して何度でもレポートを開く (クエリーを実行する)
ことができ、結果には影響を与えません。レポートを変更すると (カウンターの追加、フィルタ
ーの追加など)、クエリーが効果的になります。レポートを閉じると、こうした変更を保存するか
破棄するかを尋ねられます。レポートを再表示するには、Test Navigator でその実行が見つ
かるまでプロジェクトを展開します。デフォルトのレポートを表示するには、結果をダブルクリッ
クします。別のレポートを表示するには、テスト結果を右クリックし、Display Report (レポート
を表示) をクリックして、表示するレポートを選択します。
2012 年 4 月
ページ 31/ 43
6.5.1 カスタム レポート
デフォルトのレポートは HTTP Performance レポートであり、11 のタブが含まれています。
独自のレポートを作成することもできます。デフォルトでは、確認レポートとパーセンタイル レ
ポートは個別のレポートです。その情報用の新しいタブをレポートに作成できます。レポートを
新しいデフォルトにするには、環境設定の変更が必要になります。Windows メニューから、
Preferences > Performance Test Report > Default Report を選択します。
カスタム レポートの作成については、次を参照してください： Customize, export, and
compare reports.
6.5.2 パフォーマンス テスト結果の分析
テストの実行中に発生するエラーは、Execution Event Console (実行イベント コンソール)
タブに表示されます。可能であれば、テストの実行中にエラーを確認し、発生しているエラー
の割合が著しく大きい場合は、テストを終了します。テストが完了したら、パフォーマンス結果
を右クリックし、Display Test Log (テスト ログを表示) を選択すると、テスト ログを確認でき
ます。
Overview (概要) タブでエラーを検討し、必要に応じて、Events (イベント) タブでログの詳細
を調べます。
エージェント コンピューターの TCP/IP チューニング推奨事項を適用した後のロード テスト
で接続エラーが出る場合は、その設定をアプリケーション サーバーにも適用して実験するこ
とができます。特に、使用可能なポートの数に影響を与える値 (Windows での
MaxUserPort および dymanicport 設定や AIX または Linux での tcp_ephemeral_low
設定)、および TCP 時間待ち遅延設定などを検討します。
6.5.3 すべての時間範囲の比較
段階を含んだスケジュールを実行する場合は、各段階の時間範囲が自動的に作成されま
す。これらの段階を比較するレポートを表示できます。また、環境設定を設定して、段階化さ
れた実行の終わりにレポートを自動的に表示できます。
Compare report は各段階の時間範囲を比較します。このレポートは、テスト下のシステム
がさまざまなユーザー ロードの下でどのように動作するかについて、素早い、並列的な分析
を提供します。テストが完了したら、結果ファイルを右クリックし、Compare All Time Ranges
を選択します。アクティブな時間範囲とデフォルトの時間範囲のどちらを表示するかを指定し
た環境設定に応じて、これを完了するのに数分かかる場合があります。また、Performance
Test Run ウィンドウで比較する特定の時間範囲を選択することもできます。
6.6
ワークスペースのその他の問題
6.6.1 プロジェクトのクリーンアップ
プロジェクトが既存のワークスペースにインポートされると、場合によっては数百のエントリが
Problems タブに表示されることがあります。
2012 年 4 月
ページ 32/ 43
この状況を改善するには、次の 2 つの手順が必要になる場合があります。Navigator ウィ
ンドウで、src / test
が表示されるまでツリー構造を展開します。(Navigator タブを表示す
るには、Windows > Show view > Navigator
をクリックします)。末尾が java で終わり、
名前がテスト名とスケジュール名に一致し、名前に大きな数値文字列が含まれているアイテ
ムをすべて削除します。そのクラスに配置された可能性のあるカスタム コードと一致する名
前を持つものは削除しないでください。
Test Navigator (テスト ナビゲーター) ウィンドウで、プロジェクトを右クリックし、Properties
(プロパティ) を選択します。Click on Java Build Path (Java ビルド パス) をクリックしま
す。Libraries (ライブラリ) タブをクリックします。JRE System Library [jdk] および外部に追
加されたライブラリを除くすべてのエントリ強調表示します。(削除するエントリには、横に赤
い X があります。これは、それらが見つからないことを示します)。Remove (削除) をクリッ
クします。Project メニューから Clean を選択します。Clean projects selected below (下
の選択されたプロジェクトを消去) の横にあるラジオ ボタンをクリックします。プロジェクトを
選択します。Start a build immediately (ビルドをただちに開始 ) の横のチェック ボックスを
選択解除します。Build only selected projects (選択したプロジェクトのみをビルド) をクリッ
クします。
2012 年 4 月
ページ 33/ 43
7
パフォーマンス問題のトラブルシューティング
パフォーマンス分析およびデバッグのために、開発環境またはテスト環境でトラブルシューティ
ング手順を使用します。一般的に、この手順は本番環境で使用しないでください。テスト環境
では問題を特定できない場合にのみ、この手順を本番環境で使用します。
7.1
パフォーマンス問題の判別
可能な場合は、実装段階でロード テストを実施して、IBM Tivoli サービス マネジメ
ント製品を本番環境に配置する前に、パフォーマンス問題の存在を明らかにします。
ロード テストを実施する機器がある場合は、パッチや長い間のデータ増加によるパフォーマ
ンスへの影響があるかどうかを調べるために、IBM Tivoli サービス マネジメント製品を本番
環境に配置してからロード テストを使用できます。
7.1.1 問題の判別テクニック
ア プ リケ ー シ ョン サ ー バ ー
何らかのエラーがないか WebSphere ログを確認します。ロードバランスを行った実装の
場合は、JVM 全体のユーザーの分布に注意を払います。verbose garbage collection を
有効にして、アプリケーション サーバーでの JVM メモリー使用率をモニターします。
WebSphere アプリケーション サーバー ログ
SystemOut.log および SystemErr.log — これらのログには、任意のアプリケーション エラ
ー、長期の SQL クエリーなどがあります。
Native_system_err.log — verbosegc を有効にした場合は、verbose garbage collection
情報がこのログに示されます。
http_plugin.log — クラスター化された環境でのロード バランシング問題は、このログを調べ
ます。
WebSphere ア プ リケ ー シ ョン サ ー バ ー 構 成
JVM ヒープ サイズが適切に設定され、ヒープ枯渇が発生しないようにします。
デフォルトのスレッド プール サイズと WebContainer スレッド プールが適切なレベル
に設定されるようにします。
Connection Pool Watchdog のデータベース接続プール監視を有効にし、接続漏れが
発生しないように log4j.logger.maximo.dbconnectionを INFO に設定します。
2012 年 4 月
ページ 34/ 43
Web サーバー
エラーがないか Web サーバー ログを確認します。Web サーバーが必要とする大半の接
続を使用できるかどうかを確認するため、最大接続数と合計接続試行数を表示します。これ
らの数をメモリーとプロセッサー使用の数値と比較して、接続 (他のコンポーネントではない)
によって問題が発生するかどうかを判断します。
IBM HTTP Server では、関連するログは access.log、admin_access.log、
admin_error.log、error.log、および http_plugin.log です。
場合によっては、httpd.conf ファイルの ThreadsPerChild 設定を引き上げる必要があります。
デ ー タベ ー ス サ ー バ ー
maxsession テーブルおよびデータベース 接続数を分析して、セッション アクティビティが
予想したとおりであるか確認します。
また、データベース サーバー メモリーとインスタンス メモリーをモニターします。データベー
ス追跡とスナップショットを収集して、データベースのチューニング問題に役立てることができ
ます。詳細については、DB2 Query Tuning and Index Creation および Tuning and
Indexing Oracle Databases を参照してください。
ネ ットワ ー ク
ネットワーク インターフェースによって処理される 1 秒当りのバイト数をモニターすると、ネ
ットワークの潜在的オーバーロードに対する洞察が得られます。
帯域幅の要件を知るためにより詳細なネットワーク情報が必要な場合は、帯域幅モニタリン
グ ツールを使用して、HTTP リクエスト、階層間の往復数、および TCP/IP パケット情報を
分析できます。
CPU
CPU をモニターして、すべてのプロセッサーが予想したように使用されており、CPU 全体の
使用率が健全な状態を維持するようにします。
メモ リー
合計メモリー使用を注意深くモニターします。IBM Tivoli サービス マネジメント製品では、
JVM ヒープ サイズは、アプリケーション サーバーでモニターする最も重要なメモリーのメト
リックです。
7.1.2 問題の判別ツール
IBM Tivoli サービス マネジメント製品でのパフォーマンス問題を調べるのに役立つツールを
使用できます。
IBM Tivoli サービス マネジメント製品ツール
IBM Tivoli サービス マネジメント製品では、問題の判別に役立つように次のツールを提供し
ています。
2012 年 4 月
ページ 35/ 43
Ÿ DB2 Snapshot Format Tool— この Perl スクリプトは、DB2 スナップショット
ファイルを読み取り、セミコロンで区切られたテキスト ファイルを生成します。この
ファイルをスプレッドシートに読み込むと、動作が遅い SQL クエリーを特定する
のに役立ちます。
Ÿ Activity Dashboard (別名 PerfMon) — 有効にして、使用する方法について
は、次の第 6 章を参照してください： DB2 Query Tuning and Index Creation.
Ÿ IBM Support Assistant Tool— 問題の判別に役立つワークベンチを提供します。
Java Core、Heap Dump、お よ び Garbage Collection の各ユーティリティ
次のツールを使用すると、Java コードをデバッグできます：
Ÿ IBM Thread and Monitor Dump Analyzer for Java— javacores を分析し、モ
ニター ロックおよびスレッド アクティビティを診断して、ハング、デッドロック、リソ
ース競合などの根本原因を特定したり、ボトルネックをモニターします。
Ÿ Websphere Application Server のスレッド ダンプ ファイルを収集する方法に
ついては、次の場所で「To force a thread dump」(スレッド ダンプを強制するに
は) を参照してくだい： Web module or application server stops processing
requests.
Ÿ HeapAnalyzer— ヒューリスティック サーチ エンジンと Java アプリケーション
での Java ヒープ ダンプの分析により、可能性のある Java ヒープ漏れ領域の
発見を可能にします。
Websphere Application Server のヒープ ダンプ ファイルの収集については、
Generating heap dumps manually を参照してください。
Ÿ IBM Pattern Modeling and Analysis Tool for Java Garbage Collector—
verbose GC trace を解析し、Java ヒープ使用を分析して、Java ヒープ使用の
パターン モデリングに基づく主要構成を提案します。
リモ ー ト接 続 ユ ー テ ィリテ ィ
Ÿ PuTTY — SSH で保護されたリモート UNIX プラットフォームへの接続に使用で
きる PuTTY ユーティリティで、Telnet と SSH クライアントが含まれます。
Ÿ Remote Desktop Connection — Windows に付属しており、他の Windows シ
ステムにリモート接続できます。
ファイ ル 転 送 ユ ー テ ィリテ ィ
Ÿ WinSCP— UNIX プラットフォームとのファイル転送に使用できる Windows 用
の無料 SFTP および FTP クライアントです。
Ÿ psftp — SFTP クライアントを含む PuTTY ユーティリティです。SSH で保護さ
れた UNIX プラットフォームとのファイル転送に使用できます。
ア プ リケ ー シ ョン プ ロ ファイ リン グ ユ ー テ ィリテ ィ
次のツールを使用すると、Java コードをプロファイルし、デバッグできます：
Ÿ Performance Inspector— 一連のパフォーマンス分析ツールが含まれており、アプリ
ケーションのパフォーマンスとそれが消費するリソースを知る上で役立ちます。
2012 年 4 月
ページ 36/ 43
Ÿ YourKit — CPU とメモリーの Java Profiler で J2EE/J2ME をサポートします。
Ÿ Eclipse Memory Analyzer— メモリー リークを見つけ、メモリー消費の低減に役立
ちます。
Ÿ OProfile— Linux システム用のシステム全体のプロファイラーで、低いオーバーヘッ
ドで任意の実行コードをプロファイルできます。
そ の 他 の ユ ー テ ィリテ ィ
Ÿ ActivePerl— 統合フレームワークの問題を調べるスクリプトを書くのに便利な Perl
プログラミング環境を提供します。
Ÿ Database SQL Query Tools — 各データベース プラットフォームに、長期の SQL
ステートメントに役立つ SQL クエリーを分析するツールが含まれています。
7.2
システムのモニタリング
システムの継続的なモニタリングは、何よりもパフォーマンス問題の発生を防ぐことができま
す。IBM Tivoli サービス マネジメント製品を本番環境に配置する前に、モニタリング戦略を
用意します。
Monitoring the Maximo Platform には、ご使用の環境をモニターする Tivoli モニタ
リング ポートフォリオの使い方の概要が示されています。
7.2.1 モニタリング ツール
また、次のﾂｰﾙを IBM Tivoli サービス マネジメント製品のモニタリングに使用できます。
ア プ リケ ー シ ョン モニタリング ツール
Ÿ Tivoli Monitoring Agent for Maximo— IBM Tivoli Monitoring の機能を使用するた
めにダウンロードできるオプション機能のパックです。この機能パックには、サーバー
メモリー統計、cron タスク、ユーザー接続、データベース接続、インストールされた製
品とライセンス、およびその他のシステム情報のモニターに使用できる Tivoli
Monitoring ソフトウェアが含まれています。
IBM Tivoli サービル マネジメント製品で IBM Tivoli Monitoring を使用する方
法については、IBM Maximo Monitoring Jam プレゼンテーションを参照してく
ださい。
Ÿ IBM Tivoli Composite Application Manager (ITCAM)— アプリケーションの潜在的
な問題をより深いレベルでモニターできます。IBM Tivoli サービス マネジメント製品
で ITCAM ファミリを使用する方法については、以下を参照してください： System
Performance Monitoring and Diagnosis using ITCAM Products.
ミドル ウ ェア モニタリング ツール
次のモニタリング ツールを使用すると、IBM Tivoli サービス マネジメント製品に関
連付けられたミドルウェア コンポーネントをモニターできます：
2012 年 4 月
ページ 37/ 43
Ÿ Tivoli Performance Viewer— 管理コンソール内から IBM WebSphere Application
Server の全般的な健全性のモニタリングが行えます。
Ÿ Database Monitoring — 各データベース プラットフォームに、データベースをモニタ
ーして、有用な情報を提供するツールが含まれています。
シ ス テ ム リソー ス モニタリング ツール
次のツールを使用すると、テストを実行中にシステム リソースをモニターできます：
Ÿ PerfMon — Windows ベースのシステムでパフォーマンス メトリックスの収集に使
用します。これは Windows の一部であり、すべての Windows パフォーマンス カ
ウンターへのアクセスを提供します。
Ÿ nmonn — AIX または Linux ベースのシステムでパフォーマンス 統計の収集に使
用します。
Nmon for AIX には AIX 5.3 TL09 以降、AIX 6.1 TL02、および Virtual I/O
Server (VIOS) 2.1 が含まれており、デフォルトでインストールされます。AIX の旧
バージョン用の nmon バージョンとこのツールを使用するための情報は、IBM
developerWorks にあります。Nmon for Linux はオープン ソースとしてリリースさ
れており、nmon for Linux wiki から入手できます。
Ÿ rstatd — UNIX システム カーネルからパフォーマンス メトリックスを収集します。
Rpc.rstatd は AIX に同梱されており、Linux プラットフォーム用は rstatd 4 Linux
サイトからダウンロードできます。
Ÿ sysstat— AIX および Linux 用に sar, sadf, iostat, mpstat, および pidstat コマ
ンドを含んだユーティリティのパッケージです。Sar は I/O、メモリー、ページング、プ
ロセス、ネットワーク、および CPU 使用率に関連するシステム情報を提供します。
Sadf は sar によって収集されたデータをフォーマットします。Iostat は CPU およ
び I/O データをディスクおよび TTY デバイスに与えます。Pidstat はプロセス デ
ータをレポートし、mpstat はグローバルおよびプロセッサー当りのデータをレポートし
ます。
Ÿ vmstat — UNIX システムのカーネル スレッド、仮想メモリー、ディスク、トラップ、お
よび CPU アクティビティについての統計をレポートします。
帯 域 幅 モ ニ タリン グ ツ ー ル
次のモニタリング ツールを使用すると、テストを実行中にネットワークと HTTP 帯域
幅をモニターできます：
Ÿ Wireshark— ネットワーク プロトコル アナライザー。帯域幅の分析用にネットワーク
トラフィックをキャプチャできます。
Ÿ WinPcap— パケット キャプチャおよびフィルタリング エンジン。これは、Wireshark
など、多くのネットワーク プロトコル アナライザーで使用されています。
Ÿ HttpWatch— HTTP および HTTPS トラフィックのログを作成し、検査を可能にしま
す。 これを使うと、帯域幅分析のために、ブラウザー クライアントと Web サーバー
間のリクエストと応答を知ることができます。
2012 年 4 月
ページ 38/ 43
8
結果の分析
パフォーマンス テストの結果を分析する場合は、その目的を忘れないでください。パフォーマン
ス テストの一般的な目的は、平均的な実装や、特定のハードウェア/ソフトウェア構成のため
に、エンドユーザー応答時間がビジネス要件によって規定された条件を満たす最適なアクティ
ブ同時ユーザー ロードを決定することです。
最適なシステム環境とは、時折発生するアクティブ ユーザー数のピーク時に、システム
が限界を超えないようにサポートできる十分な CPU とメモリー容量を持った環境です。
作業負荷ミックスはトランザクション レートに基づくため、実際に実行されるトランザクション
レートを計算して、有効なテストかどうかを決定します。トランザクションの合否レートを考慮
して、テストを再度行うかべきかどうかを判断します。
各ロード ポイントの結果をグラフにします。良くできたパフォーマンス テストには、応答
時間、1 秒当りのトランザクション数、CPU およびメモリー使用/ページング、スループッ
ト (mbps) などの結果が含まれます。
次のグラフは、異なるロード レベルでの CPU 使用を示した例です。
図 1: 結果グラフの例
2012 年 4 月
ページ 39/ 43
最終レポートには結果のグラフを含め、ビジネス要件を参照できるようにします。最終レポートでは、パフォー
マンス要件が満たされたかどうかを文書化します。要件が満たされなかった場合は、レポートで考えられるリ
スクを概要し、今後取るべき対策を説明します。
2012 年 4 月
ページ 40/ 43
9
Rational リソース
9.1
全般
Rational Performance Tester Overview
Rational Performance Tester: A resources roadmap for all users
Rational Performance Tester: Find technical developer content and resources for
Rational® Performance Tester.
Redbooks publication: Using Rational Performance Tester Version 7
Rational support: Licensing
9.2
フォーラム
developerWorks > Rational > Forums > Rational Performance Testing
9.3
IBM サポート
Rational Performance Tester Support (登録が必要です)
Software support - Open service request (登録が必要です)
2012 年 4 月
ページ 41/ 43
IBM の Tivoli ソフトウェアについて
Tivoli ソフトウェアは、より効率的で効果的なサービスを御社のビジネスにお届けする拡張可能なモジ
ュラー アプローチの IBM サービス マネジメントに裏付けられた広範囲な製品と機能を提供します。
あらゆるサイズのビジネス ニーズを満たす Tivoli ソフトウェアは、プロセス、ワークフロー、タスクの統
合と自動化を通じて、御社のビジネス目的を支える卓越したサービスを実現します。高度なセキュリティ
を備えたオープン スタンダードの Tivoli サービス マネジメント プラットフォームは、エンド・ツー・エンド
の可視性とコントロールを実現する、事前対応のオペレーション管理ソリューションによって補完されて
います。また、ワールドクラスの IBM サービス、IBM サポート、および IBM ビジネス パートナーの積
極的なエコシステムによって支援されます。また Tivoli カスタマーとパートナーは、世界中で自主運営
されている IBM Tivoli ユーザー グループに参加することにより、お互いのベスト プラクティスを使用
できます。次のサイトをご覧ください：
2012 年 4 月
www.tivoli-ug.org
ページ 42/ 43
®
© Copyright IBM Corporation 2011
IBM United States of America
Produced in the United States of America
All Rights Reserved
IBM Corporation
Route 100
Somers, NY 10589
U.S.A.
IBM、IBM ロゴ、および ibm.com は、世界中の法域で登録された
International Business Machines Corp. の商標または登録商標です。そ
の他の製品名およびサービス名は、IBM またはその他の社の商標です。
IBM 商標の現行リストは、Web 上の次の場所で入手できます：
“Copyright and trademark information”
www.ibm.com/legal/copytrade.shtml.
Java およびすべての Java ベースの商標およびロゴは、米国およびそ
の他の国における Sun Microsystems, Inc. の商標です。
Microsoft、Windows、Windows NT、および Windows ロゴは、米国および
その他の国における Microsoft Corporation の商 標 です。
その他の会社名、製品名、サービス名は、各社の商標またはサービス マー
クです。
本刊行物における IBM 製品やサービスの参照は、IBM が業務を行うすべ
ての国で入手できることを意味するものではありません。
IBM Corporation の書面による許可なく、本書の如何なる部分も、その形式
にかかわらず、複製または伝送することは禁じられています。
製品データは、初版発行日におけるもの校閲されています。製品データは
予告なく変更される場合があります。IBM の 将 来 の 方 向 性 や 意 向 に
関 するすべての記 述 は、予 告 なく変 更 または撤 回 される場 合 があ
り、目 標 のみを表 しています。
本書に含まれる情報は、明示または黙示の如何なる保証も行わずに、現状
のまま配布されます。IBM は、商業性、特定目的への適合性、または権利の
非侵害についての如何なる保証も明確に否認します。
IBM 製品は、それが提供された契約条件 (例えば、IBM お客様契約、
限定保証の記述、国際プログラム ライセンス契約、など) に基づいて保
証されます。
お客様は、法律要件の順守に責任があります。お客様のビジネスや、お客
様が斯かる法律に対応するために取る行動に影響を与える関連する法律
や規制要件の検証や解釈に関して、資格のある弁護士の助言を得ること
は、お客様の単独の責任となります。IBM は、そのサービスや製品がお客
様の任意の法律または規制への順守を確保することについて、法律上の助言
または表明または保証を行いません。
2012 年 4 月
ページ 43/ 43