2012年4月21日土曜日

Rational Performance Tester 活用ガイド: 第3回 スケジュールの作成と実行Hints&Tips編


Rational Performance Tester活用ガイドの位置づけ

当ガイドは、Rational Performance Tester(以降、RPTと記述)のユーザー向けに、RPTを使用したパフォーマンス・テストを効果的に実施できるようなHints & Tipsをまとめた資料です。

全4回で構成されていますので、他の章も参考にしてください。


全4回
タイトル
第1回事前準備とテスト記録・生成 Hints & Tips編
第2回テストスクリプトの編集 Hints & Tips編
第3回スケジュールの作成と実行 Hints & Tips編
第4回テスト結果(レポート)の確認 Hints & Tips編+FAQ

当ガイドは2011年1月時点の最新バージョンであるRPT v8.2を前提に記述しております。利用する環境やバージョンによっては、提供される機能や画面構成が異なる可能性がありますのでご注意ください。

1. スケジュールの作成と確認

1.1. スケジュールの設計

1.1.1. 負荷の設定

スケジュールの機能を使用して、「仮想ユーザー数」「スループット(トランザクション)」「期間」などテストの負荷を設定します。

ユーザー数の指定は、「ユーザー・ロード」タブより行います。ユーザー数の指定や、ユーザー投入の間隔、テストの実行期間を指定出来ます。


スケジュール・エレメントの評価

もし、「1秒あたりxxトランザクションの負荷を発生させたい」という要件がある場合の制御方法は、以下のように考えます。

単位時間あたりのトランザクション量は、テスト対象サーバー側のパフォーマンスによっても影響を受ける値であるため、RPTの設定にて正確な値を指定し実行することは出来ません。従って、実際にテストを実行してみた上で負荷の量を調整しながら設定値を決めていく必要があります。

RPTのテストおよびスケジュールで設定できる項目は、「実行する仮想ユーザー数」「テストのページに含まれるThinkTime(考慮時間)」「(ループでテストを反復する場合)単位時間あたりにテストを実行する頻度」などです。ユーザー数を増やしたり、ThinkTimeを短くすると、単位時間あたりのトランザクション量が増加します。またループの反復率の設定を使用すると、一定の頻度でリクエストを送信することが出来るので、各ページの応答時間に大きく左右されず安定したトランザクションを指定しやすくなります。上記パラメーターを調整しながら何度かスケジュールを実行し、ちょうど良い負荷を発生させられる設定を見つけるようにします。

1.1.2. ユーザー・グループのグループ・サイズ

ユーザー・グループのグループ・サイズの指定には、「絶対」値と「パーセント」値の2種類があります。


「パーセント」指定の場合、合計のユーザー数が割り切れないときは、余ったユーザーがどのグループに割当てられるかは、RPTの内部ロジックに依存するため、明確に指定することが出来ません。割り当てるユーザー数が重要な要素である場合には「絶対」値で指定してください。

1.1.3. スケジュールの組み方

同じユーザー・グループ内のエレメントは、上から順にシーケンシャルに実行されます。

並列に実行させる場合には、ユーザー・グループを分けます。


上記のスケジュールの場合、

  • ユーザー・グループ1のサンプル1ユーザー・グループ2のサンプル1は同時に実行
  • ユーザー・グループ1では、サンプル1の完了後にサンプル・スクリプト1-3が開始

このスケジュールに「遅延」を追加し、「ユーザー・グループ1」と「ユーザー・グループ2」のサンプル1の実行をずらします。


上記の例では、

  • ユーザー・グループ1のサンプル1開始5秒後にユーザー・グループ2のサンプル1が開始されます。

「遅延」の時間を調整することで、ユーザー・グループ1とユーザー・グループ2をシーケンシャルに実行するようにすることも可能です。

1.2. スケジュール作成

1.2.1. ユーザー・ステージ

段階的にユーザー数を増やしつつ、システムの限界となる負荷を特定していく機能です。

例えば、2ユーザーで1分間、次に5ユーザーにして1分間負荷を掛けたい場合は以下のように設定します。

(1) スケジュール・プロパティーの「ユーザー・ロード」タブで、表示された行を選択した状態で「編集」をクリック


(2) 「ユーザー・ステージ」画面にて、以下のように指定し「OK」をクリック

  • ユーザー数に「2」
  • ステージ期間で「指定した期間実行」を選択して、「1」「分」と指定

これで「2ユーザーで1分負荷をかける」という設定になります。

(3) スケジュールの「ユーザー・ロード」タブで、「追加」をクリック

(4) 「ユーザー・ステージ」画面にて、以下のように指定し「OK」をクリック

  • ユーザー数に「5」
  • ステージ期間で「指定した期間実行」を選択して、「1」「分」と指定

これで「5ユーザーで1分負荷をかける」という設定になります。

(5) 設定が完了すると「ユーザー・ロード」タブは以下のようになります。


これで、2ユーザーになってから1分間、次に5ユーザーになってからにして1分間テストを実施する、という設定になりました。


basicscienceは何ですか

(6) 次に、スケジュールにテストを追加しますが、テストが上記で指定した時間(1分間)未満で終わってしまう場合には、無限ループを使ってステージが終わるまでテストが繰り返されるように設定します。


1.2.2. パフォーマンス要件

スケジュール・プロパティーにある「パフォーマンス要件」タブでは、パフォーマンスの許容可能なしきい値を指定して、スケジュールのパフォーマンス要件を定義することができます。

「パフォーマンス要件」タブの「パフォーマンス要件の使用可能化」にチェックします。

「パフォーマンス要件」リストから定義したいパフォーマンス要件を選択し、「演算子」と「値」を指定します。


上記の例では、「すべてのページ・エレメントの平均応答時間が500ミリ秒以下」というパフォーマンス要件を定義しています。この場合、平均が500ミリ秒以下であればテストは「成功」となります。

各ページや要求に対しての「パフォーマンス要求」の詳細な指定は、テストにて設定することができます。各エレメントの「テスト・エレメント詳細」の「拡張」タブで定義します。

「パフォーマンス要件のレポート」の出力方法は、「パフォーマンス・テストの実行」ビューより対象のテスト実行結果を選択し、右クリックのメニューから「パフォーマンス要件レポートの表示」を選択します。


「パフォーマンス要件レポート」は以下のように表示されます。


1.2.3. エラー処理動作

テストやスケジュールの実行時に、エラーとなる条件が発生した場合の動作を指定します。

「テスト・エレメント詳細」もしくは「スケジュール・エレメント詳細」の「拡張」タブを開き、「エラー処理」の「クリックして条件を表示」をクリックし、エラー条件のテーブルを展開します。


動作を指定したい条件のチェックボックスを選択し、表示される画面にて条件が発生したときに実行するアクションおよびログに記録するメッセージを指定します。


1.2.4. 考慮時間

スケジュール・プロパティーにある「考慮時間」タブでは、テストの各ページにある「考慮時間」を調整します。考慮時間の設定によって、負荷の調整が出来ます。


「記録済みの考慮時間の遅延期間の変更」については、以下の通りです。

【記録された考慮時間を使用】 記録された時の考慮時間を使用して、テストが行われます。

【固定の考慮時間を指定】 考慮時間に指定した時間が使用されます。

【パーセントによって考慮時間を増減】


「考慮時間のスケール」に指定された値(パーセント)によって、考慮時間が計算されます。パーセントは、記録された時の時間ではなく、指定された考慮時間に基づきます。

  • 値が100の場合は、考慮時間に変更がないことを示します。
  • 値が200 の場合は、考慮時間を 2 倍に変更します。 スケジュールは記録された時間の2倍の速度で、つまり、ゆっくり再生されます。
  • 値が50 の場合は考慮時間を半分に減らします。 スケジュールは 2 倍の速度で再生されます。つまり負荷が高くなります。
  • 値が0 の場合は、遅延がないことを示します。

【ランダムなパーセントによって考慮時間を変化】


指定したパーセントの上限および下限の範囲内でランダムに生成されます。パーセントは記録された考慮時間に基づきます。

例えば、下限に10、上限に90を選択した場合、考慮時間は記録された元の考慮時間の 10%から90%の範囲になります。ランダムな時間はこの範囲内で均一に分散されます。

1.3. リソース・モニタリング

RPTでのパフォーマンス・テスト実行時、テスト対象等のサーバーにおけるリソース使用状況のデータを併せて取得することが出来ます。

この節では、Windows環境でのリソース使用状況をモニターする方法、およびAIX(またはLinux)環境でのリソース使用状況をモニターする方法を説明します。

リソース・モニタリングについて、ヘルプに情報が記載されていますので、以下URLより併せてご参照ください。

ヘルプトピック「リソース・データのモニター」

1.3.1. Windows環境のリソース・モニタリング

リソース・モニタリング対象サーバーがWindows環境の場合、既存のWindowsパフォーマンス・モニターをデータ・ソースとして使用することが出来ます。

【設定手順】

(1) スケジュール・エレメントの詳細にて「リソース・モニター」タブを開きます。

「リソース・モニターを有効にする」にチェックをつけると、モニタリング対象サーバーがリストに表示されます。まだリストされていないサーバーを新規に追加する場合、「追加」ボタンをクリックして追加します。


(2) ロケーションを選択します。既存のロケーションがない場合、新規ロケーションを作成します。


(3) 「ホスト」の欄に、サーバーのホスト名(またはIPアドレス)を入力します。

続いて、データ・ソース欄で「Windowsパフォーマンス・モニター」にチェックを入れます。

また、中央の「ロケーション」タブにて、OSログイン情報を入力します。


(4) 「リソース」タブを開きます。

「選択されたカウンターのみを表示」のチェックを外すと、選択可能な全てのカウンターが表示されます。モニタリングしたいカウンターを全て選択し、「次へ」をクリックします。


中部大西洋岸の状態はどのですか?

続いて、データ・ソース欄で「Windowsパフォーマンス・モニター」にチェックを入れます。


(5) ロケーション情報を保存します。(※次回以降、既存のロケーションとして再利用できます)

ウィザードに従って、ロケーション名(任意)と、作成先プロジェクトを選択し、「終了」をクリックします。


(6) リソース・モニター対象のホストが追加されます。


上図に示される例のように、リソース・モニターが有効にされ、対象サーバーおよびリソース・カウンターを指定している場合、スケジュール実行時にリソース情報が収集されます。結果は、パフォーマンス・レポートの「リソース」タブに表示されます。

【Tips】

リソース・モニタリングを行う際は、RPT側マシンと、リソース・モニタリング対象サーバーの時刻同期を行ってください。時刻がずれていると、パフォーマンス・レポート上の表示時刻が一致しなくなります。

また、リソース・モニターの設定がうまく出来ない場合や、リソース・データが正しく収集されない場合、以下のポイントをチェックしてください。

  • 指定したサーバーのIPアドレス(またはホスト名)は正確ですか?
  • リソース・モニタリングを行うサーバーの認証情報は正しいですか?また、認証したユーザーのアクセス権に問題はありませんか?
  • サーバーのWindowsパフォーマンス・モニターの機能を使用可能にしていますか?
  • ネットワーク接続のプロパティーで、「Microsoft ネットワーク用ファイルとプリンタ共有」がオンになっていますか?

Windowsパフォーマンス・モニターを使用する場合の注意点が、ヘルプにも掲載されています。以下URLの情報を併せてご参照ください。

ヘルプトピック「Microsoft Windows パフォーマンス・モニターのソースの追加」

1.3.2. AIX(Unix)環境のリソース・モニタリング

リソース・モニタリングの対象サーバーがAIX(Unix)環境の場合、rstatdプロセスをデータ・ソースとして使用します。(サーバー側にrstatdが導入され、使用可能になっている必要があります)

RPTのスケジュールにて、リソース・モニターの設定を行う流れは、Windows環境のリソース・モニタリングの場合とほぼ同様です。設定前に、サーバー側(AIX)にてrstatdが使用可能になっている必要があります。使用可能でない場合は以下の手順にて設定します。

【rstatdの使用可能手順】

(1) /etc/inetd.conf ファイルを開き、rstatdのコメントアウトを外します。

(サンプル)

[修正前]

#rstatd	 sunrpc_udp	udp	wait	root	/usr/sbin/rpc.rstatd rstatd 100001 1-3

[修正後]

rstatd	 sunrpc_udp	udp	wait	root	/usr/sbin/rpc.rstatd rstatd 100001 1-3

(2) 手順①で更新したinetd.conf ファイルをinetdに再読み込みさせます。

(コマンドのサンプル)

RPT側では、「4.3.1. Windows環境のリソース・モニタリング」と同様、スケジュールの「リソース・モニター」タブにてサーバーおよびリソース・カウンターの追加を行います。

【RPTスケジュール設定手順】

※設定の流れは「Windows環境のリソース・モニタリング」と同様であるため割愛します

  • リソース・モニターの追加ウィザードにて、「ホスト名」を入力します。
  • 続いて、データ・ソースで「UNIX rstatd モニター」にチェックをつけます。
  • その後、「リソース」タブにて、データを収集するカウンターを選択します。
  • 最後に、「OK」をクリックして、サーバーおよびカウンターの追加を完了します。

設定中に、下図のようなエラーが発生した場合は、サーバー側のrstatデーモンが稼働していない(導入されていない)可能性が考えられます。または、ファイアウォールによって通信が妨げられていないかどうかを確認します。


【rstatdに関する考慮点】

ファイアウォールを使用する環境でリソース・モニタリングを実施する場合、rstatdとRPTが通信可能なようにファイアウォールの設定を行う必要があります。以下は、rstatdを使用する際に必要なポートの情報です。

(ただし、rstatdの仕様やrstatdが使用するポートの割り当てに関しては、OSの種類やバージョンなどに依存して異なる可能性があるため、当文書を持って動作を保証するものではありません。必ず、実際の環境に合わせて動作を確認してください。)

rstatdはRPCを利用するサービスであり、動的に割り当てられるポート番号でクライアントと通信する際にはportmapperサービスを利用します。

portmapperはWell-known portで稼働しており(デフォルトはTCP/UDP 111)、このポートにアクセスできるようにF/Wの設定を行う必要があります。またrstatdのポートが通信毎に動的に変わるため、全て(もしくは、特定のレンジ)のUDPのポートをアクセス可能にしておきます。もしrstatdに割り当てられるポートを固定したい場合には、OSごとに実現の可否や設定方法が異なりますので、ご使用のOSでの設定方法をご確認ください。

(情報源)

Using IBM Rational Performance Tester: Resource monitoring Part 3, Monitoring with UNIX/Linux rstatd (US)

rstatdを使用したリソース・モニタリングに関して、ヘルプにも説明が掲載されていますので、以下URLの情報を併せてご参照ください。

ヘルプトピック「UNIX rstatd ソースの追加」

1.4. Tips

1.4.1. 複数のテストを結合して一度に実行したい場合

複数のテストを順番に実行する場合には、スケジュールで実現します。


誰がオンラインコミュニティを設定する際に関与させるべきである
  • 同じユーザー・グループ内のエレメントは、上から順にシーケンシャルに実行される
  • ユーザー・グループに挿入した「遅延」の時間を調整することで、各ユーザー・グループをシーケンシャルに実行することも可能

以上のようなスケジュール機能の特性を利用し、複数のテストをまとめて実施するようなスケジュールを作成します。

1.4.2. スケジュールの確認

作成したスケジュールを、動作確認のため複数ユーザーで稼動確認を行います。

この場合、スケジュールを以下のような設定で実行します。

(1) テスト・ログ

テスト・ログにすべてのHTTPリクエスト、レスポンスが記録されるようにします。

動作確認時には、デバッグできるようにもっとも詳細なログレベルを指定します。

【設定値】

エラーおよび失敗の表示・・・すべて

警告も表示 ・・・すべて

他のすべてのタイプも表示・・・すべて

ユーザーのサブセットからのサンプル情報のみ・・・(チェックなし)


(2) ユーザー数

詳細なログを取得するため、少なめのユーザー数に設定します。

【設定値】 10ユーザー以下


(3) エージェント

複数エージェント使用時の挙動を確認できるように指定します。

【設定値】 本番テストで使用する全てのロケーションを追加


1.4.3. 同期ポイント

同期ポイントは、ユーザーを待ち合わせる機能です。例えば、「ログインは各ユーザーの間隔をあけて行いたいが、その後の更新処理は一気に負荷をかけたい」といった状況で使用されます。この場合、更新処理の直前に「同期ポイント」を設定します。解放のタイプは「同時」または「スタッガー」があります。「スタッガー」を選択すると、指定した時間内でランダムな間隔で全てのユーザーを開始することができます。

なお、同期ポイントはテストでも指定できますが、解放の定義はスケジュールでしか行えません。テストでは全ユーザーが同時に開始されます。

【設定方法】

エレメントを選択し、「オプション」→「同期ポイント」を選択します。


「パフォーマンス・スケジュール・エディター」ウィンドウにて同期ポイントの名前を指定し「OK」をクリックします。


同期ポイントは、選択したエレメントの上に挿入されます。

挿入された同期ポイントの「テスト・エレメントの詳細」で、解放の定義をします。

解放のタイプで「スタッガー」を選択した場合、同期ポイントからユーザーを1人づつ解放するため、解放するユーザーによるシステムへの過負荷が回避できます。


上記の例では、ユーザー・グループ1の全ユーザーが揃うまで待機し、全ユーザーが「同期ポイント1」に到達したら、

最小時間「0秒」から最大時間「60秒」の間にランダムな間隔で次のアクション(サンプル1の実行)を開始します。

2. スケジュールの実行

2.1. ロングラン、大規模ユーザーでのテスト

ロングランあるいは大規模テストを行う際には以下の点に注意します。

  • 1回のテスト実行時間が長くなるため、もし再テストを行う場合の時間は余裕を持って確保しておく
  • ログの量が非常に多くなるため、不要なログは取得しないように設定する

大量ユーザーテスト時も、上記と同様に、全ての仮想ユーザーのログを取得することは推奨されません。また、RPT側のシステムにかかる負荷を軽減させるため、複数台構成でのテストが推奨されます。

2.2. Tips

2.2.1. スケジュール実行結果の名前を任意に指定する方法

「実行の構成」からスケジュールを実行すると、任意のログ名を指定できます。テスト名、実施日、スケジュールで指定しているユーザー数、実行期間などをログ名に含めておくと、後に結果を振り返る際に見やすくなります。なお、RPT上のログ名と関連させて、手元のメモ帳や表計算ソフトなどを使って、実行し他テストのログ名と、実施した内容(ユーザー数、日時、テストした目的(デバッグ/本番)など)をメモしておくと非常に便利です。

【手順】

RPTのメニューバーより「実行」⇒「実行の構成」をクリックします。


左側メニューより「パフォーマンス・スケジュール」をダブルクリックします。


パフォーマンス・スケジュールの下に、New_configurationが生成されます。

右側ペインの「スケジュール」タブにて、実行したいスケジュールを選択します。


「テスト・ログ」タブに移動します。

「デフォルトを使用」のチェックを外します。


「名前」欄に、テスト・ログにつける名前を、入力します。

また、「ロケーション」にて、テスト・ログを出力するロケーションを明示的に選択します。


「適用」ボタンをクリックし、設定内容を保存します。

「実行」ボタンをクリックすると、本設定によるスケジュールの実行が開始されます。


2.2.2. 実行中のスケジュールを途中で停止する方法

実行中のスケジュールを途中で停止する場合、「パフォーマンス・テストの実行」ビューにて、現在実行中のテストが表示されている事を確認の上、右上にある「テスト実行の停止」ボタンをクリックします。



「テスト実行の停止」ウィザードが表示されます。テスト・ログを収集したい場合は、停止のオプション「テスト結果およびヒストリーの収集」にチェックをつけます。(※チェックをつけない場合は、ログは収集せずに終了となります)タイムアウト値はデフォルトで30秒ですが、確実に全テスト・ログを収集したい場合には、やや長めにタイムアウト値を変更することをお勧めします。(150秒~300秒程度など)

オプションを設定後、「OK」をクリックすると、スケジュールの停止が実行されます。


2.2.3. スケジュール実行時に、ユーザーを追加する方法

スケジュール実行中に、「パフォーマンス・テストの実行」ビューの右上にあるアイコン「仮想ユーザーの追加または除去」をクリックします。


ユーザー数の変更ウィザードが表示されます。

ユーザーを追加したい場合は、「ユーザーの追加」を選択し、追加したい人数を数値で入力します。入力後、「OK」をクリックしてウィザードを閉じます。


実行中のユーザーを減らしたい場合は、「ユーザーの除去」を選択し、除去したい人数を数値で入力します。入力後、「OK」をクリックしてウィザードを閉じます。


事前の設定でセットしたVU数でスケジュール開始後、実行中に手動でユーザーの増減を行うことが出来ます。


2.2.4. スケジュール実行時に、仮想ユーザーを監視する方法

スケジュール実行時に実行中の特定の仮想ユーザーがどのような振る舞いをしているか、ブラウザーで確認することが出来ます。

【確認方法】

スケジュール実行中に、「プロトコル・データ」ビューを確認します。

ビューの右上にある「仮想ユーザーの監視」ボタンをクリックします。


ユーザーの選択ウィザードが表示されます。

1度に監視可能な仮想ユーザーは1つです。いずれかの仮想ユーザーを選択します。

仮想ユーザーの属する「ユーザー・グループ」と、番号(入力可能なアクティブ・ユーザーの番号を入力のこと)を選択し、「OK」をクリックします。


選択した仮想ユーザーのイベントが、「イベント・ログ」タブで確認可能になります。

その他のタブ(要求、応答、ブラウザーなど)でも、リアルタイムでデータが表示されます。


現在選択中の仮想ユーザーの監視を停止したい場合は、ビュー右上にある「監視の停止」ボタンをクリックします。



ダウンロード

内容ファイル名サイズダウンロード形式
第3回 スケジュールの作成と実行Hints&Tips編rpt_practicalguide_part3.pdf1.86MBHTTP

ダウンロード形式について          Adobe® Reader® が必要

著者について

森田 成紀, Rational Client Technical Professionals, IBM

お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。 プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。 お客様の姓名(非表示設定にしていない限り)とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

この記事を評価する

コメント



These are our most popular posts:

動的 Web アプリケーションのアーキテクチャの決定 : パフォーマンス ...

2001年3月1日 ... NET Academic について. Visual Studio . ... これには、さまざまな展開オプションや 構成設定によるベンチマーク テストの結果が含まれています。 日本語編集注: この記事 の本文 ..... このテストは 1 年前に行われたので、その後パフォーマンスや スケーラビリティに影響するような変化が何かあったでしょうか ? 実は、2 つの大きな ... read more

第2言語習得 (SLA) 用語集

よってaccidental gapの語が産出された場合、その学習者はovergeneralization (過剰 般化)を起こしていると考えられる。 ..... テスト作成において感情的な話題を使用する 必要がある際には、パフォーマンスがどのように感情から影響を受けるかを考える必要 がある。 ..... ■cognitive academic language proficiency (CALP: 認知・学習言語 能力) ... read more

Rational Performance Tester 活用ガイド: 第3回 スケジュールの作成と ...

2011年4月1日 ... 単位時間あたりのトランザクション量は、テスト対象サーバー側のパフォーマンス によっても影響を受ける値であるため、RPTの設定にて正確な値を指定し実行すること は出来ません。従って、実際にテストを実行してみた上で負荷の量を調整し ... read more

帰国子女の国・何年いたかの追跡調査

発表語彙知識がスピーキングパフォーマンスに与える影響:日本人初級者を対象に」. 小泉利恵 (筑波大学大学院博士 ... 研究の目的:「発表語彙知識が、スピーキングテスト ・パフォーマンスにどの程度影響するか」について検討. ・日本人英語初級者に対象を 絞る ... read more

0 件のコメント:

コメントを投稿