2004年9月
要約
Oracle ADF Business Componentsを使用して作成されたアプリケーションは、強力で優れたオプションの値を調整する事で、そのパフォーマンスを最大限に引き出すことができます。本書では、これらのチューニング・オプションについて説明します。また、特定のトピックの詳細を記載した他のドキュメントへのリンクも提供します。
OracleのApplication Development Framework Business Components（ADF BC）は、J2EEのデータドリブン・アプリケーションを開発するための優れたフレームワークです。 この機能により、ADF BCアプリケーションを様々な方法で構成する柔軟性が実現し、アプリケーション固有のアーキテクチャに対するパフォーマンスを最大限引き出せます。
本書は、ADF BCおよびJDeveloper 10gを対象としています。 本書で紹介する手法は他のリリースと組み合わせても機能しますが、Business Componentsのバージョンが異なると、構成オプションも異なる場合があるので注意が必要です。 最新ライブラリの使用を確認するには、JDeveloperからADF ランタイム・インストーラを使用するか、または『How To Update ADF Runtime Libraries to Oracle Application Server 10g』に従ってください。
本書は、Oracle Application Serverにデプロイされたアプリケーションを中心に説明しています。そのため、Oracle Application Server固有の説明もいくつか含まれます。ただし、ほとんどの情報は一般的なもので、すべてのアプリケーション・サーバーおよびADF BCのすべてのバージョンに適用できます。 ADF BCおよびその他のアプリケーション・サーバーの詳細は、『Application Servers Supported by JDeveloper』を参照してください。
JDeveloperで、Business Componentsプロジェクトの構成プロパティ値を設定するには、ナビゲータでアプリケーション・モジュールを右クリックし、コンテキスト・メニューから「構成」を選択します。これにより、 デフォルト値以外の構成値はすべて、bc4j.xcfg ファイルに格納することができます。 その他のオプションは、JVMによりクライアント内に、または他の構成ファイル内に設定できます。 Business Componentsプロジェクトの構成プロパティ値は複数の場所に設定することが可能なため、そのの設定場所および優先順位について理解することが重要です。
Business Componentsの構成プロパティ値は、次の方法で設定できます。
bc4j.xcfg）
-D フラグ
.propertiesファイル（通常はアプリケーションの実行ディレクトリに配置された BC4J.properties ファイル）
/oracle/jbo/BC4J.properties リソース
/oracle/jbo/server/jboserver.propertiesリソース
/oracle/jbo/common/Diagnostic.properties リソース
数値は小さいほど優先順位が高くなります。
たとえば、bc4j.xcfg ファイルの値は、-D フラグによって指定されたどのオプションよりも優先されます。 つまり、いくつかのグローバルなデフォルトを設定するのに -D オプションを使用する場合は、bc4j.xcfg ファイルにそのプロパティのエントリがないことを確認する必要があります。このようなエントリが存在すると、-D フラグにより設定された構成プロパティ値が無効になり bc4j.xcfg ファイルの値が優先されます。
構成プロパティの値は複数の場所に設定できるため、これらの値を非常に細かく制御できます。 たとえば、スピルオーバーに対してシステム全体レベルのポリシー・セットがあるとします。 この場合には、システムで定義されたデフォルトを設定して、すべてのアプリケーションでそのデフォルトを使用します。 特定のアプリケーションについて、そのシステム全体の設定を無効にする必要がある場合は、bc4j.xcfg ファイルに記述する事でその設定を有効にすることができます。ただし、その他のすべてのアプリケーションではシステム・レベルの設定がそのまま使用されていることに注意してください。
ADF BCには、バッチ・モードと即時モードの2つのデータ同期モードがあります。 JDeveloper 10gでは、バッチ・モードがデフォルトです。 バッチ・モードでは、クライアントを中間層から切断できます。 これにより、特にJClientのようなリッチ・クライアントを使用するアプリケーションでは、ネットワークのラウンド・トリップが減少するため、パフォーマンスが大幅に向上する場合があります。ただし、アプリケーションがデータベースに頻繁にアクセスする場合は、即時モードが有効です。また、Webアプリケーションのパフォーマンスを向上させるには、適切なデータ同期モードを選択する必要があります。 データ同期モードの変更は、JDeveloperのオンライン・ヘルプを参照してください。
ADF BCは、アプリケーション・モジュール・プーリングとJDBC接続プーリングの2つのタイプのプーリングをサポートしています。
アプリケーション・モジュール・プーリング（AMプーリング）はADF BCアプリケーションのスケーラビリティを最大に引き出す上で重要な機能です。AMプーリングを使用することで、少数のアプリケーション・モジュール・インスタンス（AMインスタンス）で多数のリクエストに対処できます。 AMプーリングはデフォルトで使用可能です。 AMプーリングの機能を無効にする場合は、構成プロパティ jbo.ampool.doampooling を False に設定するか、または構成エディタで「アプリケーション・プール使用可」のチェックをはずします。
AMプーリングは細かく構成できます。最適なプーリング方針を実現するには、AMプールがどのように使用されているかを理解する必要があります。 このため、システム管理者は、各AMプールについて、次の詳細情報を確認することができます。
これらの情報を使用して、プール・サイズを適切に設定し、プールのタイミングを制御できます。
アプリケーション・モジュールのプール・サイズを管理するプロパティには、 jbo.ampool.maxpoolsize、 jbo.ampool.maxavailablesize、 jbo.ampool.minavailablesize、 jbo.recyclethreshold および jbo.init.poolsize の5つがあります。
アプリケーションからデータ・ソースに対する接続の最大数は、 jbo.ampool.maxpoolsize を設定により制御します。データ・ソースに対し許可される最大のセッション数が制限されている場合は、jbo.ampool.maxpoolsize の数をその最大数より小さく設定してください。対象のアプリケーションで予想されるユーザーの最大数、または予想されるアプリケーション・モジュール・インスタンスの最大数がわかっている場合は、jbo.ampool.maxpoolsize をその値に設定します。 これにより、アプリケーションでなんらかの例外が発生した場合でも、データ・ソースまたはアプリケーション・サーバーでスワッピングが起こりにくくなり、予期しないエラーを回避できます。
プール内で、リクエストを待機しアイドル状態に保持するアプリケーション・モジュール・インスタンスの最大数は、 jbo.ampool.maxavailablesize の設定により制御します。
新しいAMインスタンスの生成は、パフォーマンスのコストが高い処理です。そのため、 jbo.ampool.maxavailablesize および jbo.ampool.minavailablesize の値を調節して、AMインスタンス必要な際に、プール内に使用可能なAMインスタンスが存在するようにします。これらの2つの値は、同じ値に設定することもできます。ただし、これらを大きな値に設定すると、他で使用するためのリソースを一箇所で使用してしまう可能性があるため十分に注意が必要です。
各アプリケーションでニーズが異なるため、これらの2つの値の設定についての明確な基準はありませんが、これらの値を同時発生するプール・リクエストの予想数に設定することをお薦めします。これによりAMインスタンスを頻繁に作成または削除することを避けることができます。同時発生するリクエストの予想数は、Enterprise Managerを使用してアプリケーション統計を監視するとわかります。 これは、アクティブなリクエストの平均数、つまりリクエストの平均処理時間に、1秒あたりのリクエスト数を掛けた値です。
アプリケーションが複数のOC4Jインスタンスにデプロイされている場合、またはアプリケーションがクラスタリングを使用している場合は、OC4Jの各インスタンスは、それぞれAMプールを持ちます。したがって、AMプールのプロパティをそれに応じて設定する必要があるため注意してください。 たとえば、最大100人のユーザーに限定したデータソースがあり、アプリケーションを2つのOC4Jインスタンスにデプロイする場合は、jbo.ampool.maxpoolsize パラメータを50（100/2）に設定します。
最大および最小のプール・サイズ以外に、リファレンス・プール・サイズの設定も可能です。 リファレンス・プール・サイズとは、プール内のアプリケーション・モジュール・インスタンスの数です。これらのAMインスタンスは、それが管理ステート・モードでプールに対しリリースされる前に、最後に使用したセッションで作成された次のリクエストに対して、セッション・アフィニティを保持しようとします。 これは、 jbo.recyclethreshold のパラメータで制御されます。 アクティブなセッションとは、タイムアウト前に後続のリクエストを送信すると予想されるセッションです。 あるタイミングにおけるアクティブなセッションの数は、Enterprise Managerを使用して参照できます。
また、アプリケーション・モジュール・プールの初期サイズ（jbo.ampool.initpoolsize）は、jbo.recyclethreshold と同じ値に設定する必要があります。
アプリケーション・モジュールのプール・サイジングの詳細は、『Understanding Application Module Pooling Concepts and Configuration Parameters』を参照してください。
jbo.ampool.monitorsleepinterval を設定して、AMプール内の非アクティブなAMインスタンスをモニタリングする頻度を制御できます。また、jbo.ampool.maxinactivage を設定すると、プール内でアイドル状態のAMインスタンスがガベージ・コレクションされるまでの時間を制御できます。
プール内に、 jbo.ampool.maxavailablesize の値よりも多くのAMインスタンスが存在する場合は、AMインスタンスは jbo.ampool.maxinactiveage の設定により、一定時間が経過すると削除されます。そのデフォルト値は600000ミリ秒、つまり10分です。 ほとんどの場合、この値は大きすぎます。 jbo.ampool.maxavailablesize をより小さい値にすると、より動的かつ自動調整可能になります。 このパラメータ値は、5分、または3分に設定できます。それ以下にすることも可能です。
アイドル状態のAMインスタンスをチェックする間隔（ミリ秒）は、 jbo.ampool.monitorsleepinterval によって制御されます。この値は、 jbo.ampool.maxinactiveage の値の2倍よりも小さくすることをお薦めします。
ほとんどのアプリケーション・サーバーは、JDBCデータ・ソースを使用しない場合は一般的に接続プーリングを行いません。 アプリケーションで、JDBCデータ・ソースではなくJDBC URL接続を使用している場合は、ADF BCでJDBC接続プーリングが提供されます。 ADF BCのJDBC接続プーリングは、デフォルトでは無効に設定されています。 アプリケーション・サーバーのJDBC接続プーリングのかわりに、ADF BCのJDBC接続プーリングを使用したい場合には、ADF BCでは、データ・ソース接続に対するJDBC接続プーリングが提供されます。
アプリケーション・サーバーの接続プーリングではなく、ADF BCの接続プーリングを使用する最も一般的な理由は、1つのアプリケーションで複数のアプリケーション・モジュール・プールを持っている場合、それは1つの接続プール/プールされたデータ・ソースで共有される接続であるためです。 この場合のメリットとデメリットを理解するには、『Understanding Application Module Pooling Concepts and Configuration Parameters』を参照してください。
JDBC接続プーリングを有効にするには、構成エディタの「解放時にアプリケーション・モジュールを切断（接続プーリングを使用）」をチェックするか、または構成プロパティ jbo.doconnectionpooling を true に設定します。
オラクル社では、JDBC URL接続よりもJDBCデータ・ソース接続を使用することをお薦めしています。 JDBCデータ・ソース接続はJ2EEの標準であるうえ、データソースの方がセキュアな（ログイン情報がクライアントに含まれない）傾向があるため、配置された環境内の様々なデータベース接続に再マップでき、コンテナの接続プーリングを利用できます。データ・ソース接続の構成方法の詳細は、『Using JDBC Data Sources with ADF Business Components』を参照してください。
動的なJDBC資格証明は、デフォルトでは無効に設定されています。 動的なJDBC資格証明は、必要な場合以外は使用しないでください。 これを使用すると、アプリケーションとデータベース間のネットワーク通信量が増加し、アプリケーションのパフォーマンスが低下します。 JDBC資格証明が必要な場合の例、および使用方法の情報は、『How to Support Dynamic JDBC Credentials』を参照してください。
スピルオーバーは、コンテナがJVMのメモリー不足になり、データソースに影響する場合に使用します。この場合、データベース表を仮想メモリーとして使用します。 スピルオーバーによってパフォーマンスが大幅に低下するため、これは最後の手段として使用してください。 どのような場合にスピルオーバーを使用するかの詳細は『Overview of Temporary Tables Created By BC4J』を参照してください。
JDeveloper 10gのデフォルトでは、スピルオーバーの機能（jbo.use.pers.column）は無効（false）に設定されています。 ただし、JDeveloperの以前のバージョンで作成されたプロジェクトでは、これが有効（true）に設定されている場合があります。
フェイルオーバーを使用すると、アプリケーション・モジュール・インスタンスが失われている場合、どのような理由であってもステートが常に保存され、任意のアプリケーション･モジュール･インスタンスによっていつでもアクティにできます。この機能を使用すると、アプリケーション・モジュールがプールに戻ってチェックされるたびに、非アクティブにするための余分なオーバーヘッドが発生します。 フェイルオーバーは、パフォーマンスまたは信頼性のどちらかを重視すれば他方が低下するという、典型的な二者択一的なオプションです。
このパラメータの値については明確なアドバイスはありません。そのため、ユーザーはリソースの利用可能性、およびアプリケーションの性質に基づいて、フェイルオーバーを使用するかどうかを決定する必要があります。 フェイルオーバー・モードはデフォルトで true に設定されています。これは、デフォルトのADF BCがパフォーマンスではなく信頼性を重視することを意味しています。
フェイルオーバーは jbo.dofailover で制御されます。このプロパティを false に設定するとフェイルオーバーが無効になり、 true に設定すると、フェイルオーバーが有効になります。
ADF BCのアプリケーション・プールは、AMの使用境界でアクティブ・データベースに対してpingを実行し、アプリケーションに対するAMの参照処理前に、AM接続がアクティブであることを確認します。 AM接続が非アクティブになっている場合は、AMのステートを保持したままアプリケーション・プールがアプリケーションのかわりにAMに接続します。
Oracleを含め、最近のいくつかのJDBCデータ・ソースの実装では、接続に対して透過なアプリケーション・フェイルオーバーを提供しています。そのため、ADF BCではこのデータ・ソース・フェイルオーバーは不要です。 また、アプリケーションによっては、データベースをpingする場合のパフォーマンスについて、提供するクオリティのレベルを低下させたくない場合があります。 このような要件を持ったアプリケーションでは、プロパティ jbo.connectfailover を false に定義して、アクティブなpingを無効にできます。
接続のフェイルオーバーが無効になっており、他に透過なフェイルオーバー・メカニズムを使用していないアプリケーションでは、接続例外が発生する場合があります。 このような例外が発生しても、中間層の後続処理が続行されると予想されるため、AMにリクエストして接続に失敗したセッションに対象を限定する必要があります。
ADF BCをWeb環境にデプロイする場合、一般的には、ADF BCとWebクライアント（JSPなど）を同じJVMで実行することで最高のパフォーマンスが得られます。