前回、負荷テストの対象となるサンプルWebアプリケーション用スクリプトを作成したのを覚えていますか？
すでに、VUgenを閉じてしまっているのであれば、前回記述した手順で起動してみてください。
VUGenが起動したら、前回保存したスクリプト（私は前回「WebSample」という名前で作成して保存しました）を開いてみましょう。
VUGenの「ファイル」-「最近のスクリプトおよびソリューション」にマウスで選択をすると、前回保存したスクリプト名があるのがわかりますか？
もし、前回作成後にいくつも試しに自身でつくられたものがある場合は、一般的なWindowsアプリケーションと同じように「ファイル」-「開く」を選択して、実際に保存した先から開くということもできます。
では、保存したスクリプト名をクリックして開いてみましょう。
負荷テストを実行する前に、スクリプトにトランザクションという設定を編集してみましょう。このトランザクションは設定しなくても負荷テストは実行できますので、もし面倒だと思われたら飛ばしてもかまいません。
トランザクションとは、負荷テストで単純にページ単位での応答時間を計測するだけではなく、一定の処理、例えば、このサンプルアプリケーションの例で言うと、該当航空便のチケットを探すまでに、
- 航空便検索画面を表示
- 出発地、到着地、日にちなどを入力
- 該当便で予約可能なリストが表示
- そこから購入したい便を選択して次の画面へ遷移
- という一連の手順のトータルの時間を計測したい場合があります。
- もっといい例をあげると、サンプルWebアプリケーションではありませんが、検索キーワードを入力すると、「検索中」という画面が表示されて待たされ、実は裏でWebページのリロードが結果が表示されるまで、実行されているWebアプリを想像してみてください。
- テスト担当者としては、ページ数がどのくらいカウントされるか不明だけども、処理としての応答時間はその1作業だけで計測したいですよね？
- こういう場合に、トランザクションというのを使うと有効です。では、設定してみましょう。VUGenの左下にタブがあります（下図参照）、この「ステップナビゲータ」をクリックしてみてください。
すると、ステップナビゲーターには、スクリプトのステップ（Webサーバーへの送信単位と思考遅延時間）が表示されているのがわかると思います。
これは前回記録したスクリプトがこのようなステップでサーバーとやりとりしているというのを把握するのに便利な機能です。思考遅延時間は、通常、人の操作を考えると、数秒まって（画面内容を確認、操作して）から次の画面へ遷移しますよね、それにかかる時間を思考遅延時間といいます。
これは、重要です。よく、TPSをあげるために遅延時間を0にして負荷テストされる話を聞きますが、問題を含んでいます。それについてはまたの機会にして、今回はそこまで踏み込みません。もし、ご興味があれば、HPでは負荷テスト講座がありますのでご紹介しますので、お問い合わせください。
では、トランザクションを設定してきましょう。先ほど説明したこの操作のトータル時間を計測したいと思う、操作部分のステップをまず調べます。VUGenの右下のタブで「サムネイルエクスプローラ」を選択すると、サンプルWebアプリケーションを操作した時のGUIが表示されるのがわかると思います。ここを見やすいようにある程度広げた状態にして、ステップナビゲータであたりをつけたステップをクリックしてみてください。該当ステップの画面がサムネイルエクスプローラに表示されると思いますので、ここから、計測したい操作の開始ステップ、終了ステップを確認しておきます。
そして、計測を開始したいステップを選択した状態で、ツールバーから「デザイン」-「スクリプトに挿入」-「トランザクションの開始」をクリックしてください（下図参照）。
「トランザクションの開始」がクリックされると、スクリプト内の該当ステップ部分にマウスが自動でフォーカス移動しますので、
lr_start_transaction("トップ画面");
というように、計測したい操作の名前を入力します（この例では「トップ画面」）。
同様に、計測を終了したいステップを選択した状態で、ツールバーから「デザイン」-「スクリプトに挿入」-「トランザクションの終了」をクリックしてください。
すると、「トランザクションの終了」がクリックされると、スクリプト内の該当ステップ部分にマウスが自動でフォーカス移動しますので、こちらも同様に、
lr_end_transaction("トップ画面" , LR_AUTO);
というように、計測したい操作の名前を入力します（この例では「トップ画面」）。
ポイントは、開始と、終了で同じトランザクション名にしておかないと計測ができないという事です。また、トランザクションはオーバーラップも可能ですから、あるトランザクションの途中で別のトランザクションの開始や終了があるといういのも計測できます。
では、ここで、スクリプト編集は終了し、実際に負荷テストを実施する事にしてみましょう。
ここからは、VUGenではなく、Controllerを使っていきます。
前回にも説明しましたが、負荷テスト全体の指示やサーバー側のモニタリングをする機能モジュールを実装しています。ランプアップ、ランプダウン、ランデブーもこのControllerを利用して設定していきます。
みなさんのデスクトップ上にControllerのアイコンがあると思います（下図）ので、こちらをダブルクリックして、作成したスクリプトを選択するという方法もいいですが、今回はもっと簡単な方法でControllerを起動させてみましょう。
では、VUGenでスクリプトを開いたままにした状態で、ツールバーから「ツール」-「コントローラシナリオを作成」をクリックしてみましょう（下図参照）。
すると、次のようなポップアップウィンドウが開きましたでしょうか？ここからは、負荷テストをどうやるかという設定をしていく事になります。コントローラでは、このように、どのような設定で負荷をかけるかという設定を「シナリオ」といいます。シナリオを保存して、再利用することで、いつでも同じ設定で負荷テストを実行する事ができます。
負荷テストは一度でOKということはめったにありません。何度も繰り返しますし、前回と今回といった、過去の結果との比較も必要になりますから、設定が毎回手動でやっているとほんとに同じ条件設定だったか怪しくなります。そこでシナリオはとても有効です。
では、設定しましょう。タイプとて大きく、「ゴール指向シナリオ」と「マニュアルシナリオ」があります。
このゴール指向というのはその名のとおり、目的としての数値があり、その数値を満たすように負荷が実行されるというものです、ゴールとしては、次のようなものがあります。
- 同時接続ユーザー数
- ヒット数/秒
- トランザクション数/秒
- ページ/秒
今回は、ゴール指向シナリオではなく、マニュアルシナリオを設定して、「仮想ユーザーの数」に負荷をかけたいMAX数を設定しています（この例では5ユーザーによる接続を想定）。
ライセンス購入されなくても、デフォルトでLRv12からは50ユーザーまで無償で利用できますので、購入されていなくても50までは設定して実施できます。
ただ、気をつけて欲しいのが、今回、LRv12がインストールされたマシンに、サンプルWebアプリケーションがインストールされており、さらに、この後説明する負荷を生成するLoadGeneratorもインストールして稼動してますので、ある程度のスペックがないとリソースが逼迫してしまうかもしれません。
次に、負荷を生成するLoad Generator（ここではローカルマシンのLoadGeneratorを設定）、グループ名に作成したスクリプト名、テスト結果を保存するディレクトリを指定し、「OK」をクリックします。
負荷を生成するマシンはローカルマシンではなくていいですし、別マシンでかつ並列的に追加して生成量を増やしていく事ができますが、リモートのLoadGeneratorについては別の機会にして、今回は3回目でLRv12をインストールした時に同時にインストールされたローカルのLoadGeneratorを利用しましょう。
「OK」をクリックすると、次のようにシナリオを生成する準備がはじまります。
自動で次の画面が開きましたか？
これが、Controllerというツールの操作画面になります。
まず、最初に、画面の左上をみてもらうと、先ほど選択したスクリプトと負荷想定ユーザ数の5、それを実行するLoadGeneratorが設定されているのがわかると思います。
その下の左下には、どのようにユーザー数をあげていくか（ランプアップ）、どのくらいの期間実行するか（実行時間）、どのようにユーザー数を終了していくか（ランプダウン）を設定する、「シナリオのスケジュール」があります。
右はその全体スケジュールで設定した内容を図として分かりやすく表示したものになります。こちらの図を操作する事で設定を行う事もできます。
右上にあるのは、サービスレベルアグリーメント（SLA）を設定する画面で、例えば、次のようにトランザクションを選択して、パーセンタイルでSLAの閾値を設定し、超えたかどうかを確認すると言った事ができます。
今回は設定しません、またの機会とします。
「シナリオのスケジュール」をデフォルトから変更してみましょう。まず、「アクションの編集」をクリックしてください（下図参照）。
すると、まずは、「アクションのタイプ」で「初期化」というのが開きます。これは、仮想ユーザを生成するときに最初に全部のユーザーを起動させておくか、都度、起動させるか、一定間隔をおいて起動させるかという指定をします。
これが何の影響があるの？と思われるかもしれませんが、LoadGeneratorで仮想ユーザーを起動する際には、当然、メモリーと起動処理のためのCPUを消費します。十分に余力があるマシンなら、都度起動してもいいですが、そうでもない場合は、あらかじめ最初から起動しておくというのも設計の選択肢になります。
今回は、デフォルトで都度作成する「各仮想ユーザーを実行直前に初期化する」を選択して「OK」をクリックしてください。
次は、「仮想ユーザー開始」です。ここでは、どのように仮想ユーザーを増加させていくか（ランプアップ）を設定します。デフォルトは次のようになってますよね？
それを次のように、1ユーザーづつ、5秒ごとに増加させる設定にしてみましょう。
設定したら右下の「適用」をクリックして「次へ」をクリックします。
次は、「実行時間」です。要はどのくらい負荷を実行かけ続けますかという時間の設定です。
デフォルトは5分になってるかと思いますが、ここでは、3分に設定し、「適用」をクリックして「次へ」をクリックしてみましょう。
最後は「仮想ユーザの停止」が開きます。ここでもデフォルトから、2仮想ユーザーづつ、10秒ごとに終了させると編集して、「適用」し、「OK」をクリックします。
すると、これまで設定した内容が、「全体スケジュール」と同時に、右の「対話式スケジュールグラフ」にも反映して表示されているのが分かると思います。
このようにLRv12では、容易にシナリオを設定する事ができます。
では、いよいよ実行していきます。左したにあるタブから「実行」をクリックしてみましょう（下図）。
すると次のような画面が表示されます。先ほど作成した、シナリオを実際に実行するための機能が集約されています。
実行中のリアルタイムなステータスもこの画面にでてきます。軽くまとめてみます。
- 左上「シナリオグループ」 スクリプトグループ単位で、どのくらいユーザーが実行しているか、エラーがどのくらい発生しているか、終了したのか、といった情報を目視できます
- 右上「シナリオステータス」 全体の実行中ユーザー数、成功・失敗トランザクション、エラー情報を可視化（エラーの詳細はエラーリンクをクリックすると見る事ができます）
- 中央以下「利用可能なグラフ」 リアルタイムにどのくらいの仮想ユーザー数が起動しているか、トランザクションの時間はどのくらいか、ヒット数/秒はどのくらいなのか、対象システムのリソースなどメトリック情報の取得を表示します
今回は、LRv12をインストールしたマシン上に負荷テストの対象となるサンプルWebアプリケーションが稼動しているので、リソース収集として、このローカルマシンのリソースを取得していきます。LRv12では、リソースを取得するために、
- 標準モニタリング
- SiteScopeモニタリング
を利用できます。SiteScopeとは、HPの運用監視で実績のあるエージェントレスリソースモニタリングであり、監視対象や安定性の上で有効なモニタリングです。ただし、無償で利用できるLRv12コミュニティ版では、利用できません。
Entitlement利用権を購入いただければ、SiteScope2000メトリック使用権がつきますので、興味がある方は担当営業かパートナー様まで問い合わせください。
ここでは、無償で利用できる範囲として標準モニタリング機能を利用して、ローカルホストのWindowsリソースを取得してみましょう。「利用可能なグラフ」の右側には実行中のリアルタイムモニタリングが実装されています。デフォルトで4枠あります（追加・削除できますが、ここでは4枠のまま利用しましょう）。ここで、一番右下の「Windowsリソース」を右クリックしてみましょう（下図参照）。 そして「測定値の追加」をクリックしてみてください。
次のポップアップウィンドウがでてきましたね？さっそく追加してみましょう。「監視するサーバマシン」の「追加」をクリックしてみてください。
すると、次のポップアップがでてきます。「マシン情報」の「名前」でホスト名を記入しますが、今回は、ローカルホストのリソースを取得するので、
localhost
と入力してみましょう。次に、「プラットフォーム」ですがここは、＜＜一番近いプラットフォーム＞＞を選択してもらいます。というのも、LRv12では選択できるWindowsプラットフォームとしてWindows7、Windows8、 Windows2012がキチンとプリセットされていません。そこで、今回ローカルホストは、Windows7なのですが、一番近いWindowsVIｓtaを選択しています。選択したら「OK」をクリックしましょう。
すると、次のように、取得する監視するサーバマシンとしてローカルホストが追加され、リソース項目も一覧として表示されているのがわかります。項目は追加する事ができますが、ここではデフォルトのままでいきましょう。
また、分かる方はすぐ分かると思いますが、この項目は、Windowsの「パフォーマンスモニター」と同じ項目です。
もし、ローカルホストじゃなく、リモートのWindowsマシンを設定しようとした方はいませんか？？もしいたとすると、次のように「ログイン情報の入力」を聞かれたと思いますが、これはリモートでWindowsのパフォーマンスモニターを利用するときに聞かれる情報と同じで、リモートのWindowsマシンにアクセスためのユーザ名とパスワードになります。
それから、モニタリングするために、NETBIOSで通信するために、Controllerマシンから、対象のリモートWindowsマシンにNETBIOSでアクセスでき、パフォーマンスモニターを利用できる権限が必要です。当然、NETBIOSですからポート番号139もリモートWindowsマシン側で空けていないといけません。
また、Controllerとリモート側Windowsマシン間にファイアウォールがある場合は当然、ここもNETBIOSが通過できるようにしておく必要があります。
と、リモートのWindowsマシンの場合は注意点がありますが、今回は、ローカルホストですので苦労せず取得できるはずです。どうですか？
Windowsリソース取得は設定するとすぐに、負荷テストを実行する前でも収集が始まりますので、もしエラーがあると、「シナリオステータス」の「エラー」に表示されますので、エラーがカウントされたら、詳細をみて内容から、何が問題か切り分けをすることになります。
次に現在ローカルホストのLoadGeneratorがこのスクリプトグループに割り当てられていますが、デフォルトではダウン中なので、それを起動していきましょう。Controllerのツールバーから「Load Generators」をクリックしましょう（下図参照）。
すると、現在設定しているLoad Generatorのリストが表示されます。今回はローカルホストのLoad Generator1つだけがリストに表示されているのが分かると思います。
また、この画面から追加の別マシン上のLoad Generatorを追加したり、LRv12の新機能であるクラウド上のLoad Generatorを追加するという事もできます（現在はまだAWS上のみ）。
リストのカラムにある「ステータス」を見てみてください、ダウンになってますね、これはまだ利用するLoad Generatorとしてリストには追加されているが、Controllerとキチンと接続して起動してない事を意味してます。そこで、選択した状態で右側にある「接続」をクリックしてみましょう。
どうでしょう？無事「準備完了」になりましたね？そうしたら「閉じる」をクリックしましょう。
はい、ここまでで負荷テストを実行するのに必要な最低限の準備はできました！いよいよ、負荷テストを実行していきましょう！
「シナリオステータス」にある、「シナリオの開始」をクリックしてみてください！
シナリオステータスのところに「実行中」と緑色で出てきましたよね？？はい、負荷テストが実行されているんです。
もう少しみてみましょう。左上の「シナリオグループ」をみてみましょう、ここでグループのカラムをみてみてください。
「ダウン」が4、「実行」が1になってますね。これは、もともと仮想ユーザとして5を準備していましたね？
その5のうち、その時点でランプアップ設定により、1仮想ユーザが実行中で、4仮想ユーザはまだ実行されない状態にあるという事を意味してます。ランプアップ設定について、わからなくなったら、今回のシナリオ設定のところを再度読み直してみてくださいね。
しばらくすると、ランプアップ設定にもとづき、5仮想ユーザ全部が実行状態になるはずです、その時点のスナップショットは次のようになります。みなさんのマシンでも同じようになりましたね？？どうですか？？
リアルタイムモニタ情報をみてみましょう。下記図のようにデフォルトで設定した情報だと、仮想ユーザ数の増減情報、トランザクション応答時間、秒ごとヒット数がリアルタイムに表示されるのが分かりますね？
実際に本格的に使っていくには、初期のボトルネック判断で大まかにあたりをつける粒度として、どのような値を計測するか、開始前にメンバーで相談しておきましょう。
お、私の環境では、「シナリオステータス」の「エラー」にカウントがありました！
なんかエラーが起きたんですよ・・・いったいどんなエラーなのか見てみましょう。「エラー」のカウントした数字部分がリンクになってますのでクリックしてみましょう（下図参照）
すると、大きく2つのエラーがでてるのがわかります。特に回数が多いのは2つ目の方でメッセージ合計をみると4回カウントされています。さらに、ここで、この2つ目をクリックして詳細をみてみましょう。
詳細が表示され、メッセージ合計にあった4つのメッセージが表示されます。この場合、たった、仮想ユーザが5で思考遅延時間も人の操作に近いものでしたが、非力なマシンであったことと、対象Webアプリケーション、Controller、LoadGeneratorがすべてローカルホストで実施していた関係もあり、CPUの使用率が80％を超えてしまったためにエラーとして検地されました。
もうひとつのエラーのほうは、このCPU使用率が超過したために、チケット検索の送信メッセージの応答でエラーが発生したのが原因なのですが、ここでは、説明は省きます。
実際のテストでもそうですが、ある程度、エラー原因の仮説と検証を繰り返す事で、原因を切り分け、絞込みをしていきます。一般にボトルネック分析というスキル＆ナレッジが必要な所です。
本来、負荷テストでテスト担当者がフォーカスしたい部分はこのボトルネック分析部分ですよね？
そのために、スクリプト作成や編集、負荷テストシナリオ作成や実行、モニタリング、レポート作成は楽にやりたいですよね。という視点でツールを選択するとどのツールが自分達のチームに向いているか分かると思いますので、ちょっと皆さんのチームで機会があったらディスカッションしてみてください。
では続けましょう。シナリオが設定した時間どおり終了した事を確認します。
（シナリオグループの「中止」が5になって、「シナリオの開始」ボタンが有効になってますね）
エラーが多発していますが、この例では、上述のCPU高負荷によるものですので、追加の説明は省きます。
どうです？（エラーが起きたとしても）終了しましたね？
おさらいですが、前回作成した負荷テスト用スクリプトを使って、シナリオ（ランプアップ、ランプダウン、仮想ユーザ数、LoadGenerator設定）の設定方法、標準モニタリングを利用したリソース収集の設定方法、エラー内容の詳細表示の方法をやってみました。
次回は、ようやく後編としてこの負荷テスト結果を利用してAnalysisでレポートを作成してみます！
今日はいろいろ操作ポイントがでてきて大変だったと思います・・皆さんお疲れ様でした。また次回！