キャパシティプランニング

基準アプリケーションの処理結果の検討

以下の節では、基準アプリケーションについて説明します。

MedRec ベンチマークの概要

MedRec サンプルアプリケーションを使用して、軽量および重量アプリケーションテストを行いました。軽量アプリケーションテストと重量アプリケーションテストでは、クライアントとサーバの間で使用される通信プロトコルが異なります。軽量アプリケーションテストでは、クライアントから HTTP 1.1 プロトコルが使用されます。重量アプリケーションテストでは HTTPS 1.1 プロトコルが使用され、クライアントとサーバの間のデータ通信が保護および暗号化されます。

Avitek Medical Records (MedRec) は、J2EE プラットフォームのすべての側面を正確に示す WebLogic Server サンプルアプリケーションスイートです。MedRec は、J2EE 開発者の全レベルに対応する教育ツールとして設計されています。このサンプルは、J2EE の各コンポーネントの使用方法、およびコンポーネントの対話とクライアント開発に関するベストプラクティスの設計パターンを示すものです。

MedRec アプリケーションは、患者、医師、および管理者に対して、さまざまなクライアントを使用して患者のデータを管理するフレームワークを提供します。患者のデータには、以下のものがあります。

患者のプロファイル情報 - 患者の名前、住所、社会保障番号、およびログイン情報
患者の医療記録 - 患者の通院の詳細。患者の生命徴候と症状、医師の診断と処方箋など

MedRec アプリケーションスイートは 2 つの主要な J2EE アプリケーションで構成されています。各アプリケーションで、1 つまたは複数の MedRec ユーザシナリオがサポートされています。

medrecEar - 患者が Patient Web アプリケーション (patientWebApp) にログインし、自分のプロファイル情報を編集するか、または自分のプロファイルをシステムに追加するように要求します。また、以前に通院していたときの医療記録を参照することもできます。管理者は、Administration Web アプリケーション (adminWebApp) を使用して新しい患者のプロファイルリクエストを承認するか、または否認します。さらに medrecEar では、MedRec アプリケーションスイートで使用されるすべてのコントローラとビジネスロジック、およびさまざまなクライアントで使用される Web サービスも使用できます。
physicianEar - 医師および看護師が Physician Web アプリケーション (physicianWebApp) にログインし、患者のプロファイルを検索およびアクセスしたり、患者の医療記録を作成および参照したり、患者に薬を処方したりします。Physician アプリケーションは、medrecEar で提供される Web サービスを使用して通信するように設計されています。

medrecEAR アプリケーションは、MedRecServer という 1 つの WebLogic Server インスタンスにデプロイされます。physicianEAR アプリケーションは、Web サービスを使用して medrecEAR のコントローラコンポーネントと通信する PhysicianServer という独立したサーバにデプロイされます。

ベンチマークで使用される MedRec およびトランザクションに対する変更

WebLogic Server 8.1 MedRec アプリケーションは、キャパシティプランニングのベンチマーク用に最適化されています。修正後のアプリケーションでは、患者登録プロセスが同期化され、2 フェーズコミットが省略されています。ベンチマークソフトウェア LoadRunner の実行されたクライアントにおいて、次のトランザクションシーケンスで負荷を生成しました。

患者が MedRec アプリケーションに接続して、スタートページを開きます。

その患者が登録プロセスを完了します。

医師がオンラインシステムに接続して、サインインします。

医師が患者のルックアップを実行します。

医師が患者の新しい通院記録を作成して、処方箋の作成や削除を行います。

医師がログアウトします。

患者がサインインして、ユーザプロファイルを編集します。

患者がそのプロファイルを修正して、情報を更新します。

患者がログアウトします。

上のシーケンスの各アクションが、スループットを計算するためのトランザクションとして扱われます。各クライアントでは、処理を反復するたびにユニークな患者 ID が生成されます。

基準アプリケーションの概要

BEA ではシステム構築を検討する起点として、基準キャパシティプランニングでのテスト結果を生成しました。準値の生成には、構成の異なる 2 種類のアプリケーションを使用しました。使用したアプリケーションを次に示します。

軽量アプリケーションソフトウェア - HTTP プロトコルを使用する search、select、insert、および update トランザクションで構成される MedRec アプリケーション
重量アプリケーションソフトウェア - HTTPS (セキュア) プロトコルを使用する search、select、insert、および update トランザクションで構成される MedRec アプリケーション

これらのアプリケーションのそれぞれで提示される測定基準を使用して、選択したハードウェアとコンフィグレーションに基づく WebLogic Server のスループット、応答時間、同時ユーザの数、およびパフォーマンスへの全体的な影響を予測できます。

これらのテストシステムの測定値は、トランザクションの混合に思考時間を加味せずに得られたものです。

注意 : 標準ソフトウェアでの WebAuction アプリケーションを使用したキャパシティプランニングの概要については、『J2EE Applications and BEA WebLogic Server』Prentice Hall, 2001, ISBN 0-13-091111-9 (http://www.phptr.com) の第 15 章「Analysis of Capacity Planning」を参照してください。

MedRec 基準アプリケーション (軽量と重量) のコンフィグレーション

測定はすべて、クライアントアプリケーションと Oracle データベースを 4x400Mhz Solaris プロセッサ上で実行した状態で行われました。WebLogic Server インスタンスは、掲載されているプロセッサ/コンフィグレーションの組み合わせごとに起動しました。2 種類のアプリケーションのキャパシティ測定の基準値は、アプリケーションの説明の後に表形式で示します。

ここに示す基準値は、クライアントアプリケーション (ベンチマークソフトウェア LoadRunner を実行)、MedRec 基準アプリケーションの含まれる WebLogic Server、および Oracle データベースサーバの 3 層に分かれたコンフィグレーションで収集されたものです。このシステムでは Oracle 8.1.7 データベースが使用され、すべて 1GB のネットワークを使用して測定されました。

図 2-1 3 層コンフィグレーション

3 層コンフィグレーション

WebLogic Server のコンフィグレーション

基準値の収集に使用した製品バージョンと設定を以下に示します。

BEA WebLogic Server 8.1 GA 製品
Sun JDK141_02 (Solaris プラットフォームでの Java 出力は次のとおり)

java version "1.4.1_02-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-ea-b01)
Java HotSpot(TM) Client VM (build 1.4.1_02-ea-b01, mixed mode)

BEA JRockit (Windows プラットフォーム)

java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02)
BEA WebLogic JRockit(R) Virtual Machine (build 8.1-1.4.1_02-win32-CROSIS-20030317-1550, Native Threads, Generational Concurrent Garbage Collector)

デフォルトの WebLogic JVM コンフィグレーション (以下を除く)

JVM コンフィグレーション - 初期ヒープサイズと最大ヒープサイズの設定は 1GB
スレッドカウント - 設定は 50 (確認された最適の値)
JDBC コンフィグレーション Oracle 9.2.0.2 Thin Driver を使用 JDBC 接続プールの (初期および最大) サイズの設定は 50 (確認された最適の値) JDBC StatementCacheSize の設定は 50
クラスタコンフィグレーション - 各ノードに 1 つの管理対象サーバ (最初のノードでは管理サーバが動作)

測定に使用したコンフィグレーション

以下のコンフィグレーションについて測定しました。

WebLogic Server 8.1、Sun JDK141_02: 1、2、4、および 8 プロセッサコンフィグレーション、750MHz プロセッサ、1GB メモリ、BEA による最適チューニングの WebLogic Server (1 インスタンス)。
WebLogic Server 8.1、Sun JDK141_02: 1、2、3、および 4 ノードコンフィグレーション、400MHz プロセッサ、1GB メモリ、BEA による最適チューニングの WebLogic Server (1 ノードにつき 1 インスタンス)。LoadRunner クライアントでロードバランシングを実行しました。
WebLogic Server 8.1、JRockit 141_02: 1、2、3、および 4 ノードコンフィグレーション、700MHz プロセッサ、1GB メモリ、BEA による最適チューニングの WebLogic Server (1 ノードにつき 1 インスタンス)。LoadRunner クライアントでロードバランシングを実行しました。

データベースのコンフィグレーション

Oracle 9.2.0.2.0 を 8 プロセッサ 750MHz E6800 上で使用しました。パフォーマンスを向上させるために、Oracle のログ (8GB) を、一緒にストライピングされる 4 ディスクの RAID 配列に配置し、他のすべてのデータベースファイルについては、4 ディスクの別の RAID 配列 (ストライピング) を使用しました。

データベースのコンフィグレーションは次のとおりです。

ホスト - Solaris 9
CPU - 8X 750MHz UltraSparc III - Sun E6800
メモリ - 8GB
ディスク - 2 X 18GB + 4 x 18GB RAID Array
ソフトウェア - Oracle9i Enterprise Edition Release 9.2.0.2.0

クライアントのコンフィグレーション

クライアントのコンフィグレーションは次のとおりです。

ホスト - Windows 2000 Advanced Server
CPU - 4X 700MHz Poweredge 6400
メモリ - 4GB
ディスク - 2 X 18GB
ソフトウェア - LoadRunner 7.02

ネットワークのコンフィグレーション

1GB のネットワークを使用しました。

LoadRunner のコンフィグレーション

クライアントの負荷を生成するために、LoadRunner 7.02 を 4GB のメモリを搭載した 4X700MHz Windows 2000 マシンで使用しました。このテストでは思考時間は使用されていません。使用された HTTP/HTTPs のバージョンは 1.1 です。

基準値について

この調査で使用したベンチマークで得られた基準値は、WebLogic Server と、同様のベンチマークを実行した他のアプリケーションサーバやハードウェアを比較するためには使用しないでください。この調査では、独自のベンチマーク方式とチューニングが使用されています。

多数のベンチマークテストによって、十分に最適化されたアプリケーションが WebLogic Server 上でどれだけのパフォーマンスを発揮するかが示されています。こうしたベンチマークの数値は BEA Systems から入手できます。詳細については、BEA の販売担当者にお問い合わせください。

UNIX 上の軽量 MedRec アプリケーションで測定された TPS

UNIX 上での軽量 MedRec アプリケーションの測定値は、Solaris ハードウェアおよび HTTP プロトコルを使用して得られました。表 2-1 は、クライアントの数 (最初の列) と、ハードウェアコンフィグレーションに対する毎秒当たりのトランザクション数 (残りの列) を示しています。UNIX 上でのこのアプリケーションでは、コンフィグレーション番号の名称は light medrec UNIX n (lmUn) です。n はコンフィグレーション番号です。

(TPS = 1 秒当たりのトランザクション)

表 2-1 UNIX 上での軽量 MedRec アプリケーションのクライアント数 x TPS

プロセッサ (MHz) コンフィグレーション番号	1x750 lmU1	2x750 lmU2	4x750 lmU3	8x750 lmU4	4x400 1 ノード lmU5	4x400 2 ノード lmU6	4x400 3 ノード lmU7	4x400 4 ノード lmU8
クライアントの数	TPS	TPS	TPS	TPS	TPS	TPS	TPS	TPS
1 クライアント	16.20	19.15	21.45	22.63	15.69
4 クライアント	17.20	29.80	47.95	58.12	34.54	53.57	58.67	63.33
10 クライアント	16.74	30.12	53.87	80.96	38.87	76.82	102.48
20 クライアント	17.04	30.54	55.76	83.84	39.17	81.14	120.73	154.76
40 クライアント	16.72	30.81	54.02	84.66	39.32	81.65	122.50	163.23
80 クライアント	16.83	30.71	54.33	84.22	39.02	80.64	121.47	163.84
100 クライアント	16.85	30.71	54.36	84.09	38.78	80.24	122.26	163.86
150 クライアント							121.38	162.71
200 クライアント								163.10
最大 TPS	17.20	30.81	55.76	84.66	39.32	81.65	122.50	163.86
最大 TPS での App サーバの CPU 使用率	98%	97%	95%	91%	95.09%	95.58%	95.35%	95.22%
最大 TPS での DB サーバの CPU 使用率	<1%	1.30%	2.25%	3.91%	1.70%	3.64%	6.21%	9.70%
最大 TPS での DB サーバディスクの CPU 使用率	6%	12%	19%	28.24	13.94	27.79	40.58	53.25

表 2-2 に、測定対象とした各プロセッサタイプ/コンフィグレーションの組み合わせで達成した TPS と、その TPS に達した際に同時に実行されていたクライアントの数を示します。

表 2-2 UNIX 上の軽量 MedRec アプリケーションで測定された TPS

プロセッサタイプ、コンフィグレーション	コンフィグレーション番号	測定された TPS	クライアントの数
Solaris 1x750MHz	lmU1	17.20	4
Solaris 2x750MHz	lmU2	30.81	40
Solaris 4x750MHz	lmU3	55.76	20
Solaris 8x750MHz	lmU4	84.66	40
Solaris 4x400 - 1 ノード	lmU5	39.32	40
Solaris 4x400 - 2 ノード	lmU6	81.65	40
Solaris 4x400 - 3 ノード	lmU7	122.50	40
Solaris 4x400 - 4 ノード	lmU8	163.86	100

UNIX 上の重量 MedRec アプリケーションで測定された TPS

UNIX 上での重量 MedRec アプリケーションの測定値は、Solaris ハードウェアおよび HTTPS プロトコルを使用して得られました。表 2-3 は、クライアントの数 (最初の列) と、ハードウェアコンフィグレーションに対する毎秒当たりのトランザクション数 (残りの列) を示しています。UNIX 上でのこのアプリケーションでは、コンフィグレーション番号の名称は heavy medrec UNIX n (hmUn) です。

(TPS = 1 秒当たりのトランザクション)

表 2-3 UNIX 上での重量 MedRec アプリケーションのクライアント数 x TPS

プロセッサ (MHz) コンフィグレーション番号	4x750 hmU1	4x400 hmU2
クライアントの数	TPS	TPS
1 クライアント	12.18	8.76
4 クライアント	27.49	20.70
10 クライアント	32.13	23.00
20 クライアント	31.08	23.07
40 クライアント	31.39	23.35
80 クライアント	31.43	23.44
100 クライアント	31.81	23.29
最大 TPS	32.13	23.44
最大 TPS での App サーバの CPU 使用率	93.00%	94.06%
最大 TPS での DB サーバの CPU 使用率	1.16%	0.89%
最大 TPS での DB サーバディスクの CPU 使用率	12.23%	9.22%

Windows 2000 上の軽量 MedRec アプリケーションで測定された TPS

Windows 2000 上での軽量 MedRec アプリケーションの測定値は、HTTP プロトコルを使用して得られました。表 2-4 は、並行して動作するクライアントの数 (最初の列) と、ハードウェアコンフィグレーションに対する毎秒当たりのトランザクション数 (残りの列) を示しています。Windows 2000 上でのこのアプリケーションでは、コンフィグレーション番号の名称は light medrec Windows n (lmWn) です。

表 2-4 Windows 2000 上での軽量 MedRec アプリケーションのクライアント数 x TPS

プロセッサ (MHz) コンフィグレーション番号	Win2K 4x700 1 ノード lmW1	Win2K 4x700 2 ノード lmW2	Win2K 4x700 3 ノード lmW3	Win2K 4x700 3 ノード lmW3
クライアントの数	TPS	TPS	TPS	TPS
1 クライアント	33.50
4 クライアント	78.53	107.58	112.36	122.83
10 クライアント	80.24	149.09	205.13
20 クライアント	79.28	148.12	226.53	297.35
40 クライアント	77.36	148.78	223.53	299.11
80 クライアント	76.16	146.75	224.38	291.82
100 クライアント	76.38	144.99	220.02	292.22
150 クライアント			219.38	291.17
200 クライアント				292.87
最大 TPS	80.24	149.09	226.53	299.11
最大 TPS での App サーバの CPU 使用率	92.51%	92.42%	92.40%	92.82%
最大 TPS での DB サーバの CPU 使用率	3.32%	7.63%	14.63	23.44%
最大 TPS での DB サーバディスクの CPU 使用率	26.32%	44.63%	70.25%	88.98%

次の表に、測定対象とした各プロセッサタイプ/コンフィグレーションの組み合わせで達成した TPS と、その TPS に達した際に同時に実行されていたクライアントの数を示します。

表 2-5 Windows 2000 上の軽量 MedRec アプリケーションで測定された TPS

プロセッサタイプ、コンフィグレーション	コンフィグレーション番号	測定された TPS	クライアントの数
Windows 2000 4x700MHz - 1 ノード	lmW1	80.24	10
Windows 2000 4x700MHz - 2 ノード	lmW2	149.09	10
Windows 2000 4x700MHz - 3 ノード	lmW3	226.53	20
Windows 2000 4x700MHz - 4 ノード	lmW4	299.11	40

Windows 2000 上の重量 MedRec アプリケーションで測定された TPS

次に示すのは、Windows 2000 上での重量 MedRec アプリケーションの測定値です。すべてのオペレーティングシステムのすべてのテストで、HTTPS (セキュア) プロトコルを使用しています。重量 MedRec アプリケーションで使用した JVM は、Sun Microsystems JDK です。

表 2-6 は、クライアントの数 (最初の列) と、ハードウェアコンフィグレーションに対する毎秒当たりのトランザクション数 (残りの列) を示しています。Windows 2000 上でのこのアプリケーションでは、コンフィグレーション番号の名称は heavy medrec { U | W } n (hmUn または mmWn) です。

表 2-6 Windows 2000 上での重量 MedRec アプリケーションのクライアント数 x TPS

プロセッサ (MHz) コンフィグレーション番号	Win2K 4x700 hmW1
クライアントの数	TPS
1 クライアント	16.29
4 クライアント	38.62
10 クライアント	38.27
20 クライアント	37.58
40 クライアント	37.37
80 クライアント	36.86
100 クライアント	36.92
最大 TPS	38.62

次のステップ

サンプルアプリケーションの特徴と基準となる測定結果を検討した後は、使用するアプリケーションと 1 つまたは複数の基準サンプルの比較を行います。「ハードウェアキャパシティ要件の決定」に進んでください。次章では、使用するアプリケーションのキャパシティプランニング要件の作成に役立つ情報を紹介します。