Forms Server for Windows and UNIX
Formsアプリケーション Web利用ガイド
リリース6i
J00496-01
戻る次へ

目次
索引

14
キャパシティ量計画の考慮事項

14.1 概要

この章では、Forms Serverの拡張性機能について考察します。広く使用されているハードウェア・プラットフォームとオペレーティング・システムを用いて、いくつかのベンチマーク・テストを実行することによって、サーバーの拡張性を調査しました。

次のベンチマークを測定しました。

Forms Server 6.0では、次の結果が得られました。

Windows NTの場合:

表14-1 Windows NTでのベンチマーク
アプリケーションのサイズ/複雑さ  ユーザーあたりのRAM（MB）  CPUあたりのユーザー数 

標準/普通 

2.5-6.0 

100-300 

小/単純 

1.0-2.5 

150-300 

Sun Solarisの場合:

表14-2 Sun Solarisでのベンチマーク
アプリケーションのサイズ/複雑さ  ユーザーあたりのRAM（MB）  CPUあたりのユーザー数 

標準/普通 

2.0-5.0 

200-400 

小/単純 

1.0-2.0 

300-500 

注意:

この章に記載されている結果は、Forms Serverのリリース6iに固有であり、以前のリリースの製品には適用されません。このリリースは、以前のリリースと比較してパフォーマンスが改善されています。パフォーマンスの改善は、次のようないくつかのアーキテクチャおよびコードの最適化によるものです。

ベンチマーク・テストは、Oracle社で現在でも進行中の作業です。ここに示す図は、本書の記述時点で利用可能な情報を表しています。追加の結果は、利用可能になりしだい公開されます。

14.2 拡張性とは

拡張性とは、基盤となるソフトウェアは変更しないでシステムにハードウェア・リソースを追加することで、ある単一システム上のユーザー数の増加に適応できる能力です。拡張可能なシステムは、企業のニーズの拡大に適応できます。

パフォーマンス・ニーズに合せて拡張できるハードウェアとソフトウェアを選択することは、パフォーマンス・ニーズが変わるたびに新しいソフトウェアを購入することよりもはるかに優れた方針です。

次の事項を検討してください。

これらの質問に対する回答は、使用するハードウェア、オペレーティング・システムおよびアプリケーション・ソフトウェアに大きく依存します。

14.3 システム・キャパシティの評価基準

ネットワーク化されたアプリケーションの拡張性は、アプリケーション・サーバーの能力と、ユーザー負荷の増加に予想どおりに適応するためのネットワーク・トポロジに関連します。

この項で説明する各コンポーネントの役割と、それらのコンポーネントが特にForms Server環境で、システムの全体的な拡張性にどのように影響するかを理解しておくと役に立ちます。

この章では、最もよく使用されるサーバー・ハードウェアとオペレーティング・システムの2つの組合せを例として使用します。その組合せとは、Sun UltraSparcアーキテクチャ上で実行されるSun Solarisと、Intelアーキテクチャ上で実行されるMicrosoft Windows NTです。

次の領域は、Forms Serverベースシステムの評価で重要です。

14.3.1 プロセッサ

より高速な動作か、より効率的なな動作か。プロセッサ・テクノロジは、両方のアプローチを探索しました。通常、企業は2〜3年ごとに新世代アーキテクチャ（より効率的な動作）をリリースします。これらのリリースの間に、プロセッサ速度が向上します（より高速な動作）。クロック速度とも呼ばれるプロセッサの速度は、通常はメガヘルツ（MHz）で表されます。プロセッサ速度は、コンピュータ・システムがどの程度高速に稼動できるかをよく示します。通常は、サーバーとして使用されるコンピュータは、複数のプロセッサを使用し、マルチプロセッサ・システムと呼ばれます。

Forms Serverに関して我々が実際に興味を持つ基準値は、各プロセッサ上の同時ユーザー数です。この基準値は、プロセッサあたりのユーザー数と呼ばれることもあります。この数値は、プロセッサのタイプによって大きく異なります。この変化の例は、の表14-1との表14-2を参照してください。

ベンチマークで収集された経験データによると、400MHzのIntel Pentium II Xeonプロセッサと1MBのL2キャッシュを搭載したコンピュータは、200MHz Pentium Proシステムと比較して、約2倍のユーザー数をサポートできます。

14.3.2 メモリー

メモリーは、コンピュータ・システムがプログラムの起動と実行に使用できるRAMの容量です。コンピュータ・システムのRAMの容量は、通常はメガバイト（MB）で表されます。

プログラムの通常の実行では、プログラムはRAMにロードされ、プログラムが非アクティブになるたびに、オペレーティング・システムがプログラムをディスクにスワップします。オペレーティング・システムは、プログラムがアクティブになると、そのプログラムをRAMに戻します。

このアクティビティは、一般にスワッピングと呼ばれています。Sun SolarisやMicrosoft Windows NTなどのほとんどのオペレーティング・システムは、通常の操作中にスワッピングを実行します。スワッピングによって、プロセッサの需要が増加します。過度のスワッピングは、システムの処理速度をかなり低下させる傾向があります。パフォーマンスの低下を防ぐには、サーバー・ホスト・マシンに十分なRAMを搭載してください。

重要な基準値は、Forms Serverを介してアプリケーションに接続し実行するすべての追加ユーザーが必要とするRAMです。この基準値は、ユーザーあたりのメモリーとも呼ばれます。通常は、パフォーマンス測定ツールは、ユーザーあたりのメモリーを正確に測定しません。この基準値を入念に調査して、メモリー要件を判断します。ユーザーあたりのメモリーの例は、の表14-1と表14-2を参照してください。

14.3.3 ネットワーク

Forms Serverのような多層のインターネットベース・アーキテクチャでは、クライアントをForms Serverに接続する物理的なネットワーク、およびForms Serverとデータベースの間の接続は、システムの全体的な拡張性の重要な要因となります。Forms Serverベース・システムのパフォーマンスを測定するときは、物理ネットワークのパフォーマンスに注意してください。

14.3.4 共有リソース

マルチユーザー、マルチプロセス環境での個々のプロセスのパフォーマンスは、メイン・メモリーで処理される個々のプロセスの能力に直接比例します。つまり、他のプロセス用の領域を空けるために、必要なページが仮想メモリーにスワップされると、パフォーマンスが悪影響を受けます。必要なページがメイン・メモリーに見つかる可能性を高める1つの技法は、イメージ・マップ・メモリーを使用して共有メモリー・モデルをインプリメントすることです。イメージ・マップ・メモリーは、メモリー内のファイルの内容を、プロセス間で共有される特定のアドレス空間に関連付けます。

Forms Serverはイメージ・マップ・メモリーを使用します。個々のFormsプロセスは、FMXファイル・イメージの大部分を共有するので、個々のメモリー要件が低減し、全体的な拡張性が向上します。

14.3.5 ユーザー負荷

ベンチマーク・シナリオでは、実際のアプリケーション環境を正確に作り出すために多数のクライアント・マシン（およびユーザー）を設定するのは、実際的ではありません。ベンチマークでは、負荷シミュレータを使用して、アプリケーション・サーバーでトランザクションを実行する実際のユーザーをシミュレートします。Oracle Toolsの開発部門は、負荷シミュレータを開発しました。このシミュレータは、サーバーにメッセージを送信して負荷をシミュレートすることで、実世界のForms Serverユーザーを模倣します。負荷シミュレータは、Forms ServerとUIクライアントの間に位置し、これら2つのコンポーネント間のメッセージ・トラフィックをインターセプトする小さなJavaアプリケーションです。

クライアントからのイベント・メッセージが記録されると、そのメッセージをサーバーに再生できます。これにより、実際のユーザー・セッションがシミュレートされます。（UIクライアントは、再生モードには関係しないことに注意してください。）サーバーへの再生中に、負荷シミュレータは多数のユーザー・セッションを再生できます。この方法では、負荷シミュレータは、クライアントとサーバー間のメッセージの往復時間の合計を判断することによって、ユーザーへの合計応答時間を計算できます。あるビジネス・トランザクション全体の合計応答時間を累計することによって、アプリケーション・パフォーマンスの測定可能な基準値を取得できます。

14.3.6 アプリケーションの複雑さ

値リスト（LOV）とポップアップ・ウィンドウを含む単純な単一Formから、複数のFormsとPL/SQLライブラリ（PLL）を同時にオープンする複雑なアプリケーションにいたるまで、さまざまな複雑さのFormsアプリケーションをテストしました。アプリケーションの複雑さは、ある1つのモジュールに固有の複雑さではなく、ユーザーが一度にアクセスできるモジュール数に関連付けました。

複雑さを判断するのによい方法は、Formに追加されたすべての依存性を参照することです。たとえば、フォームは、CALL_FORMまたはOPEN_FORMビルトインを介して他のフォームをコールすることがあります。また、メニュー（MMXファイル）に接続することや、PL/SQLライブラリ（PLLファイル）を使用して外部ビジネス・ロジックをロードすることもあります。これらすべての要因は、ユーザーあたりのメモリー使用量に寄与します。

次の表に、Oracle Formsアプリケーションの複雑さのレベルを分類します。

表14-3 アプリケーションの複雑さの判断
アプリケーションのサイズ/複雑さ  メモリー内の同時モジュールの合計サイズ 

大/複雑 

> 10MB 

標準/普通 

2〜10MB 

小/単純 

< 2MB 

複雑さの異なる2つのアプリケーションをテストしました。

現実的なユーザー・コミュニティ、つまり複合的な作業負荷が存在するコミュニティを表すために、テストでは、45分間のシナリオに、サービス・デスク要員が実行するアクティビティを模倣したいくつかのトランザクションを含めました。

インプリメントした作業のステップごとの定義。

ステップ  実行した作業 

1 

サービス表示アプリケーションの起動 - ログイン 

2 

通知画面へ[ナビゲート] 

3 

進捗画面を[コール]

トランザクション:パラメータ化した問合せの入力 

4 

問題画面を[オープン]

各種タブ（PL/SQLの実行）へ[ナビゲート]

画面上のすべてのフィールドへ[ナビゲート] 

5 

サービス画面を[コール]

トランザクション:ブラインド問合せの入力

問い合わせたすべてのフィールドへ[ナビゲート] 

6 

シナリオ2〜5の[繰返し]  

14.4 拡張性の基準値の判断

ユーザー負荷が増えたときに感じられるパフォーマンスの低下感を測定するためには、最初に、特定のユーザーが特定のアプリケーション作業を実行するのにかかる時間を判断する必要があります。この合計応答時間基準値は、単に特定の物理トランザクションやネットワークの往復の応答時間をテストするのとは異なります。この基準値は、（平均的なユーザーが）当面のビジネス・タスクを実行するのにかかる合計時間（つまり、ビジネス・トランザクションの一部としてForms Serverとデータベースの間で行われるすべての対話の合計）を参照します。

全体的なシステム・リソースに関する経験的な情報を得るために、拡張性テストでは、オペレーティング・システムに固有の監視ユーティリティ（Windows NTのパフォーマンス・モニタなど）も使用して、物理メモリーと仮想メモリーの使用量およびCPUの合計使用量の値を判断します。

合計応答時間基準値を経験的な測定値とともに使用することで、ユーザー負荷が増えたときに、特定のユーザーのパフォーマンスが大幅に低下するポイントを判断できました。許容されるパフォーマンスでサポートできるユーザー数を判断したところ、個々のメモリー消費は、アプリケーションにアクセスするユーザー数で除算した合計使用可能メモリーの単純な等式になりました。

例:

512MBのRAMのある特定のハードウェア・プラットフォームでは、60人の同時ユーザーまではパフォーマンスが一定です。それを超えると、パフォーマンスは大幅に低下します。これにより、サポートされる最大ユーザー数は60人であると規定できます。

通常のオペレーティング・システム・オーバーヘッド（〜32MB）を考慮すると、個々のメモリー使用量は、(512-32) / 60、つまりユーザーあたり8MBになります。

14.5 サンプルのベンチマーク結果

次の項では、次のシナリオについて、テストしたシステム、テストの結果および簡単な分析を定義します。

14.5.1 低コストのIntel Pentiumベース・システム上の、標準的な複雑さのアプリケーション

パラメータ:

アプリケーションのサイズ/複雑さ  CPU  RAM  オペレーティング・システム  スワップ 

標準（2〜10MB） 

2つの200 MHz Pentium Pro 

512MB 

Windows NT 4.0 Server（SP 3） 

2GB 

結果:

CPUあたりのユーザー数  ユーザーあたりのメモリー 

100 

2.4MB 

分析:

このシステムは、標準的な複雑さのアプリケーションの拡張性をテストするために使用した最も安価なシステムの1つです。システムは、約200ユーザーを非常に効率よく処理できました。200ユーザーを超えると、パフォーマンスが劇的に低下しました。このシステムは、標準クラスの複雑さに分類されるアプリケーションを最大200ユーザーが使用する小規模部門サーバーとして、費用効果があります。

14.5.2 Intel Pentium II Xeon-Baseシステム上の、標準的な複雑さのアプリケーション

パラメータ:

アプリケーションのサイズ/複雑さ  CPU  RAM  オペレーティング・システム  スワップ 

標準（2〜10MB） 

1MB L2キャッシュを搭載した2つの400 MHz Pentium II Xeon 

512MB 

Windows NT 4.0 Server（SP 3） 

2GB 

結果:

CPUあたりのユーザー数  ユーザーあたりのメモリー 

200 

1.2MB 

分析:

このシステムは、標準的な複雑さのアプリケーションの拡張性をテストするために使用した最新のIntel Pentium II Xeon-Baseサーバーの1つです。システムは、約400ユーザーを非常に効率よく処理しました。400ユーザーを超えると、パフォーマンスが劇的に低下しました。システムは、大規模な部門サーバーまたは小〜標準規模ビジネス用のエントリレベルEnterprise Serverとして、費用効果があります。

14.5.3 エントリレベルのSun UltraSparcサーバー上の、標準的な複雑さのアプリケーション

パラメータ:

アプリケーションのサイズ/複雑さ  CPU  RAM  オペレーティング・システム  スワップ 

標準 

2つの248 MHz Ultra Sparc 

512MB 

Solaris 2.5.1 

2GB 

結果:

CPUあたりのユーザー数  ユーザーあたりのメモリー 

200 

1.3MB 

分析:

システムは、約375ユーザーを非常に効率よく処理しました。375ユーザーを超えると、パフォーマンスが劇的に低下しました。システムは、過度のページングとスワッピング・アクティビティにより速度が低下するようで、実際のボトルネックは物理メモリーであったことを示しています。このシステムは、標準的な複雑さのアプリケーションを実行する大規模部門または小〜標準規模のビジネスで、費用効果があります。

14.5.4 Intel Pentium II Xeon-Baseシステム上の単純なアプリケーション

パラメータ:

アプリケーションのサイズ/複雑さ  CPU  RAM  オペレーティング・システム  スワップ 

小（2MB未満） 

1MB L2キャッシュを搭載した2つの400 MHz Pentium II Xeon 

512MB 

Windows NT Server 4.0（SP 3） 

2GB 

結果:

CPUあたりのユーザー数  ユーザーあたりのメモリー 

250 

1MB 

分析:

Pentium II Xeon-Baseのサーバーは、小規模なアプリケーションで500ユーザーを非常に効率よく処理しました。

14.5.5 エントリレベルのSun UltraSparcサーバー上の単純なアプリケーション

パラメータ:

アプリケーションのサイズ/複雑さ  CPU  RAM  オペレーティング・システム  スワップ 

小（2MB未満） 

2つの248 MHz Ultra Sparc 

512MB 

Solaris 2.5.1 

2GB 

結果:

CPUあたりのユーザー数  ユーザーあたりのメモリー 

240 

1MB 

分析:

このシステムは、エントリレベルのSun Ultra Sparcシステムです。システムは、約480ユーザーを非常に効率よく処理しました。480ユーザーを超えると、パフォーマンスが劇的に低下しました。

戻る 次へ
Oracle
Copyright © 2000 Oracle Corporation.
All Rights Reserved.

目次
索引