 目次 |
 索引 |
|
|
|
|
この章では、Forms Serverを使用してインターネットまたはその他のネットワーク環境上にアプリケーションを配置する場合に発生するチューニング上の考慮事項について説明します。この章では、アプリケーション・サーバー上のネットワークおよびリソースについて取り扱います。Forms Serverとデータベース・サーバー間の接続のチューニングについては取り扱いません。
Forms ServerおよびJavaクライアントには、いくつかの最適化機能が含まれており、大きく次の項目に分類できます。
Javaクライアントは、主にアプリケーション画面のレンダリングを行います。Javaクライアントには、埋込みアプリケーションのロジックはありません。Javaクライアントをロードすると、複数のフォームを同時に表示できます。すべてのForms Serverアプリケーションに対応する汎用Javaクライアントを使用すると、各アプリケーションにカスタマイズされたJavaクライアントと比較して、クライアント上のリソースが少なくて済みます。
Javaクライアントは、多くのJavaクラスで構成されています。これらのクラスは、スプラッシュ画面の表示、ネットワーク通信およびルック・アンド・フィールの変更などの、機能サブコンポーネントにグループ化されます。機能サブコンポーネントを使用すると、Forms DeveloperおよびJava仮想マシン（JVM）は、すべての機能クラスを一度にダウンロードせず、必要に応じて機能をロードできます。
フォームの定義をFMXファイルからロードすると、実行プロセスのプロファイルは次のものに要約できます。
これらの中で、Data Segmentsセクションのみがアプリケーションの指定したインスタンスに対して一意です。Encoded Program UnitsおよびBoilerplate Objects/Imagesはすべてのアプリケーション・ユーザーに対して共通です。Forms Serverは共有コンポーネントを物理メモリーにマップして、同じFMXファイルにアクセスするすべてのプロセスでそのコンポーネントを共有します。
指定したFMXファイルをロードする最初のユーザーは、そのフォームに必要な全メモリー量を使用します。ただし、後続のユーザーの場合は必要なメモリー量が大幅に減らされているので、ローカル・データのエクステントにのみ依存します。共有コンポーネントをマップするこのメソッドを使用すると、指定したアプリケーションに必要な、ユーザーごとの平均メモリー量を減らすことができます。
帯域幅は重要なリソースで、インターネット・コンピューティングの一般的な広がりとともに、インフラストラクチャにますます大きな負担を強いるようになっています。このため、アプリケーションはネットワークの容量を節約して使用することが重要です。
Forms Serverは、メタデータ・メッセージを使用するJavaクライアントと通信します。メタデータ・メッセージは、実行対象のオブジェクトとその実行方法をクライアントに通知する名前と値のペアのコレクションです。パラメータのみをJavaクライアント上の汎用オブジェクトに送信することで、（同じ効果になるよう新規コードを送信した場合と比較して）通信量を約90%減らすことができます。
Forms Serverでは、次の3つの方法で効果的にデータ・ストリームを圧縮します。
待ち時間は、アプリケーションの応答時間に影響を与える最も重要な要因です。待ち時間の影響をなるべく受けないようにする最もよい方法の1つは、JavaクライアントとForms Server間で、対話中に送信されるネットワーク・パケットの数を最小限にすることです。
Forms Developerモデル内のトリガーを多数使用すると大きな効果がありますが、各トリガーにネットワークの往復が必要なため、待ち時間の影響が大きくなります。トリガーに関連する待ち時間を避ける方法の1つは、イベント・バンドルを介してトリガーをグループ化することです。たとえば、ユーザーが項目Aから項目Bにナビゲートする場合（あるエントリ・フィールドから別のフィールドへタブする場合など）、トリガー実行前後の範囲には、それぞれForms Server上での処理が必要です。
イベント・バンドルは、2つのオブジェクト間をナビゲートしている間にトリガーされたすべてのイベントを集めて、それらを単一のパケットとしてForms Serverに配布して処理します。ナビゲートに多くのオブジェクトの問合せが関連している場合（離れているオブジェクト上でマウスのクリックを行った場合など）、イベント・バンドルは問い合されたすべてのオブジェクトからすべてのイベントを集めて、そのグループを単一のネットワーク・メッセージとしてForms Serverに配布します。
指定したフォーム内のすべてのボイラープレート・オブジェクトは仮想グラフィック・システム（VGS）ツリーの一部です。VGSは、すべてのForms Developer製品に共通の図形サブコンポーネントです。VGSツリー・オブジェクトは、座標、カラー、線幅およびフォントなどの属性を使用して記述します。オブジェクトのVGSツリーをJavaクライアントに送信する場合、送信する属性のみが指定したオブジェクト・タイプのデフォルトと異なる属性になります。
イメージは圧縮されたJPEGイメージとして送信および格納されます。これにより、ネットワーク・オーバーヘッドとクライアントの必要なメモリー量の両方を減らすことができます。
リソースの最小化には、クライアントおよびサーバー・プロセスのメモリー・オーバーヘッドの最小化も含まれます。ネットワークを最適な状態で使用するには、帯域幅を最小に維持し、ネットワークの待ち時間の影響も含まれるため、クライアントおよびForms Server間の通信に使用するパケット数を最小化することが必要です。
アプリケーションの開発者は、Forms Serverのビルトイン・アーキテクチャの最適化機能により最大の利益を得ることができます。この章の後半では、多くのアプリケーションに影響を与える主要なパフォーマンスの問題および開発者がアプリケーションをチューニングしてパフォーマンスを改善し、Forms Server 機能を活用するための方法について説明します。
取り上げる内容は次のとおりです。
JavaクライアントをForms Serverへ接続する場合、イベント・バンドルなどの機能を使用してネットワーク待ち時間の影響を効率的に抑えることができます。message diff-ingを使用して、ネットワーク帯域幅を削減します。一方、Forms Serverとデータ・サーバー間に存在するクライアント・サーバーの関係で、ネットワークの往復通信の遅延や混雑はさらに許容できません。
これらの理由から、Forms Serverはデータ・サーバーと同じ高速LAN上に置くことが最良で、この結果Forms Serverをユーザーからさらに離れた場所に置くことがあります。これは、ユーザーの近くにサーバーを置くという標準規則に反しているように思えますが、従来のクライアント・サーバーのインプリメンテーションと比較して、ネットワークでのForms Serverの効率を改善した結果です。
最適構成では、図11-1に示すように、Form Serverおよびデータ・サーバーはデータ・センター内の同じ場所に配置されます。これはお薦めの設定方法ですが、クライアントは低帯域幅（モデム）と長い待ち時間（衛星）の接続を介してサーバーにアクセスします。
アプリケーションをロードするためにかかる時間は、第一印象として重要であり、またどのユーザーにとっても主要な基準となります。起動時間は、オーバーヘッドとみなされます。起動時間は、今後のパフォーマンスを期待させるものでもあります。業務でクライアント・テクノロジを使用する場合、クライアント・コードのロードに必要な追加のオーバーヘッドは、ユーザーにあまりよい影響を与えません。したがって、可能な限りロード時間を最小化することが重要です。
Formsアプリケーションを要求した後に、次のステップを実行してからアプリケーションを使用します。
アプリケーション開発者は、JVMを起動するのにかかる時間についてほとんど何も行うことができません。ただし、Java配置モデルおよびForm Javaクライアントの構造では、開発者はロードするJavaクラスとその方法を決定できます。これにより、Javaクラスに必要なロード時間を最小化します。
Javaクライアントには、基本機能のクラス（ウィンドウを開くなど）と特定の表示オブジェクトの追加クラス（LOV項目など）のコア集合が必要です。これらのクラスはサーバーに始めから常駐している必要がありますが、次の方法を使用すると、これらのクラスをクライアントのJVMにロードするのに必要な時間を短縮できます。
JavaはJavaアーカイブ（JAR）メカニズムを提供して、クライアントにネットワークを介して効率的な配布を行うために、クラスをまとめてグループ化し、圧縮（Zip形式）することができるファイルを作成します。このファイルをクライアントで使用すると、今後の使用のためにキャッシュされます。
Form Serverは、次に示す構成済みのJARファイルを提供して、通常の配置シナリオをサポートします。
1つ以上のJARファイルをアプレットに指定するには、参照しているHTMLファイルの<APPLET>タグでARCHIVEパラメータを指定します。例:
<APPLET CODEBASE="http://www.server.com/webcode/" ARCHIVE="f60all.jar, icons.jar" CODE="oracle.forms..">
Form Serverのサポート済みJVMは両方（Oracle JInitiatorおよびOracle JDK）ともJARファイルのキャッシュをサポートします。JVMがクラスを参照する場合、最初にローカルのクライアント・キャッシュをチェックして、クラスがキャッシュ済みJARファイル内に存在するか確認します。クラスがキャッシュ内に存在する場合、JVMはサーバーをチェックして、JARファイルの現行バージョンがあるか確認します。見つからない場合は、クラスはネットワークを介してではなくローカル・キャッシュからロードされます。
キャッシュは、効率性を最大化するために適切なサイズにします。キャッシュ・サイズが小さすぎると、有効なJARファイルが上書きされてしまう場合があります。その結果、アプリケーションを再度起動すると、別のJARファイルのダウンロードが必要になります。デフォルトのキャッシュ・サイズは20MBです。このサイズは、アプリケーションを正常に実行した後のキャッシュ容量のサイズと比較する必要があります。
JARファイルはロード元のホストに関連してキャッシュされます。これには、異なるサーバーからの同一のJARファイルがキャッシュを埋めることができるロード・バランス・アーキテクチャという含意があります。JARファイルを中央に置き、ロード・バランス構成の各サーバーでそれらを参照することで、開発者は各JARファイルの1つのコピーのみがクライアントのキャッシュでメンテナンスされていることを確認できます。この方法を使用すると、JARファイル内の特定のクラスに署名して、ロード元のサーバー以外のサーバーに接続を戻せるようにする必要があります。Oracleが提供するJARファイルでは、事前にクラスに署名してあります。
JARメソッドの欠点は、実行を継続する前にJARファイル内のすべてのクラスをロードし、JVMによって妥当性チェックする必要があるという点です。JARファイルの便利な点として、他のJARファイルを参照して、指定したアーカイブ内に格納するクラスの数を制限できるという機能があります。JVMは、アプリケーションが要求する順序で必要なJARファイルにナビゲートできます。
Oracleが提供するf60splash.jarファイルには、クライアントを初期化し、初期スプラッシュ画面を表示するのに十分なロジックがあります。また、このファイルには、他のJARファイルに含まれるファイルの遅延参照もあるので、これらのファイルは需要に応じて続いてロードされます。需要に応じた遅延ロードを使用するには、f60splash.jarファイルをHTMLページが参照する最初のJARファイルに設定する必要があります。
開発者は、メッセージ間で異なる情報のみを送信するmessage diff-ingを使用して、データ・ストリーム圧縮を最大限利用できるようアプリケーションを設計できます。次のステップを実行すると、メッセージ間の相違部分を削減できます。
set_item_property(text_item1_id, FONT_WEIGHT, FONT_BOLD); set_item_property(text_item2_id, FONT_WEIGHT, FONT_BOLD); set_item_property(text_item3_id, FONT_WEIGHT, FONT_BOLD); set_item_property(button_item1_id, LABEL, 'Exit'); ...
RAISE ON ENTRY = YES (キャンバスのみ)
VISIBLE = NO
Set_Application_Property (MENU_BUFFERING, 'false');
次に示す方法を使用すると、アプリケーションを実行するのに必要なリソースをさらに削減できます。
|
 Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|