「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
負荷テストをスムーズに計画・実行できるようにコンテンツを作成してみました。
負荷テストとは？ †
負荷テストの概要図 †
単純に、Webアプリケーションだけに対して負荷をかけることもできるが、
以下のようにネットワーク機器など含めた本番稼働構成に対する性能検証も可能。
この場合、単純なリクエスト－レスポンス間の時間測定だけするのではなく、
各サーバーや機器のパフォーマンス カウンタなどのパフォーマンス情報を収集し、
ボトルネックが無いか？などを調査する必要がある。
負荷テストのスクリプト作成 †
- 負荷テストでは、以下のような実行毎に変わる可変値を
正規表現などを使用して抜いて引き継ぐ処理が必要になるケースがある。
以降コレを「可変値の追跡」と呼ぶ。
- また、ユーザ入力やユーザ操作をシミュレートする必要になるケースもある。
可変値の場所 †
post、url、htmlなどに含まれる値。
- ヘッダ部
- Cookie
- Session Cookie
- Cookie認証チケット
可変値のユースケース †
- 実行タイミング次第で可変となる値。
- ランダム値が使用されていて可変となる値。
- 乱数
- GUID, UUID
- Temporary Password
- DBMSの
- Timestamp値
- Identity列やSequence値
- ログイン・ユーザ毎に可変となる値。
- ログイン・アカウント
- ユーザ毎の結果セット
- 結果セットから選択したデータ
スクリプトによる可変値の追跡 †
アプリケーションの仕組み次第では、データストアを初期化すれば、
取得した電文の再送だけで、負荷テストが可能なケースもあるが、
- 実行タイミング次第で可変となる値がある。
- ランダム値が使用されていて可変となる値がある。
- 多重ログインが不可能な仕組みがある。
のような処理がある場合、
が必要になる。
このため、負荷テストでは、スクリプト作成が必要になる。
このように「可変値の追跡」が必要になる負荷テストは、HTTPを使用するWebアプリケーションでは容易であるが、
バイナリ電文を使用するリッチクライアントの場合、型情報を取り込む必要があるので、容易ではない。
（...と言うか、実質的に汎用的な負荷ツールでバイナリ電文の実行で負荷をシミュレートできないことが殆どである）。
負荷テスト・ツールの機能 †
負荷テスト・ツールは、以下のような機能を持っている。
電文のキャプチャとスクリプトの生成機能 †
- 電文キャプチャとスクリプト（修正前のテンプレート）を生成する。
- 専用ブラウザを持つツールと、HTTPプロキシのように動作するツールがある。
HTTPプロキシのように動作するツール †
- GUIを持たないWebAPIの負荷テストの場合は、コチラを使用する必要がある。
専用ブラウザを持つツール †
- レグレッション・テスト（回帰テスト）を実行可能。
- この場合、ブラウザ上の操作手順やjavascriptなどのイベントをシミュレートできる。
- ただし、レグレッション・テスト（回帰テスト）用であり、負荷テスト用のスクリプト再生には使用できない。
- また、スクリプトを再実行して
「スクリプト（操作）の記録時」と「テスト時」の
値の差異を検出し、追跡が必要な可変値をサジェストする。
スクリプトの編集機能 †
可変値の追跡 †
- スクリプト生成時に自動追跡するツールもある。
- 以下のケースでは自動追跡できないので、手動でスクリプトを修正する。
- ユーザ毎に別々の入力値が必要になる場合
- JavaScriptにより複雑なパラメータを動的に生成している場合
- クライアント側で、Cookieを生成している場合
ユーザ毎の入力 †
準備したユーザ毎の入力値を、実行時に投入する。
デバッグ方法 †
- エラーが発生した際は、見極めが必要になる場合がある。
- アプリケーション・エラーか？
- それ以外のアプリケーション上の問題か？
仮想ユーザ毎のスクリプト実行機能 †
- 仮想ユーザ毎にスクリプトを実行する。
- 多重度を上げるため、1 Thread = 1 Userに見立てて負荷をシミュレートする。
- この際、ユーザ入力の思考遅延時間をシミュレートする。
エージェント機能 †
１つのスクリプトやシナリオを複数のマシンを使用して負荷を書ける場合、
各マシンにエージェントをインストールし、
コントローラからエージェント経由で各マシンを制御する。
シナリオの組み立てと実行機能 †
- シナリオでは、複数のスクリプトを組合せて本番環境に近い負荷をシミュレートする。
- このシナリオを組み立て、シナリオに従い仮想ユーザ毎にスクリプトを実行させる。
- シナリオの作成準備として、まず、指針となる「測定モデル」を作成する必要がある。
測定モデル †
「測定モデル」は、下記のマトリックスのことで、
| トランザクション種別 | 機能名 | 実行ユーザ比率 | スクリプト名 |
| 参照系 | 機能A、機能B | 例：70％ | スクリプトA、スクリプトB |
| 更新系 | 機能C、機能D | 例：20％ | スクリプトC、スクリプトD |
| 追加、削除系 | 機能E | 例：10％ | スクリプトE |
- 「トランザクション種別」毎に「機能」を抽出し、
- 「トランザクション種別毎」の「実行ユーザ比率」を設定し、
作成する。
機能抽出 †
- 「機能」を抽出する際、負荷テストの対象となる
- 「代表的なパターンの抽出」という観点だけでなく、
- 「ボトルネックの発見」という観点も含めると良い。
- 例えば、
- 重要な機能
- 複雑な機能
- その他、性能的に問題がありそうな機能
に、「ボトルネック」がないかどうかチェックすることは重要である。
シナリオ作成 †
- 「測定モデル」を参考にして、
- 「代表的なパターン」や、
- 「ポイント機能を含むパターン」を、
シナリオとして作成する。
となる。
- シナリオの編成の例
| シナリオ | 仮想ユーザ数 |
| 参照系 | 更新系 | 追加、削除系 |
| シナリオ1(10ユーザ) | 7 | 2 | 1 |
| シナリオ2(30ユーザ) | 14 | 4 | 2 |
| シナリオ3(70ユーザ) | 35 | 10 | 5 |
| シナリオ4(100ユーザ) | 70 | 20 | 10 |
※「仮想ユーザ数」が「測定モデルの実行ユーザ比率」に必ずしも準拠する必要はない。
レポーティング機能 †
- 経過時間と、仮想ユーザ数/平均レスポンスタイム/スループットのグラフ
- パフォーマンス カウンタなどのパフォーマンス情報を収集
アーキテクチャと負荷テスト †
Webアプリケーション（+HTTP） †
HTTPはHeaderからBodyまで、全てテキスト表現となっているため、以下手順に従い、
負荷テスト・ツールを用いてスクリプトを作成し負荷テスト・シナリオを作成しやすい。
- Webアプリケーションをブラウザから操作しながら、
HTTP電文をキャプチャしてスクリプトを生成する。
- 作成したスクリプトを実行し、
アプリケーションが動作する（負荷をシミュレートできる）かを確認する。
- アプリケーションが動作しない（負荷をシミュレートできない）部分を確認し、スクリプトの修正を行う。
- 動的に変更される可変値の追跡を行う。
- ユーザ入力をシミュレートする。
例えば、多重ログインができないシステムであれば、
仮想ユーザごとに使用するユーザIDを変更するようにする。
- スクリプトを実行して、サーバーに負荷をかける。
- スクリプトを組合せ負荷テスト・シナリオを作成し実行する。
リッチクライアント（+バイナリ電文） †
バイナリ電文 †
- バイナリ電文はC構造体や.NETオブジェクトのバイナリ表現になっている事が多い。
- このため、バイナリ電文を使用するリッチクライアントの負荷テストは、
HTTPに特化した負荷テストツールでは実行が困難である。
- バイナリ電文の負荷テストが困難な理由は、
- 電文再送で負荷がかけられるような単純なサーバー機能でない限り、バイナリ電文は型情報が無いと上手く処理できない。
- 殆どのビジネス・アプリケーションでは、その仕組み上、単純なバイナリの電文再送では負荷をシミュレートできない事が多い。
等である。
- 結果として、バイナリ電文を使用するリッチクライアントの負荷テストは、
クライアントサイドのシミュレータやスクリプトなどを開発して負荷をシミュレートする事が多い。
回帰テストツール †
以下のような、回帰テストツールもあるが、
負荷テストは、多重実行など、回帰テストツールでの代替が難しいため、
同様にクライアントサイドのシミュレータやスクリプトを作成して再生することが多い。
3層 C/S、2層 C/S †
- 3層 C/Sの場合、
基本的にシミュレータやスクリプトを作成して負荷テストを実行する。
- P層 / B層(D層)が適切にクラス分割されていれば、
3層C/Sのようなシミュレータやスクリプトを作成しやすい。
.NETの場合 †
Webアプリケーション †
以下がポイントのもよう。
- HTTPクッキーマネージャを設定（Session利用時）
- EVENTVALIDATIONの引継を設定
EVENTVALIDATIONは、EnableEventValidation? = true の際に
生成され、PostBack?およびCallbackイベントを検証するための情報。
これにより、Response・PostBack?間で保存 → 復元される値が、
改ざんされていないかどうかをチェックするようになるので、
Response・PostBack?間で保存 → 復元される値が、
動的に変更になるような場合は、可変値を追跡する必要がある。
- CSRF(XSRF)対策用のTokenの引継を設定
- CSRF(XSRF)対策用のTokenの引継を設定
リッチクライアン †
は、前述の方法を参考にする。
参考 †
Tags: :テスト
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
