Comments
Description
Transcript
実証実験ガイドライン（PDF/111KB）
＜実証実験ガイドライン＞ 1. テスト目的 (1)利用企業保有のアプリケーションを仮想環境上へ移行し、サービス開始する前に、 本実験環境を利用して、性能検証を実施することを目的としています。 A. 性能検証におけるテスト種類とその定義を以下に記載します。 本性能検証においては、下記の順番で実施してください。 ストレステスト→ベースラインテスト→パフォーマンステスト a. ストレステスト トランザクションを大量に発生させるテスト CPU、メモリが高負荷になったとき、システムの挙動が正常に行われるかを確認します。 b. ベースラインテスト 通常と考える負荷条件で、システムの性能基準を測定するテスト パフォーマンステストを行ううえでのベースラインとなります。 c. パフォーマンステスト 負荷レベルを変えてシステムパフォーマンスを計測するテスト システムの性能特性を確認します。 d. スケーラビリティテスト キャパシティプランニングのためのテスト 予想される負荷増大に対してシステムの拡張性が十分であるかを確認します。 e. ボリュームテスト データを大量（件数またはサイズ）に扱った場合のテスト f. ロングランテスト 長時間にわたって、一定の負荷をかけ続け、パフォーマンス低下しないか、またはシス テムの挙動が正常に行われるかを確認します。 B. 本性能検証にて実施いただくシナリオのガイドラインを以下に記載します。 以下から利用企業が実験結果として必要シナリオを確定して実施してください。 a. ログイン/ログアウトのみのシナリオ 認証のオーバヘッドを確認します。 Web アプリケーション系のみ。 b. 検索や閲覧を行うシナリオ 参照系のアクセスの性能を確認します。 Web アプリケーション系/バッチ系両方。 c. 購入や申請を行うシナリオ 更新系のアクセスの性能を確認します。 Web アプリケーション系/バッチ系両方。 d. 上記 c.と d.を複合のシナリオ 参照系と更新系のアクセスを複合した場合の性能を確認します。 Web アプリケーション系のみ。 C. 実施いただく本性能検証の目標値のガイドラインを以下に記載します。 以下の 3 点に関しては、収集/分析して報告ください。 a. スループット Web アプリケーション系の場合、秒間あたりのトランザクション数（ユーザがログイン してから必要な操作をすべて終わるまでを 1 トランザクションと定義） b. 同時接続ユーザ数 同じ時間帯に接続して利用しているユーザ数 c. 応答時間 シナリオ毎の応答時間（今回はサーバ内応答時間） 例えば Web アプリケーション系の参照系は 3 秒、更新系は 5 秒 (2) 検証するアプリケーションは、インターネット環境にて稼動実績があるものでお願いします。 機能検証を目的としていませんので、開発中で安定性に懸念のあるアプリケーションは避けてくだ さい。 (3) 本検証を実施する仮想サーバ上にインストールする OS、ミドルソフトウェアのバージョンを含め た一覧表を作成しておくことをお薦めします。 また、今後のセキュリティ、安定性の観点から本実験環境の提供ベンダのサポート範囲内で OS・ミ ドルウェアは可能な限り、最新のバージョンを使用することをお薦めします。 (4) 本来、仮想化環境は性能改善のためにスケールアウト可能とする前提ですが、最終的にボトルネ ックとなるタイミングがどの程度のシステム規模なのかを本検証にて確認することが有益と考えま す。 2. テストの流れ (1) 具体的なテスト項目とスケジュールを作成します。 なお、性能検証は複数回実施する前提でスケジュールを作成してください。 A. 性能検証にて準備に必要とされる工数のガイドラインを以下に記載します。 a. テストシナリオ（含むスクリプト）作成 ： 1 週間程度 ※ 下記(5)にて具体的な方法を記載しています。 b. サーバリソース収集/分析準備 ：3 日間程度※ 下記(6)にて具体的な方法を 記載しています。 c. テスト用データベース（DB）作成 ：2 日間程度 ※ 下記(2)にても記載しています。 (2) テスト準備を行ってください。 別途本実験環境の提供ベンダから事前案内がありますが、OS、ミドルソフトウェアを含めアプリケ ーション稼動に必要なソフトウェアはライセンスを含めて、用意してください。 また、テストにて使用する DB データまたはデータファイルは、性能検証時に増幅可能なものを除 き、事前にインポート可能な状態にしてください。 (3) 本実験環境上に検証アプリケーションシステムを構築します。 構築後、テストシナリオが流れる（＝機能に問題がない）ことを確認してください。 また、前記のリコメンドに従い、OS・ミドルウェアを最新バージョンに変更したことにより、問題 がでた場合は、稼動確認済のバージョンに変更してください。 (4) 性能検証を実施します。 (5) テストシナリオを実施した際、応答時間を計測して、問題がないか確認した結果を 報告してください。 A. 利用企業にて収集/分析方法を有している場合、そちらを使用してください。 B. 収集/分析方法を有していない利用企業のために、以下に Tips を記載しています。 a. Web アプリケーション系の負荷/性能検証用のツールの JMeter の使用方法を記載している以下 のサイトにアクセスしてください。 http://www.stackasterisk.jp/tech/engineer/jmeter01_01.jsp 詳細は、上記サイトにて確認できますが、JMeter の概要は以下のとおりです。 オープンソースの Apache Jakarta プロジェクト内で開発された Web アプリケーションのため のテストツールです。 HTTP 以外に、FTP、JDBC、SOAP、LDAP などのテストを行うことができます。 また、SSL やプロキシ環境をサポートしており、無償ツールとしては、高機能といえます。 (6) 上記レスポンス時間の計測以外に、サーバのリソース状況を計測して、ミニマム、下記のリソース に問題がないか確認した結果を報告してください。 - CPU 使用率 - メモリ使用率 - ディスク I/O ※ 勿論、上記以外のリソース状況を計測可能ならば確認することをお薦めします。 A. 利用企業にて収集/分析方法を有している場合、そちらを使用してください。 B. OS が Windows で、収集/分析方法を有していない利用企業のために、 以下に Tips を記載しています。 a. 以下のパフォーマンスモニタで収集した情報をログファイルに落とす手順が記載されたサイト にアクセスしてください。 http://www.voice-com.net/news/winpfm/index.html 収集対象のパラメータの意味の解説もあるので、このサイトの記載内容を把握すれば収集できる と考えます。 b. マイクロソフト社のサイトでは、以下にアクセスしてください。 システム モニタを使用してリモートの Windows 2000 コンピュータからパフォーマンス デー タをキャプチャする方法 http://support.microsoft.com/kb/811237/ja (7) 実施結果にもとづき、結果報告書を作成し、予め合意した期限内に提出してください。