| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース1（11.1.1） B61006-01 |
|
 戻る |
 次へ |
この章では、Oracle Application Development Framework（ADF）のパフォーマンスおよびスケーラビリティを最大化する方法についての基本的なガイドラインを示します。次の各項で、設計時、構成時およびデプロイメント時のパフォーマンスに関する考慮事項を取り上げます。
この章では、読者がADFアプリケーションの構築に精通しているものと想定しています。ADFについては、次のマニュアルを参照してください。
『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』
『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』
『Oracle Fusion Middleware Oracle Application Development Framework Java EE開発者ガイド』
Oracle Application Development Framework（Oracle ADF）は、Java Platform, Enterprise Edition（Java EE）標準およびオープンソース・テクノロジをベースとするエンドツーエンドのアプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、Webサービスなどのインタフェースを使用してデータを検索、表示、作成、変更、検証するアプリケーションの構築を目指す企業内開発者に最適です。Web、無線、デスクトップ、Webサービスなどのインタフェースを使用してデータを検索、表示、作成、変更、検証するエンタープライズ・ソリューションを構築する場合は、Oracle ADFで作業を簡素化できます。Oracle JDeveloper 11gとOracle ADFを組み合せて使用すれば、設計からデプロイメントまでの開発ライフサイクル全体をカバーする環境と、ドラッグ・アンド・ドロップによるデータ・バインディング、ビジュアルUI設計およびチーム開発の組込み機能が得られます。
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のOracle ADFの概要に関する項を参照してください。
Oracle ADF Faces Rich Client（RC）は、Ajax（Asynchronous JavaScript and XML）機能を備えた標準JSFコンポーネントのセットです。
Ajaxが標準のインターネット技術で稼働するリッチ・クライアント型のアプリケーションを実現するのに対し、JSFはサーバーサイド・コントロールを提供します。そのため、一般的なAjaxアプリケーションによく見られる、JavaScriptを多用することへの依存が軽減されます。Apache MyFaces Trinidadを基盤として採用したOracle ADF Faces RCは、JSFアプリケーションにAjaxの機能性を付加し、リッチ・インターネット・アプリケーション（RIA）の機能をもたらします。
ADFアプリケーションの構築、構成およびデプロイを行う前に、最適なパフォーマンスが得られるよう、次のトピックに目を通してください。
この項では、ADF Facesの構成およびプロファイリングの概念について説明します。Oracle ADF Facesの構成オプションは、web.xmlファイルに設定されています。ほとんどの構成オプションには、パフォーマンスを考慮してチューニングされたデフォルト値があります。表7-1に、これらの構成オプションの一部を示します。
表7-1 ADFの構成オプション
| パラメータ | 説明 |
|---|---|
|
|
出力をデバッグ用に拡張するするかどうかを制御します。このパラメータは削除するか、 |
|
|
ADF FacesがJSPページの変更日付をチェックして、ファイルに変更があった場合は保存されている状態を破棄するかどうかを制御します。このパラメータは削除するか、 |
|
|
クライアント側での状態の保存が有効になっている場合に、どのタイプの保存（ |
|
|
クライアント側のログ・レベルを設定します。デフォルト値は |
|
|
クライアント側でアサーションを処理するかどうかを指定します。デフォルト値は |
|
注意: Firefoxブラウザを使用してクライアントのレスポンス時間のプロファイリングまたは測定を行う際には、Firebugプラグインが無効になっていることを確認してください。ページの情報を取得したり、ページのJavaScriptコードをデバッグしたりする目的では、このプラグインは非常に有効ですが、総レスポンス時間に影響を与える可能性があります。Firefox Firebugプラグインの無効化の詳細は、Firefox Support Home Page（ |
表7-2に、ADF Facesのパフォーマンス向上につながる、構成に関する推奨事項を示します。
表7-2 ADF Facesの構成パラメータ
| 構成に関する推奨事項 | 説明 |
|---|---|
|
部分ページ・ナビゲーションを使用します。 |
部分ページ・ナビゲーションはADF Facesフレームワークの機能です。これを使用すると、ブラウザであるADF Facesページから別のADF Facesページへ移動する際に、ページ全体の遷移が不要になります。新しいページは、部分ページ・レンダリング（PPR）/Ajaxチャネルを使用してクライアントに送信されます。 従来のページ全体のナビゲーションと比較した部分ページ・ナビゲーションの主な利点は、パフォーマンスの向上です。ブラウザがJavaScriptライブラリを再度解釈して実行する必要はなく、ページ全体のクリーンアップ/初期化に時間を費やすこともありません。このような最適化から得られるパフォーマンス上の利点は非常に大きいため、部分ページ・ナビゲーションは可能なかぎり有効にしてください。 この機能には次のような既知の制限があります。
|
|
ページ・テンプレートを使用します。 |
ページ・テンプレートとは、開発者がデータ・バインドされた再利用可能なテンプレートを作成して、これを任意のページのシェルとして使用できる機能です。開発者は、Webページを作成する他の開発者に構成を伝えて一貫性を確保するためのテンプレートを1つ以上作成できます。テンプレートには、使用時に変更できない静的領域と、開発者が作成中のページ固有のコンテンツを配置できる動的領域があります。 テンプレートを使用する際の重要な考慮事項を次に示します。
|
|
ADF Rich Clientのジオメトリ管理を有効にします。 |
ADF Rich Clientは、親コンポーネントが明示的にUIに含められているブラウザ・レイアウトのジオメトリ管理をサポートしています。子コンポーネントは、ブラウザの使用可能領域いっぱいまで広がるようサイズ設定されます。この機能を使用するとUIの見栄えはよくなりますが、コストが発生します。影響が出るのはクライアント側です。これは、ブラウザがコンポーネントのサイズを変更するのに時間がかかるためです。デフォルトでジオメトリ管理の対象となるコンポーネントは次のとおりです。 panelAccordion panelStretchLayout panelTabbed breadCrumbs navigationPane panelSplitter toolbar toolbox table train 注意:
|
|
ADF Rich Clientのオーバーフロー機能を使用します。 |
ADF Rich Clientはオーバーフロー機能をサポートしています。この機能は、ページに収まらない子コンポーネントを、目に見えないオーバーフロー領域に移動するというものです。オーバーフローのサポートが組み込まれているコンポーネントは、panelTabbed、breadCrumbs、navigationPane、panelAccordion、toolbarおよびtrainです。toolbarは、toolboxの中に入れないとオーバーフローを処理できません。 オーバーフローのコストを軽減するために最適化がいくつか行われていますが、オーバーフロー・コンポーネントにおける子コンポーネントの数とそれぞれの複雑さに特に注意を払うことが必要です。オーバーフロー・コンポーネントの初期サイズを十分に大きく設定し、オーバーフローがほとんど発生しないようにすると効果的な場合もあります。 |
|
ADF Rich Clientの部分ページ・レンダリング（PPR）を使用します。 |
ADF Rich Clientは、Asynchronous JavaScript and XML（Ajax）開発手法をベースとしています。Ajaxは、対話型Webアプリケーションを作成するためのWeb開発手法です。Ajaxを使用したアプリケーションでは、Webページ全体をリロードせずに少量のデータを内部的にサーバーと交換するため、Webページのレスポンスが向上します。その結果、Webページの対話性、速度および使い勝手が向上します。 ADF Facesでは、Ajaxの部分ページ・リフレッシュ動作を実現する機能を部分ページ・レンダリング（PPR）と呼びます。PPRを使用すると、ページの小さい領域をリフレッシュすることができ、ページ全体を再描画する必要がなくなります。たとえば、ユーザーが入力コンポーネントで選択または入力した内容を出力コンポーネントに表示したり、コマンド・リンクやコマンド・ボタンからページ上の別のコンポーネントをリフレッシュするといったことが可能です。 2つの主要なAjaxパターンが部分ページ・レンダリング（PPR）によって実装されます。
ネイティブ・コンポーネント・リフレッシュはフレームワークに組み込まれていますが、クロスコンポーネント・リフレッシュは、場合によっては開発者が実装作業を行う必要があります。 クロスコンポーネント・リフレッシュは、アプリケーション開発者が宣言的またはプログラム的に実装します。その際、部分更新をトリガーするコンポーネント、および部分リスナーとして動作する更新対象のコンポーネントを定義します。クロスコンポーネント・リフレッシュを正しく使用し、実装することは、クライアント側のレスポンス時間を改善するための最善の方法です。UIページを設計する際には、ユーザーがコマンド・ボタンをクリックしたときにどのような処理を行うかを常に考えてください。ページ全体のリフレッシュが必要でしょうか。それとも出力テキスト・フィールドのみでよいでしょうか。フィールドの値が更新されたら、どのような処理を行う必要があるでしょうか。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください）。 ページに
前述の手順により、コマンド・ボタンを使用して部分ページ・リフレッシュをトリガーするPPRが実現します。 部分ページ・レンダリングによってパフォーマンスが大幅に向上する主な理由は、ページ全体のリフレッシュが発生せず、フレームワーク・アーティファクト（ADF Rich ClientのJSライブラリやスタイルシートなど）がリロードされるかわりに、ページの小さい部分のみがリフレッシュされることです。そのため、余分なデータのフェッチやジオメトリ管理が一切行われない場合もあります。 ADF Rich Clientは、部分ページ・レンダリングを使用すればクライアント側で最適なパフォーマンスが得られることを実証しています。クライアント側での影響に加えて、サーバー側の処理が高速化され、サーバー側のスループットおよびスケーラビリティが向上します。 |
|
ADF Rich Clientのナビゲーションを使用します。 |
ADF Rich Clientは、ナビゲーションを幅広くサポートしています。一般的なユースケースの1つに、タブ付きナビゲーションがあります。これは現在、xmlMenuModelにバインドして簡単にナビゲーションを定義できるnavigationPaneなどのコンポーネントでサポートされています。 ただし、この方法にはデメリットが1つあります。それは、ユーザーがタブを切り替えるたびにページ全体のリフレッシュが発生することです。1つの選択肢として、panelTabbedをかわりに使用します。panelTabbedには、タブ付きコンテンツの部分ページ・レンダリングのサポートが組み込まれており、開発者の作業は必要ありません。しかし、panelTabbedはナビゲーションにバインドできず、コンテンツをページ内から取得できるようにする必要があるため、応用可能な範囲は限られています。 |
|
リソースをキャッシュします。 |
キャッシュ可能なリソース（イメージ、CSS、JavaScript）には、必ずキャッシュ・ヘッダーを正しく指定しておくことを強くお薦めします。また、サーバーにないリソースに対するクライアント・リクエストはサーバーへのラウンドトリップが増加する原因となります。これを防ぐには、すべてのリソースがサーバーに存在することを確認してください。 |
|
状態トークン・キャッシュのサイズを小さくします。 |
web.xmlに定義したorg.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENSプロパティにより、トークンベースのクライアント側状態保存において一度に保存するトークンの数を選択します。デフォルト値は15です。これを超えると、表示されてから最も長い時間が経過したページの状態が失われます。「戻る」ボタンを頻繁に使用するユーザーや複数のウィンドウを同時に開くユーザーは、影響を受ける可能性があります。セッションごとの使用中メモリーを減らすには、この値を2に減らすことを検討してください。状態トークン・キャッシュを2に減らした場合、サポートされる「戻る」ボタンのクリック回数は1回になります。「戻る」ボタンがサポートされないアプリケーションについては、この値を1に設定してください。 |
|
カスタム・スタイルをページ先頭で定義します。 |
開発者が共通して行う作業の1つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読み取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスを改善するには、スタイルをページ先頭で定義し、可能であればADFグループ・タグの内側に入れます。 HTMLページは基本的に、ヘッダーと本文の2つの部分からなります。ページに ヘッダーに表示されるコンポーネント（または静的なCDATAコンテンツ）を取得するには、metaContainerファセットを次のように使用します。
<af:document title="#{attrs.documentTitle}" theme="dark">
<f:facet name="metaContainer">
<af:group><![CDATA[
<style type="text/css">
.TabletNavigationGlobal {
text-align: right;
padding-left: 0px;
padding-right: 10px;
white-space: nowrap;
}
HTML[dir=rtl] .TabletNavigationGlobal {
text-align: left;
padding-left: 10px;
padding-right: 0px;
}
</style>
]]>
<af:facetRef facetName="metaContainer"/>
</af:group>
</f:facet>
<af:form ...>
<af:facetRef facetName="body"/>
</af:form>
</af:document>
ページ・テンプレートを使用する場合は、テンプレート定義に
|
|
カスタムJavaScriptコードを最適化します。 |
ADF Rich Clientは、クライアント側でJavaScriptを使用します。必要な機能のほとんどはフレームワークそのものに組み込まれています。しかし、カスタムJavaScriptコードの記述が必要になる場合もあります。最適なパフォーマンスを得るには、JavaScriptコードを1つのJS lib（1つのJavaScriptファイル）にまとめてクライアントに配布することを検討してください。最も簡単な方法は、ADFタグ< ほとんどのページでカスタムJavaScriptコードが必要になる場合は、このタグをアプリケーション・テンプレートに含めてください。それ以外の場合は、特定のページのみに含めることでパフォーマンスを改善できます。カスタムJavaScriptコードのlibファイルが大きくなりすぎた場合は、意味のある単位に分割して、ページに必要な部分のみを含めます。この方法では、ブラウザ・キャッシュが使用され、ページのHTMLコンテンツが小さくなるため、全体として見れば高速になります。 |
|
デバッグ出力モードを無効にします。 |
|
|
テストの自動化を無効にします。 |
テスト自動化パラメータ パフォーマンスを改善するには、 |
|
アニメーションを無効にします。 |
ADF Rich Clientフレームワークでは、クライアント側のアニメーションがデフォルトで有効になっています。アニメーションは、高度なユーザー体験を提供する目的で使用されます。ポップアップ表など、一部のコンポーネントには、一部の操作に対応するアニメーション・セットが用意されています。アニメーションを使用するとユーザー体験を改善できますが、アクションを実行したときのレスポンス時間が長くなる可能性があります。速度が最大の懸念事項である場合は、 |
|
クライアント側のアサーションを無効にします。 |
クライアント側のコード・ベースに対するアサーションは、クライアント側のパフォーマンスに大きな影響を与えることがあります。クライアント側のアサーションを無効にするには、パラメータの値を |
|
JavaScriptのプロファイラを無効にします。 |
JavaScriptの |
|
リソース・デバッグ・モードを無効にします。 |
リソース・デバッグ・モードを有効にすると、ブラウザ（またはWebCache）はリソース（JSライブラリ、CSSスタイルシート、イメージなど）がキャッシュ可能であることをHTTPレスポンス・ヘッダーから判断できません。 キャッシュを確実に有効にするには、 |
|
タイムスタンプのチェックを無効にします。 |
web.xmlファイルで |
|
CSSファイルの変更のチェックを無効にします。 |
|
|
コンテンツの圧縮を有効にします。 |
デフォルトでは、レンダリングされたスタイル・クラスは、ページ・サイズを小さくするために圧縮されます。本番環境では、必ず デバッグの際には、スタイル・クラスのコンテンツの圧縮をオフにします。そのためには、 |
|
JavaScriptの曖昧化を有効にします。 |
ADF Facesは、曖昧化されていないJavaScriptライブラリを提供するためのランタイム・オプションをサポートしています。デフォルトで提供されるのは曖昧化されたJavaScriptライブラリですが、開発ビルド用に曖昧化されていないものも提供されます。曖昧化を行うと、JavaScriptライブラリ全体のサイズが約50%削減されます。 曖昧化されたADF Facesビルドを提供するには、web.xmlファイルで Firebugが有効なFirefoxを使用して、コードが曖昧化されていることを確認するには、2つの方法があります。 ダウンロード・サイズの確認:
ソースの確認:
|
|
ライブラリのパーティション化を有効にします。 |
Oracle 11gリリースでは、ライブラリのパーティション化がデフォルトでオンになっています。旧バージョンでは、ライブラリのパーティション化はデフォルトでオフになっていました。ライブラリのパーティション化がオンになっていることを確認してください。そのためには、web.xmlファイルで |
表7-3に、ADF Facesコンポーネント属性の構成に関する推奨事項を示します。
表7-3 ADF Facesコンポーネント属性
| 構成に関する推奨事項 | 説明 |
|---|---|
|
immediate属性を使用します。 |
ADF Rich Clientのコンポーネントには
ADF Rich ClientはJSFをベースとし、標準のJSFライフサイクルを採用しています。『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のJSFおよびADF Facesのライフサイクルの理解に関する項を参照してください。
これは高度な機能であることに注意してください。パフォーマンス向上効果のほとんどは、 |
|
visible属性およびrendered属性を使用します。 |
ADF Faces Rich Clientのすべての表示コンポーネントには、ページへのコンポーネントの表示方法を指定する2つのプロパティがあります。
通常、これらのプロパティを制御するにはEL式を使用します。パフォーマンスを高めるために、クライアントがコンポーネントとやり取りしない場合は、コンポーネントが（非表示ではなく）レンダリングされないように設定することを検討してください。コンポーネントがレンダリングされないようにすると、そのコンポーネントはクライアント側での表現を持たなくなるため、サーバーのパフォーマンスおよびクライアントのレスポンス時間が改善されます。 |
|
クライアント側イベントを使用します。 |
ADF Rich Clientフレームワークは、DOMレベルではなくコンポーネントレベルのイベントに基づいたクライアント側イベント・モデルを提供します。クライアント側イベント・モデルは、アプリケーションの高速化が可能な、非常に便利な機能です。パフォーマンスに関する次の考慮事項を確認してください。
|
|
id属性を使用します。 |
id属性は、長さが7文字を超えないようにしてください。このことは、ネーミング・コンテナにとって特に重要です。クライアントに送信する必要のあるHTMLの量はIDの長さの影響を受けるため、IDが長いとパフォーマンスに影響が出ます。 |
|
クライアント側コンポーネントを使用します。 |
ADF Rich Clientフレームワークは、クライアント側イベントの処理およびコンポーネントの動作において一定の役割を果すクライアント側コンポーネントを備えています。クライアント側コンポーネントを生成するタイミング（あるいは、生成するかどうか）を構成するには、 詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のクライアント側コンポーネントに関する項を参照してください。 |
|
|
|
table、treeおよびtreeTableは、最も複雑で使用頻度の高いコンポーネントです。これらのコンポーネントは大きなデータ・セットを格納できるため、よくパフォーマンスの問題の原因となります。表7-4に、パフォーマンスに関する推奨事項を示します。
表7-4 tableコンポーネントおよびtreeコンポーネントの構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
表のフェッチ・サイズを変更します。 |
表には、1回のラウンドトリップでクライアントに送信される行数を定義したフェッチ・サイズがあります。最適なパフォーマンスを得るには、この数を最低限に抑えます。ただし、表ビューの初期ポートを実行するのに十分な行を確保してください。そうすることで、最適なパフォーマンスを得ながら余分なサーバー・リクエストを排除できます。 また、表のフェッチ・サイズとイテレータの範囲サイズを合せることを検討してください。デフォルトでは、表のフェッチ・サイズはEL式 詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表およびツリーの使用に関する項を参照してください。 |
|
列の拡大を無効にします。 |
tableコンポーネントおよびtreeTableコンポーネントの列は、最後の列の端とtableコンポーネントまたはtreeTableコンポーネントの輪郭との間に未使用の領域が残らないよう、拡大することができます。この機能は、パフォーマンスに影響を与える可能性があるため、デフォルトでオフになっています。この機能をオンにすると、クライアントのレンダリング時間に影響が出ることがあります。したがって、この機能を複雑な表に対して有効にするときは十分に注意してください。 詳細は、Oracle Fusion Applicationsの開発者ガイドの列の拡大の使用に関する項を参照してください。 |
|
ヘッダー行および固定列は必要な場合にのみ使用することを検討します。 |
tableコンポーネントには、行ヘッダーおよび固定列を設定できる機能があります。これらのオプションを使用すると、優れたデザインのインタフェースを作成でき、ユーザー体験も向上します。ただし、クライアント側のパフォーマンスに影響が出る可能性があります。tableコンポーネントで最適なパフォーマンスを得るには、これらのオプションを必要な場合にのみ使用します。 |
autoSuggestは、inputText、inputListOfValues、inputComboboxListOfValuesの各コンポーネントに対して有効にできる機能です。ユーザーが入力フィールドに文字を入力すると、コンポーネントは候補となる項目のリストを表示します。この機能により、データベース表で問合せが実行され、結果がフィルタ処理されます。データベース処理を高速化するために、autoSuggestが有効になっている列にデータベース索引を作成してください。そうすることで、特にデータベース表の行数が多い場合に、コンポーネントのレスポンス時間が改善されます。
table、tree、その他のスタンプ設定されたコンポーネントのデータは、遅延配信または即時配信が可能です。デフォルトでは、遅延配信が使用されます。つまり、サーバーからの最初のレスポンスではデータは配信されません。初期ページがレンダリングされた後、クライアントがサーバーにデータを要求し、2番目のリクエストへのレスポンスとしてデータを取得します。
即時配信の場合は、ページ・リクエストへのレスポンスと同時にデータを取得できます。データ配信が行われるのはコンポーネントごとであり、ページごとではないので注意してください。つまり、この2つを同じページ上に混在させることが可能です。
この2つのオプションから選択する際には、次の点を考慮してください。
| 遅延配信（デフォルト） | 遅延配信は、ユーザーが下にスクロールしないとコンテンツがすぐには見えないようなページで使用します。この場合、目に見えるコンテンツがクライアントに短時間で配信されるため、パフォーマンスの向上がユーザーにも感じられます。
遅延配信は、データ・ストリーミング技術を使用して実現されます。この方式が優れているのは、サーバーがデータ・フェッチを並行して実行し、データが使用可能になると同時に、そのデータをクライアントへストリーミング配信することが可能な点です。この方式は、ページに表が2つあり、一方の表ではデータがごく短時間で返され、もう一方の表ではデータが返されるまで長時間かかるといった場合に、高い効果を発揮します。高速な表のデータは、取得されると同時にユーザーに対して表示されます。 データ・フェッチを並行して実行することで、データ・フェッチの総所要時間も短縮されます。時間のかかるデータ・フェッチを複数行う必要がある場合は、このことが遅延ロードの利点となります。 |
| 即時配信 | 即時配信（contentDelivery="immediate"）を使用するのは、表データ・コントロールが高速な場合、または小さいデータ・セットを返す場合です。このような場合には、遅延配信を使用するよりレスポンス時間が短くなります。
即時配信のもう1つの利点は、遅延配信に比べてサーバー・リソースの使用率が低いことです。即時配信では、サーバーに送信されるリクエストは1つのみなので、特定のユーザー・インタラクションにおけるCPUおよびメモリーの使用率が低下します。 |
DVTコンポーネントは、ADF Rich Clientコンポーネントをベースとするデータ視覚化コンポーネントです。DVTコンポーネントには、グラフ、ゲージ、ガント・チャート、ピボット・テーブル、マップなどがあります。表7-5に、DVTコンポーネントの構成に関する推奨事項を示します。
表7-5 DVTコンポーネントの構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
RangeSize属性を使用します。 |
RangeSize属性は、同時に返す行の数を定義します。RangeSizeに値-1を指定すると、イテレータはすべての行を返します。小さい値を使用すればパフォーマンスは向上しますが、データを止めるのが難しくなる場合があります。また、rangeSizeを超えるデータはビューに表示されません。 |
|
縦方向のテキストではなく横方向のテキストを使用します。 |
デフォルトでは、ピボット・テーブルの列ヘッダーとして横方向のテキストが使用されます。ただし、縦方向のテキストを使用するオプションもあります。縦方向のテキストを使用するには、ヘッダー・フォーマットとして次のようなCSSスタイルを指定します。
縦方向のテキストのほうが見栄えがよいこともありますが、Firefoxブラウザを使用する場合はパフォーマンスに影響が出ます。 問題なのは、FirefoxがInternet Explorerのように縦方向のテキストに対応していないことです。縦方向のテキストを表示するために、ピボット・テーブルではGaugeServletによって生成されたイメージが使用されます。テキストは動的で、バインディング値に依存しているので、このイメージをキャッシュすることはできません。そのため、ピボット・テーブルをレンダリングするたびに、イメージをフェッチする目的でサーバーへの余分なラウンドトリップが発生し、ネットワーク・トラフィック、サーバーのメモリーおよびCPUに影響を与えます。 最適なパフォーマンスを得るには、縦方向のテキストではなく横方向のテキストを使用することを検討してください。 |
Oracle ADFサーバー・コンポーネントは、ADF内のUI以外のコンポーネントからなります。これには、モデル・レイヤーのADF実装（ADFm）、ビジネス・サービス・レイヤーのADF実装（ADFbc）、およびコントローラ・レイヤーのADF実装（ADFc）が含まれます。サーバー・コンポーネントは自由に構成できますが、重要なのは、指定したアプリケーション・パフォーマンスおよび機能を備える使用可能リソースに最適な構成の組合せを選択することです。
ビュー・オブジェクト（VO）にはチューニング・オプションが数多く用意されているため、開発者はアプリケーション固有のニーズに合せてビュー・オブジェクトをカスタマイズできます。ビュー・オブジェクトは、機能要件を満たすのに必要な最小限の機能セットを使用するよう構成してください。ビュー・オブジェクトのチューニングについては、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』に詳しい説明があります。ここでは、ビュー・オブジェクトのパフォーマンスに関するヒントをいくつか示します。
ビュー・オブジェクトのパフォーマンスを最大化するには、ビュー・オブジェクトを目的の用途に合致させる必要があります。たとえば、値リストのピックリスト用に取得されたデータは読取り専用であるのが一般的です。したがって、このデータを問い合せるには、読取り専用のビュー・オブジェクトを使用します。ビュー・オブジェクトをアプリケーション固有のニーズに合せてカスタマイズすると、パフォーマンス、メモリー使用率、CPU使用率およびネットワーク使用率を改善できます。
| ビュー・オブジェクトのタイプ | 説明 |
|---|---|
| 読取り専用のビュー・オブジェクト | ビュー・オブジェクトがデータの挿入や更新を行う必要がない場合は、読取り専用のビュー・オブジェクトの使用を検討してください。読取り専用のビュー・オブジェクトには2つの種類があります。
更新不可能なEOベースのビュー・オブジェクトには、カスタマイズ可能な選択リストによってUIで必要とされる属性を実行時に取得できる、ローカル・キャッシュからデータを読み取ることができる（データベース問合せの再実行が不要）、同じEOに基づいた他の更新可能なビュー・オブジェクトとの間でデータの一貫性を確保できる、といった利点があります。 エキスパートモードのビュー・オブジェクトには、EOがサポートしていないSQL操作を実行し、ビュー・オブジェクトとEOの行の連携によって発生するパフォーマンスへのわずかな影響を回避するという機能があります。EOベースのビュー・オブジェクトに対して選択したEOでupdatableオプションを選択解除すると、そのビュー・オブジェクトは更新不可能としてマークされます。また、ビュー・オブジェクトのXML定義で |
| 挿入専用のビュー・オブジェクト | レコードを挿入する目的でのみ使用されるビュー・オブジェクトの場合、そのビュー・オブジェクトを使用する際に不要なSELECT問合せが実行されるのを防ぐことができます。そのためには、ビュー・オブジェクトの概要タブの「データベースから取得」グループ・ボックスでオプション「行なし」を設定します。これで、ビュー・オブジェクト定義のMaxFetchSizeが0（ゼロ）に設定されます。 |
| 実行時に作成されるビュー・オブジェクト | AMでcreateViewObjectFromQueryStmt() APIを使用すると、ビュー・オブジェクトを実行時に作成できます。ただし、パフォーマンスに影響が出る可能性があり、チューニングも複雑になるため、実行時に作成されるビュー・オブジェクトを使用するのは絶対に必要でないかぎり避けてください。 |
ビュー・オブジェクトのパフォーマンスは、ビュー・オブジェクトによるデータ・フェッチがどのように構成されているかによって大きく変わります。フェッチ・オプションがアプリケーションに対して正しくチューニングされていないと、ビュー・オブジェクトが必要以上のデータをフェッチしたり、データベースへのラウンドトリップの回数が多くなりすぎたりする可能性があります。フェッチ・オプションは、図7-1に示した「ビュー・オブジェクト」ダイアログの「データベースから取得」グループ・ボックスで構成できます。
| フェッチ・オプション | 説明 |
|---|---|
| フェッチ・モード | デフォルトのフェッチ・オプションは「すべての行」オプションです。この場合、必要に応じて取得（FetchMode="FETCH_AS_NEEDED"）するか、一度にすべて取得（FetchMode="FETCH_ALL"）するか、適切なほうのオプションを選択します。「必要に応じて」オプションを指定すると、ビュー・オブジェクトに対するexecuteQuery()操作によって、表示される最初のページに必要な数の行のみがまず取得されます。行数は、ビュー・オブジェクトの範囲サイズに基づいて設定されます。 |
| フェッチ・サイズ | 「次の単位で」フィールドは、フェッチ・モード・オプションとともに、データベースから同時にフェッチされるレコードの数を制御します（ビュー・オブジェクトのXMLのFetchSize）。デフォルト値は1ですが、この値では、1行のみフェッチされる場合を除き、パフォーマンスに影響を与える可能性があります。推奨構成として、この値をn+1に設定することをお薦めします。nはユーザー・インタフェースに表示される行数です。
DVTオブジェクトについては、フェッチ・サイズをn+1に設定してください。nは、rangeSizeか、rangeSizeが-1の場合は予想される最大行セット・サイズです。 |
| 最大フェッチ・サイズ | ビュー・オブジェクトのデフォルト最大フェッチ・サイズは-1です。つまり、ビュー・オブジェクトがフェッチできる行の数に制限はありません。最大フェッチ・サイズを0（ゼロ）に設定すると、ビュー・オブジェクトは挿入専用になります。結果セットにn行のデータのみを含める場合は、「行番号までのみ」オプションを選択して設定するか、setMaxFetchSize(N)をコールしてこれをプログラム的に設定します。この設定を手動で行うには、パラメータMaxFetchSizeをビュー・オブジェクトのXMLに追加します。
ビュー・オブジェクトのWHERE句に単一行を取得することを指定するには、「最大で1行」オプションを設定します。このオプションを設定すると、ビュー・オブジェクトは行がそれ以上返されないことを認識し、その状況における通常のテストを省略します。この場合、SELECT問合せは発行されず、行はフェッチされません。 最大フェッチ・サイズを使用して、何百（または何千）もの行を返す非選択的な問合せが与える影響を抑えることもできます。その場合は、最大フェッチ・サイズを指定することで、フェッチしてメモリーに格納することのできる行の数が制限されます。 |
| 順方向専用モード | データ・セットが順方向にのみトラバースされる場合は、順方向専用モードを使用すると、データ・セットを反復する際のパフォーマンスが向上します。これを構成するには、ビュー・オブジェクトに対してsetForwardOnly(true)をプログラム的にコールします。順方向専用に設定すれば、データ・セットのトラバースの際に前の行セットがキャッシュされるのを防ぐこともできます。 |
表7-6に、ビュー・オブジェクト使用時のチューニングに関するその他の考慮事項を示します。
表7-6 ビュー・オブジェクトのその他の構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
大きなデータ・セットを最適化します。 |
ビュー・オブジェクトは、ユーザーが結果の特定のページにジャンプできるように、大きなデータ・セット内でページ移動するメカニズムを備えています。これを構成するには、ビュー・オブジェクトに対して |
|
可能であればスピルオーバー構成を無効にします。 |
JVMコンテナのメモリーが不足した場合は、データ・ソースを仮想メモリーとして使用できます。デフォルトでは、この機能は無効になっていますが、（必要な場合は） |
|
SQLスタイルの構成を確認します。 |
SQL92準拠の汎用データベースにSQL92の汎用SQLスタイルを使用して接続する場合は、ビュー・オブジェクトの一部のチューニング・オプションが適用されません。ビュー・オブジェクトのフェッチ・サイズは、そのようなチューニング・オプションの1つです。SQL92のSQLスタイルを使用した場合、ビュー・オブジェクトの構成にかかわらず、フェッチ・サイズはデフォルトで10行に設定されます。SQLスタイルは、データベース接続の定義時に設定されます。デフォルトでは、Oracleデータベース接続を定義する際のSQLスタイルは |
|
ビュー・オブジェクトの問合せにバインド変数を使用します。 |
ビュー・オブジェクトに関連付けられた問合せに、実行のたびに変わる可能性のある値が含まれる場合は、バインド変数の使用を検討してください。そうすることで、データベースへの問合せを再解析する必要がなくなります。バインド変数は、ビュー・オブジェクト定義の「問合せ」セクションでビュー・オブジェクトに追加できます。 |
|
ビュー・オブジェクトの問合せに問合せオプティマイザ・ヒントを使用します。 |
ビュー・オブジェクトからデータベースにヒントを渡して、関連する問合せで使用される実行計画に影響を与えることができます。オプティマイザ・ヒントは、「データベースから取得」グループ・ボックスで指定できます。 |
|
動的SQL生成を使用します。 |
ビュー・オブジェクトは、設計時にSQL文を定義するかわりに、実行時にSQLを動的に生成するよう構成できます。ビュー・オブジェクト・インスタンスがSQL文を動的に生成するように構成されていれば、データベースへの再問合せが不要になります。この効果は、ページ・ナビゲーションの際に、同じキーEOリストを持つすべての属性のサブセットが後続のページ・ナビゲーションで使用される場合に、特に大きくなります。必要なすべての属性のスーパーセットを有効にすると、後続の問合せを実行する必要がなくなり、パフォーマンスが向上します。 |
バッチ処理とは、操作をデータベースへ送信する際に、複数の挿入、更新および削除をまとめて処理できる機能です。この機能をEOに対して有効にするには、EOの「一般」タブの「チューニング」セクションで「バッチ更新を使用」チェック・ボックスを選択するか、EOのXMLファイルを直接変更して、バッチ・サイズを指定したパラメータBatchThresholdをEntity属性に追加します。
BatchThresholdの値は、操作を一度に1つずつ実行するかわりに、複数の操作のグループをバッチにまとめるかどうかの基準となるしきい値です。しきい値に達しない場合、行は一度に1つずつ処理されます。一方、しきい値を超える数の行は、単一のバッチにまとめることができます。
挿入後にリフレッシュする（RetrievedOnInsert="true"）、または更新後にリフレッシュする（RetrievedOnUpdate="true"）よう構成されたEOの属性が存在する場合、EOのBatchThreshold構成は共存できませんので注意してください。
このパラメータは、ADFmがBCレイヤーから同時にリクエストするレコードの数を制御します。デフォルトのRangeSizeは25レコードです。この値を、ビュー・オブジェクトのUIに同時に表示するレコードの数に設定して、モデルとBCレイヤーの間のラウンドトリップ回数を1回に減らすことを検討してください。これは、対応するページのページ定義XMLのIterator属性で構成します。
アプリケーション・モジュールの粒度の設計は、パフォーマンスおよびスケーラビリティに大きな影響を与える重要な考慮事項です。各ルート・アプリケーション・モジュールは通常、専用のデータベース接続を保持していることに注意してください。ユーザー・セッションが複数のルート・アプリケーション・モジュールを消費する場合、そのユーザー・セッションは同時に複数のデータベース接続を保持している可能性があります。このような状況は、アプリケーション・モジュールとユーザー・セッションの間で全般的なアフィニティが維持されるために、接続が実際には使用されていない場合でも発生します。ユーザーが同時に複数の接続を保持する可能性を減らすには、次の方法を検討します。
ユーザーが必要とする機能をすべて網羅した大きなアプリケーション・モジュールを設計します。
小さなアプリケーション・モジュールを単一のルート・アプリケーション・モジュールの下にネストし、ネストされたアプリケーション・モジュールの間で同じデータベース接続を共有できるようにします。
アプリケーション・モジュールで遅延ロードを使用します。アプリケーション・モジュールのチューニング・セクションで、遅延ロードを使用するように実行時のインスタンス化動作をカスタマイズします。遅延ロードは、次のJVM引数を追加して、JVM全体で設定することもできます。
-Djbo.load.components.lazily=true
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュールの粒度に関する項およびネストされたアプリケーション・モジュールの定義に関する項を参照してください。
アプリケーション・モジュール（AM）・プーリングを使用すると、複数のユーザーが複数のアプリケーション・モジュール・インスタンスを共有できます。AMプールの構成は、予想されるアプリケーションの使用状況によって異なります。様々なAMプール構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュール・プールのチューニングに関する項を参照してください。
ほとんどのAMプール・パラメータは、Oracle JDeveloperを介して設定できます。構成内容はbc4j.xcfgに保存されますが、必要に応じて手動で編集できます。パラメータをJVMパラメータ（-Dプロパティ=値）として指定し、システム・レベルで設定することもできます。bc4j.xcfgの構成は、JVMの構成より優先されます。そのため、システムレベルの汎用構成をアプリケーション固有の例外で上書きすることも可能です。
表7-7 アプリケーション・モジュール（AM）・プールのチューニング
| 構成に関する推奨事項 | 説明 |
|---|---|
|
アプリケーションのAMプール数を最適化します。 |
システムレベルで適用されるパラメータは、AMプール単位で適用されます。アプリケーションで複数のAMプールを使用する場合は、AMインスタンス数を表すシステムレベルの値にAMプール数を掛けて、システムで指定されている実際の制限の合計を把握する必要があります。たとえば、アプリケーションが4つの独立したAMプールを使用してアプリケーションにサービスを提供しており、システムレベルの構成によってAMプールの最大サイズが100に制限されている場合、AMインスタンスの最大数は400になります（4つのプール * 最大プール・サイズ100）。目的とするのがアプリケーション全体で最大プール・サイズを100に制限することであれば、システムレベルの構成では最大プール・サイズとして25を指定する必要があります（最大プール・サイズ100 / 4つのプール）。JDevを介して、または直接bc4j.xcfgで各プールを別々に構成すれば、各AMプールの構成をさらにきめ細かく行うことができます。 |
|
データベース接続数を最適化します。 |
デフォルトでは、AMインスタンスはAMプールに戻された後もデータベース接続を保持します。この関連付けを維持することには、パフォーマンス上、多くの利点があります。パフォーマンスを確保するには、指定したデータベース接続の最大数より多くのASMインスタンスを構成することを検討してください。 注意: AMプールの1つをルート・プールとして使用する必要がある場合は、そのAMプール・レベルでのチューニングを検討してください。使用頻度の低いプールについては、トップレベルのアプリケーション・パラメータが使用されないように、プール・サイズをプール・レベルでチューニングすることを検討してください。 詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のプール構成パラメータの設定に関する項を参照してください。 |
次のガイドラインは、AMおよびAMプールの動作をチューニングする際の一般的な出発点として使用してください。各パラメータの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。メモリー使用率またはCPU使用率の具体的なチューニングについては、7.3.5.2項「AMプール・サイズの構成」を参照してください。
表7-8 AMプールのチューニング・パラメータ
| パラメータ | 説明 |
|---|---|
|
|
プールの初期化時に作成するアプリケーション・モジュール・インスタンスの数を指定します（デフォルトはゼロです）。初期プール・サイズをゼロ以外に設定すると、アプリケーションの初期化にかかる時間が増えますが、その後、AMインスタンスを必要とする操作のパフォーマンスは向上します。一般的なガイドラインとして、この値は、すべてのユーザーへのサービス提供に必要な同時AMインスタンスの予想数より10%多くなるように構成してください。 |
|
|
プールで割り当てることのできるアプリケーション・モジュール・インスタンスの最大数を指定します（デフォルトは4096です）。この制限を超える数のアプリケーション・モジュール・インスタンスは作成できません。一般的なガイドラインとして、この値は、さらなる増加分を見込んで初期プール・サイズより20%大きくなるように構成してください。 |
|
|
リソース・クリーンアップ処理時にプール・モニターがプールに残す、使用可能なアプリケーション・モジュール・インスタンスの最小数を指定します（デフォルトは5です）。この構成の最小値は、AMプールを再作成するコストが発生しないよう、1以上に設定するのが理想的です。ゼロ（0）に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールそのものがクリーンアップされます。 |
|
|
負荷が異常でない場合に理想的な、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します（デフォルトは25です）。プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンスのタイムアウトより長い期間使用されていなかったインスタンスは、この時点でクリーンアップされます。その後、使用可能なインスタンスの数をこのサイズまで下げるために必要な場合は、使用可能なインスタンスがさらに削除されます。 |
|
|
管理状態モードでプールに解放される前に、自身を最後に使用したセッションが次に行うリクエストに備えてセッション・アフィニティを保持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します（デフォルトは10です）。参照されるプール・サイズは常に最大プール・サイズ以下になるようにしてください。そうすれば、設定された数の使用可能インスタンスが、管理状態モードで自身を解放した直近のセッションとのアフィニティに従うようになります。一般的なガイドラインとして、この値は、短い思考時間で複数の操作を実行する同時ユーザーの予想数に設定してください。短い思考時間でアプリケーションを使用する予定のユーザーがいない場合は、この値を0（ゼロ）に設定して、アフィニティを解消してもかまいません。 |
|
|
アプリケーション・モジュール・インスタンスがプール内に存在する時間（ミリ秒）を指定します。この時間が過ぎると、インスタンスは次のリソース・クリーンアップでの削除の候補となります。クリーンアップの結果、プール内のインスタンス数が |
|
|
プール内の非アクティブなアプリケーション・モジュール・インスタンスが次のリソース・クリーンアップでの削除の候補とみなされるまでの時間（ミリ秒）を指定します（デフォルトは600000ミリ秒、つまり10分です）。 |
|
|
プールのリソース・クリーンアップの間隔（ミリ秒）を指定します（デフォルトは600000ミリ秒、つまり10分です）。プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールからの削除の候補になっている使用可能インスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。 |
|
|
フェイルオーバーを無効にするか有効にするかを指定します。デフォルトでは、フェイルオーバーは無効になっています。フェイルオーバーを有効にするには、このパラメータを |
|
|
ロック・モード（ |
|
|
AMインスタンスがAMプールに戻されたときに、そのAMインスタンスをデータベース接続から切断できるかどうかを指定します。これにより、アプリケーションのAMプールをデータベース接続プールより大きなサイズに設定することができます。デフォルトは |
|
|
|
次のAMプール・サイズ・パラメータは、AMプール・サイズを制御します。次の値を調整して、メモリーまたはCPUの使用率をチューニングすることを検討してください。
システムのメモリーに制約がある場合に構成可能なパラメータについては、表7-9を参照してください。
表7-9 AMプール・サイズの構成 - メモリーに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
|
追加のAMインスタンスが必要な場合は、これを小さい値に設定するとメモリーを節約できますが、パフォーマンスの低下というコストが発生します。デフォルト値の0（ゼロ）の場合、AMプールの初期化時にAMインスタンスが作成されません。 |
|
|
これを構成すると、AMインスタンスの数が指定の値を超えるのを防止できます。ただし、設定した値が小さすぎると、使用可能なAMインスタンスがない場合に、アプリケーションへのアクセス・エラーが発生することがあります。 |
|
|
ゼロ（0）に設定すると、リソース・クリーンアップ後、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
|
これを構成すると、リソース・クリーンアップ後に指定した最大数の使用可能インスタンスを残すことができます。 |
構成するとCPUの負荷をある程度軽減できるパラメータについては、表7-10を参照してください。
表7-10 AMプール・サイズの構成 - CPUに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
|
この値は、アプリケーション・プールの初期のAMインスタンス数に設定します。初期化時にAMインスタンスを作成する場合、追加のAMインスタンスが必要になったときにオンデマンドで作成するのではなく、初期化時に作成するためのCPU処理コストがかかります。 |
|
|
ユーザーのセッションに対するAMインスタンスのアフィニティを維持するには、この値を設定します。このアフィニティを可能なかぎり維持することで、あるユーザーから別のユーザーへAMインスタンスを切り替える際に必要なCPU処理コストを削減できます。 |
次のパラメータは、AMプールのリソース・クリーンアップの頻度および特性に影響を与えます。リソース・クリーンアップの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
システムのメモリーに制約がある場合は、より多くのAMインスタンスをより頻繁にクリーンアップするようAMプールを構成します。そうすることで、AMインスタンスによって消費されるメモリーを解放して、他の目的で使用できるようになります。ただし、使用可能なAMインスタンスの数を減らしてクリーンアップの頻度を高めると、CPU使用率が上昇し、レスポンス時間も長くなる可能性があります。詳細は、表7-11を参照してください。
表7-11 AMプールのリソース・クリーンアップの構成 - メモリーに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
|
ゼロ（0）に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
|
一般に、値を小さくすると、クリーンアップ時にプールから削除されるAMインスタンスが増加します。 |
|
|
値を小さくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が短くなります。 |
|
|
値を小さくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが増加します。 |
|
|
これは、リソース・クリーンアップがトリガーされる頻度を制御します。間隔を短く設定すると、メモリーの節約のために非アクティブのAMインスタンスが削除される頻度が高まります。 |
AMプールを構成して、より多くのAMインスタンスがより長い期間プール内に存在できるようにすることで、CPU処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。
表7-12 AMプールのリソース・クリーンアップの構成 - CPUに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
|
これらを大きな値に設定すると、プール内に残されるアイドル・インスタンスが増えるため、後でAMインスタンスを再作成する必要がなくなります。ただし、過度に大きな値を設定して、最大負荷時に必要な数より多くのAMインスタンスを保持することは避けてください。 |
|
|
値を大きくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が長くなります。 |
|
|
値を大きくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが減少します。 |
|
|
大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。 |
ページにリージョンを追加すると、アプリケーションが大きく強化されます。ただし、リージョンはページで大量のリソースを消費するコンポーネントでもあります。パフォーマンスを高めるには、特定の機能が必要とされる場合にのみリージョンの使用を検討してください。
アプリケーション全体で再利用可能な静的データがアプリケーションに含まれている場合、共有アプリケーション・モジュールを使用してキャッシュ・データを収集できます。共有アプリケーション・モジュールの作成および使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュール・ビュー・インスタンスの共有に関する項を参照してください。
エンティティ属性に対してリソース消費量の多い検証を実行するときは、事前条件を使用し、必要な場合にのみ検証を選択して適用することを検討してください。検証のコストを事前条件のコストと比較し、事前条件がパフォーマンス上有益かどうかを判断する必要があります。検証の事前条件を指定する方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の検証の事前条件の設定方法に関する項を参照してください。
