設計、構成およびデプロイメントの考慮事項に配慮しながらOracle Application Development Framework (ADF)をチューニングし、そのパフォーマンスおよびスケーラビリティを最適化できます。
注意:
Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発
Oracle Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発
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 Webアプリケーションの開発で、Oracle ADFの概要に関する項を参照してください。
最適なパフォーマンスを実現するために、チューニングに関する次の考慮事項に従った後、ADFアプリケーションを構築、構成およびデプロイします。
Oracle ADF Facesの構成オプションは、web.xml
ファイルに設定されています。ほとんどの構成オプションには、パフォーマンスを考慮してチューニングされたデフォルト値があります。表9-1に、これらの構成オプションの一部を示します。
表9-1 ADFの構成オプション
パラメータ | 説明 |
---|---|
圧縮ビューの状態
|
ページ状態を圧縮するかどうかを制御します。データのサイズが圧縮されると、待機時間を減らすことができます。このパラメータは |
拡張デバッグ
|
出力をデバッグ用に拡張するするかどうかを制御します。このパラメータは削除するか、 |
ファイル変更の確認
|
ADF FacesがJSPページの変更日付をチェックして、ファイルに変更があった場合は保存されている状態を破棄するかどうかを制御します。このパラメータは削除するか、 |
クライアント状態のメソッド
|
クライアント側での状態の保存が有効になっている場合に、どのタイプの保存( |
クライアント側ログ・レベル |
クライアント側のログ・レベルを設定します。デフォルト値は |
アサーション処理
|
クライアント側でアサーションをいつ処理するかを指定します。デフォルト値は |
注意:
Firefoxブラウザを使用してクライアントのレスポンス時間のプロファイリングまたは測定を行う際には、Firebugプラグインが無効になっていることを確認してください。ページの情報を取得したり、ページのJavaScriptコードをデバッグしたりする目的では、このプラグインは非常に有効ですが、総レスポンス時間に影響を与える可能性があります。
Firefox Firebugプラグインの無効化の詳細は、Firefox Support Home Page (http://support.mozilla.com/en-US/kb/
)を参照してください。
表9-2に、ADF Facesのパフォーマンス向上につながる、構成に関する推奨事項を示します。
表9-2 ADF Facesの構成パラメータ
構成に関する推奨事項 | 説明 |
---|---|
ページでインラインJavaScriptの使用を避けます。 |
インラインJavaScriptは、レスポンス・ペイロード・サイズを増加させる可能性があり、ブラウザにまったくキャッシュされないため、ブラウザのレンダリングをブロックすることがあります。インラインJavaScriptを使用するかわりに、すべてのスクリプトをJavaScriptライブラリ内の ヒント: 可能な場合は |
JSPタイムアウト・パラメータを構成します。 |
JavaServer Pages (JSP)タイムアウト・パラメータを使用すると、 <servlet>
<servlet-name>
oraclejsp
<init-param>
<param-name>
jsp_timeout
</param-name>
<param-value>
x
</param-value>
</init-param>
</servlet-name>
</servlet>
注意: パラメータxは各自のユースケース・シナリオに基づいて設定してください。 |
ドロップダウン・ポップアップを使用して単一のツールバー項目を作成します。 |
画面解像度のためにブラウザ・サイズが小さい場合、Internet Explorer 7および8ではメニューバーまたはツールバーのオーバーフロー・ロジックが高コストになります。特に、入力フィールドを持つDOM構造のレイアウトに問題があります。 ドロップダウン・ポップアップを使用して単一のツールバー項目を作成し、すべての入力フィールドをその中に入れます。このポップアップは、子の作成および |
不明なrowCountを削除します。 |
不明な ビュー・オブジェクト(VO)で |
ユーザーが表示できないポップアップを無効にします。 |
fnd:attachmentコンポーネントは、表にスタンプ設定されると、大量のDOMおよびクライアント・コンポーネントを生成する可能性があります。DOMおよびクライアント・コンポーネントの量は、1セル当たり8Kまでですが、特に速度の遅いブラウザではページ全体のパフォーマンスに影響を与えます。 ほとんどのセルには、最初は添付ファイルがなく、ユーザーが表示できるポップアップは1つのみです。したがって、ユーザーが表示できないポップアップには、 |
ナビゲーション・リンクでホバー・ポップアップを使用しないでください。 |
ナビゲーション・リンクでホバー・ポップアップを使用すると、ナビゲーションはホバーが最初にフェッチされるのを待機します。 補正要員表のナビゲーション・リンク列のホバー・ポップアップを削除し、かわりに別の列かセル内のアイコンに配置することを検討してください。 |
表のスクロール・タイムアウトを増やします。 |
表は、タイムアウト後、スクロールについてフェッチ・リクエストをサーバーに送信します。タイムアウト(フェッチがサーバーに送信されるまで)は、ユーザーが短いスクロールを行う場合、通常20ミリ秒ですが、ユーザーがさらにスクロールする場合は200ミリ秒に増やすことができます。したがって、ユーザーがページの一番下までスクロールし、表が複数のリクエストをサーバーに送信すると、パフォーマンスに影響が出る可能性があります。 パフォーマンスに影響が出ないようにするには、タイムアウト制限を300ミリ秒に増やすことを検討してください。 |
タイムアウトを使用して_prepareForIncompleteImagesをコールします。 |
部分ページ・レンダリング(PPR)中、一部のイメージが完全にロードされないことがあります。この事象が発生した場合、子孫の1つのサイズが変更されたことを親コンポーネントに通知する必要があります。これまで、この通知はimageタグの Internet Explorer 8の場合、 |
GetFirstVisibleRowKeyandRowをキャッシュします。 |
パフォーマンスは、最初の表示可能なRowkeyおよび行をローカルにキャッシュすると向上する可能性があります。このキャッシュされた値は、スクロールまたはサイズ変更で削除できます。 |
部分ページ・ナビゲーションを使用します。 |
部分ページ・ナビゲーションはADF Facesフレームワークの機能です。これを使用すると、ブラウザであるADF Facesページから別のADF Facesページへ移動する際に、ページ全体の遷移が不要になります。新しいページは、部分ページ・レンダリング(PPR)/Ajaxチャネルを使用してクライアントに送信されます。 従来のページ全体のナビゲーションと比較した部分ページ・ナビゲーションの主な利点は、パフォーマンスの向上です。ブラウザがJavaScriptライブラリを再度解釈して実行する必要はなく、ページ全体のクリーンアップ/初期化に時間を費やすこともありません。このような最適化から得られるパフォーマンス上の利点は非常に大きいため、部分ページ・ナビゲーションは可能なかぎり有効にしてください。 この機能には次のような既知の制限があります。
|
ページ・テンプレートを使用します。 |
ページ・テンプレートとは、開発者がデータ・バインドされた再利用可能なテンプレートを作成して、これを任意のページのシェルとして使用できる機能です。開発者は、Webページを作成する他の開発者に構成を伝えて一貫性を確保するためのテンプレートを1つ以上作成できます。テンプレートには、使用時に変更できない静的領域と、開発者が作成中のページ固有のコンテンツを配置できる動的領域があります。 テンプレートを使用する際の重要な考慮事項を次に示します。
|
ADF Rich Clientのジオメトリ管理を有効にします。 |
ADF Rich Clientは、親コンポーネントが明示的にUIに含められているブラウザ・レイアウトのジオメトリ管理をサポートしています。子コンポーネントは、ブラウザの使用可能領域一杯まで広がるようサイズ設定されます。この機能を使用するとUIの見栄えはよくなりますが、コストが発生します。影響が出るのはクライアント側です。これは、ブラウザがコンポーネントのサイズを変更するのに時間がかかるためです。デフォルトでジオメトリ管理の対象となるコンポーネントは次のとおりです。
注意:
|
ADF Rich Clientのオーバーフロー機能を使用します。 |
ADF Rich Clientはオーバーフロー機能をサポートしています。この機能は、ページに収まらない子コンポーネントを、目に見えないオーバーフロー領域に移動するというものです。オーバーフローのサポートが組み込まれているコンポーネントは、 オーバーフローのコストを軽減するために最適化がいくつか行われていますが、オーバーフロー・コンポーネントにおける子コンポーネントの数とそれぞれの複雑さに特に注意を払うことが必要です。オーバーフロー・コンポーネントの初期サイズを十分に大きく設定し、オーバーフローがほとんど発生しないようにすると効果的な場合もあります。 |
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 Webアプリケーションの開発を参照してください。 ページに
前述の手順により、コマンド・ボタンを使用して部分ページ・リフレッシュをトリガーするPPRが実現します。 部分ページ・レンダリングによってパフォーマンスが大幅に向上する主な理由は、ページ全体のリフレッシュが発生せず、フレームワーク・アーティファクト(ADF Rich ClientのJSライブラリやスタイルシートなど)がリロードされるかわりに、ページの小さい部分のみがリフレッシュされることです。そのため、余分なデータのフェッチやジオメトリ管理が一切行われない場合もあります。 ADF Rich Clientは、部分ページ・レンダリングを使用すればクライアント側で最適なパフォーマンスが得られることを実証しています。クライアント側での影響に加えて、サーバー側の処理が高速化され、サーバー側のスループットおよびスケーラビリティが向上します。 |
ADF Rich Clientのナビゲーションを使用します。 |
ADF Rich Clientは、ナビゲーションを幅広くサポートしています。一般的なユースケースの1つに、タブ付きナビゲーションがあります。これは現在、 ただし、この方法にはデメリットが1つあります。それは、ユーザーがタブを切り替えるたびにページ全体のリフレッシュが発生することです。1つの選択肢として、 |
リソースをキャッシュします。 |
キャッシュ可能なリソース(イメージ、CSS、JavaScript)には、必ずキャッシュ・ヘッダーを正しく指定しておくことを強くお薦めします。また、サーバーにないリソースに対するクライアント・リクエストはサーバーへのラウンドトリップが増加する原因となります。これを防ぐには、すべてのリソースがサーバーに存在することを確認してください。
<servlet-mapping> <servlet-name>resources</servlet-name> <url-pattern>/js/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>resources</servlet-name> <url-pattern>/images/*</url-pattern> </servlet-mapping> |
状態トークン・キャッシュのサイズを小さくします。 |
セッションごとの使用中メモリーを減らすには、この値を |
カスタム・スタイルをページ先頭で定義します。 |
開発者が共通して行う作業の1つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読み取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスを改善するには、スタイルをページ先頭で定義し、可能であればADFグループ・タグの内側に入れます。 HTMLページは基本的に、
<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の |
リソース・デバッグ・モードを無効にします。 |
リソース・デバッグ・モードを有効にすると、ブラウザはリソース(JSライブラリ、CSSスタイルシート、イメージなど)がキャッシュ可能であることをレスポンス・ヘッダーから判断できません。 キャッシュを確実に有効にするには、 |
タイムスタンプのチェックを無効にします。 |
|
CSSファイルの変更のチェックを無効にします。 |
|
コンテンツの圧縮を有効にします。 |
デフォルトでは、レンダリングされたスタイル・クラスは、ページ・サイズを小さくするために圧縮されます。本番環境では、必ず デバッグの際には、スタイル・クラスのコンテンツの圧縮をオフにします。そのためには、 |
JavaScriptの曖昧化を有効にします。 |
ADF Facesは、曖昧化されていないJavaScriptライブラリを提供するためのランタイム・オプションをサポートしています。デフォルトでは曖昧化されたバージョンが提供されますが、開発ビルド用に曖昧化されていないバージョンも提供されます。曖昧化を行うと、JavaScriptライブラリ全体のサイズが約50%削減されます。 曖昧化されたADF Facesビルドを提供するには、 Firebugが有効なFirefoxを使用して、コードが曖昧化されていることを確認するには、2つの方法があります。 ダウンロード・サイズの確認:
ソースの確認:
|
ライブラリのパーティション化を有効にします。 |
Oracle 11g リリースでは、ライブラリのパーティション化がデフォルトでオンになっています。旧バージョンでは、ライブラリのパーティション化はデフォルトでオフになっていました。ライブラリのパーティション化がオンになっていることを確認してください。そのためには、 |
表9-3に、ADF Facesコンポーネント属性の構成に関する推奨事項を示します。
表9-3 ADF Facesコンポーネント属性
構成に関する推奨事項 | 説明 |
---|---|
|
ADF Rich Clientのコンポーネントには
ADF Rich ClientはJSFをベースとし、標準のJSFライフサイクルを採用しています。Oracle Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発で、JSFライフサイクルとADF Facesの使用に関する項を参照してください。
これは高度な機能であることに注意してください。パフォーマンス向上効果のほとんどは、 |
|
ADF Faces Rich Clientのすべての表示コンポーネントには、ページへのコンポーネントの表示方法を指定する2つのプロパティがあります。
通常、これらのプロパティを制御するにはEL式を使用します。パフォーマンスを高めるために、クライアントがコンポーネントとやり取りしない場合は、コンポーネントが(非表示ではなく)レンダリングされないように設定することを検討してください。コンポーネントがレンダリングされないようにすると、そのコンポーネントはクライアント側での表現を持たなくなるため、サーバーのパフォーマンスおよびクライアントのレスポンス時間が改善されます。 |
クライアント側イベントを使用します。 |
ADF Rich Clientフレームワークは、DOMレベルではなくコンポーネントレベルのイベントに基づいたクライアント側イベント・モデルを提供します。クライアント側イベント・モデルは、アプリケーションの高速化が可能な、非常に便利な機能です。パフォーマンスに関する次の考慮事項を確認してください。
|
|
|
クライアント側コンポーネントを使用します。 |
ADF Rich Clientフレームワークは、クライアント側イベントの処理およびコンポーネントの動作において一定の役割を果すクライアント側コンポーネントを備えています。クライアント側コンポーネントを生成するタイミング(あるいは、生成するかどうか)を構成するには、 詳細は、Oracle Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発で、clientComponentをtrueに設定した場合の処理に関する項を参照してください。 |
|
注意: この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。
また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。 |
Table
、Tree
およびTreeTable
は、最も複雑で使用頻度の高いコンポーネントです。これらのコンポーネントは大きなデータ・セットを格納できるため、よくパフォーマンスの問題の原因となります。表9-4に、パフォーマンスに関する推奨事項を示します。
表9-4 tableコンポーネントおよびtreeコンポーネントの構成
構成に関する推奨事項 | 説明 |
---|---|
|
|
可能な場合は、 |
|
表のフェッチ・サイズを変更します。 |
表には、1回のラウンドトリップでクライアントに送信される行数を定義したフェッチ・サイズがあります。最適なパフォーマンスを得るには、この数を最低限に抑えます。ただし、表ビューの初期ポートを実行するのに十分な行を確保してください。そうすることで、最適なパフォーマンスを得ながら余分なサーバー・リクエストを排除できます。 また、表のフェッチ・サイズとイテレータの範囲サイズを合せることを検討してください。デフォルトでは、表のフェッチ・サイズはEL式 詳細は、Oracle Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発で、表、ツリー、およびその他のコレクションベースのコンポーネントの使用に関する項を参照してください。 |
列の拡大を無効にします。 |
|
ヘッダー行および固定列は必要な場合にのみ使用することを検討します。 |
|
|
詳細は、Oracle Fusion Middleware Oracle ADF FacesによるWebユーザー・インタフェースの開発で、表、ツリー、およびその他のコレクションベースのコンポーネントの使用に関する項を参照してください。 |
autoSuggest
は、inputText
、inputListOfValues
およびinputComboboxListOfValues
の各コンポーネントに対して有効にできる機能です。ユーザーが入力フィールドに文字を入力すると、コンポーネントは候補となる項目のリストを表示します。この機能により、データベース表で問合せが実行され、結果がフィルタ処理されます。データベース処理を高速化するために、autoSuggestが有効になっている列にデータベース索引を作成してください。そうすることで、特にデータベース表の行数が多い場合に、コンポーネントのレスポンス時間が改善されます。
table、tree、その他のスタンプ設定されたコンポーネントのデータは、遅延配信または即時配信が可能です。デフォルトでは、遅延配信が使用されます。つまり、サーバーからの最初のレスポンスではデータは配信されません。初期ページがレンダリングされた後、クライアントがサーバーにデータを要求し、2番目のリクエストへのレスポンスとしてデータを取得します。
即時配信の場合は、ページ・リクエストへのレスポンスと同時にデータを取得できます。データ配信が行われるのはコンポーネントごとであり、ページごとではないので注意してください。つまり、この2つを同じページ上に混在させることが可能です。
この2つのオプションから選択する際には、次の点を考慮してください。
遅延配信(デフォルト) |
遅延配信は、表やフェッチ時間の遅いスタンプ設定された他のコンポーネントに使用する必要があります。たとえば、スタンプ設定されたコンポーネントがWebサービス呼出しを使用したデータ・コントロールや遅いデータ・フェッチの他のデータ・コントロールに基づく場合です。ユーザーが下にスクロールしないとすぐに内容が表示されないページにも遅延配信を使用できます。この場合、クライアントに表示されるコンテキストの配信時間が短くなり、ユーザーがパフォーマンスの向上を認識します。 遅延配信は、データ・ストリーミング技術を使用して実現されます。この方式が優れているのは、サーバーがデータ・フェッチを並行して実行し、データが使用可能になると同時に、そのデータをクライアントへストリーミング配信することが可能な点です。この方式は、ページに表が2つあり、一方の表ではデータがごく短時間で返され、もう一方の表ではデータが返されるまで長時間かかるといった場合に、高い効果を発揮します。高速な表のデータは、取得されると同時にユーザーに対して表示されます。 また、並行してデータ・フェッチを実行すると、データ・フェッチの合計時間が短縮されます。これは、複数の遅くなる可能性のあるデータ・フェッチの遅延ロードに利点があります。ストリーミングは遅延モードのデータ配信のデフォルト・メカニズムですが、データ・コントロールのパラレル実行はそうではありません。パラレル実行を有効にするには、ページ定義を開いて、イテレータの 場合によっては、パラレル実行のレスポンス時間が短縮される利点があります。パラレル実行では並行してリクエストを実行する複数のスレッドのために多くのリソースを使用する可能性があり、開くデータベース接続が多くなる場合があります。 ページに複数の遅いコンポーネントが存在し、スタンプ設定されたコンポーネントが異なるデータ・コントロール・フレーム(分離したタスク・フローなど)に属する場合のみ、パラレル実行を使用することを検討してください。パラレル実行がデータ・コントロール・フレーム・レベルで同期化するため、単一のデータ・コントロール・フレームのパラレル実行ではパフォーマンスが改善しない場合があります。 |
即時配信 |
即時配信( 即時配信のもう1つの利点は、遅延配信に比べてサーバー・リソースの使用率が低いことです。即時配信では、サーバーに送信されるリクエストは1つのみなので、特定のユーザー・インタラクションにおけるCPUおよびメモリーの使用率が低下します。 |
DVTコンポーネントは、ADF Rich Clientコンポーネントをベースとするデータ視覚化コンポーネントです。DVTコンポーネントには、グラフ、ゲージ、ガント・チャート、ピボット・テーブル、マップなどがあります。表9-5に、DVTコンポーネントの構成に関する推奨事項を示します。
表9-5 DVTコンポーネントの構成
構成に関する推奨事項 | 説明 |
---|---|
|
|
縦方向のテキストではなく横方向のテキストを使用します。 |
デフォルトでは、ピボット・テーブルの列ヘッダーとして横方向のテキストが使用されます。ただし、縦方向のテキストを使用するオプションもあります。縦方向のテキストを使用するには、ヘッダー・フォーマットとして次のようなCSSスタイルを指定します。
縦方向のテキストの方が見栄えがよいこともありますが、Firefoxブラウザを使用する場合はパフォーマンスに影響が出ます。 問題なのは、FirefoxがInternet Explorerのように縦方向のテキストに対応していないことです。縦方向のテキストを表示するために、ピボット・テーブルでは 最適なパフォーマンスを得るには、縦方向のテキストではなく横方向のテキストを使用することを検討してください。 |
推奨されているチューニングの変更を行った後、ADFサーバーのデプロイメントに固有の変更をさらに追加できます。高度なチューニングの推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
Oracle ADFサーバー・コンポーネントは、ADF内のUI以外のコンポーネントからなります。これには、モデル・レイヤーのADF実装(ADFm)、ビジネス・サービス・レイヤーのADF実装(ADFbc)、およびコントローラ・レイヤーのADF実装(ADFc)が含まれます。サーバー・コンポーネントは自由に構成できますが、重要なのは、指定したアプリケーション・パフォーマンスおよび機能を備える使用可能リソースに最適な構成の組合せを選択することです。
注意:
ADFmを使用するときには、パフォーマンスを維持するために遅延実行の使用を検討し、リフレッシュ状態をモニターしてください。
重要なユーザー・コミュニティを持つADFアプリケーションの場合、デフォルトのセッション・タイムアウトの45分を使用すると、期限切れを待機しているセッションによって保持されるメモリー量がパフォーマンスに悪影響を与えることがあります。保持されるメモリーは物理的に使用可能な量より大きくなる可能性があり、サーバーは負荷を処理できなくなります。公開Webサイトを使用しているユーザーなど、ユーザー数が多い場合は、セッション・タイムアウトをできるだけ短くする必要があります。
パフォーマンスを向上させるには、web.xml
ファイルでセッション・タイムアウトのデフォルト値(分単位)を変更することを検討してください。ユースケース・シナリオで機能するセッション・タイムアウト値を使用します。次の例は、10分のセッション・タイムアウトを示しています。
<session-config> <session-timeout> 10 </session-timeout> </session-config>
ビュー・オブジェクト(VO)にはチューニング・オプションが数多く用意されているため、開発者はアプリケーション固有のニーズに合せてビュー・オブジェクトをカスタマイズできます。ビュー・オブジェクトは、機能要件を満たすのに必要な最小限の機能セットを使用するよう構成してください。ビュー・オブジェクトのチューニング詳細は、Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発を参照してください。ここでは、ビュー・オブジェクトのパフォーマンスに関するヒントをいくつか示します。
ビュー・オブジェクトのパフォーマンスを最大化するには、ビュー・オブジェクトを目的の用途に合致させる必要があります。たとえば、値リストのピックリスト用に取得されたデータは読取り専用であるのが一般的です。したがって、このデータを問い合せるには、読取り専用のビュー・オブジェクトを使用します。ビュー・オブジェクトをアプリケーション固有のニーズに合せてカスタマイズすると、パフォーマンス、メモリー使用率、CPU使用率およびネットワーク使用率を改善できます。
ビュー・オブジェクトのタイプ | 説明 |
---|---|
読取り専用のビュー・オブジェクト |
ビュー・オブジェクトがデータの挿入や更新を行う必要がない場合は、読取り専用のビュー・オブジェクトの使用を検討してください。読取り専用のビュー・オブジェクトには2つの種類があります。
更新不可能なEOベースのビュー・オブジェクトには、カスタマイズ可能な選択リストによってUIで必要とされる属性を実行時に取得できる、ローカル・キャッシュからデータを読み取ることができる(データベース問合せの再実行が不要)、同じEOに基づいた他の更新可能なビュー・オブジェクトとの間でデータの一貫性を確保できる、といった利点があります。 エキスパートモードのビュー・オブジェクトには、EOがサポートしていないSQL操作を実行し、ビュー・オブジェクトとEOの行の連携によって発生するパフォーマンスへのわずかな影響を回避するという機能があります。EOベースのビュー・オブジェクトに対して選択したEOで |
挿入専用のビュー・オブジェクト |
レコードを挿入する目的でのみ使用されるビュー・オブジェクトの場合、そのビュー・オブジェクトを使用する際に不要なSELECT問合せが実行されるのを防ぐことができます。そのためには、「ビュー・オブジェクトの概要」タブの「データベースから取得」グループ・ボックスでオプション「行なし」を設定します。これで、ビュー・オブジェクト定義の |
実行時に作成されるビュー・オブジェクト |
AMで |
ビュー・オブジェクトのパフォーマンスは、ビュー・オブジェクトによるデータ・フェッチがどのように構成されているかによって大きく変わります。フェッチ・オプションがアプリケーションに対して正しくチューニングされていないと、ビュー・オブジェクトが必要以上のデータをフェッチしたり、データベースへのラウンドトリップの回数が多くなりすぎたりする可能性があります。フェッチ・オプションは、図9-1に示した「ビュー・オブジェクト」ダイアログの「データベースから取得」グループ・ボックスで構成できます。
フェッチ・オプション | 説明 |
---|---|
|
デフォルトのフェッチ・オプションは「すべての行」オプションです。この場合、必要に応じて取得( |
|
「次の単位で」フィールドは、フェッチ・モード・オプションとともに、データベースから同時にフェッチされるレコードの数を制御します(ビュー・オブジェクトのXMLの DVTオブジェクトについては、フェッチ・サイズをn+1に設定してください。nは、 |
|
ビュー・オブジェクトのデフォルト最大フェッチ・サイズは-1です。つまり、ビュー・オブジェクトがフェッチできる行の数に制限はありません。最大フェッチ・サイズを
最大フェッチ・サイズを使用して、何百(または何千)もの行を返す非選択的な問合せが与える影響を抑えることもできます。その場合は、最大フェッチ・サイズを指定することで、フェッチしてメモリーに格納することのできる行の数が制限されます。 |
|
データ・セットが順方向にのみトラバースされる場合は、順方向専用モードを使用すると、データ・セットを反復する際のパフォーマンスが向上します。これを構成するには、ビュー・オブジェクトに対して |
表9-6に、ビュー・オブジェクト使用時のチューニングに関するその他の考慮事項を示します。
表9-6 ビュー・オブジェクトのその他の構成
構成に関する推奨事項 | 説明 |
---|---|
大きなデータ・セットを最適化します。 |
ビュー・オブジェクトは、ユーザーが結果の特定のページにジャンプできるように、大きなデータ・セット内でページ移動するメカニズムを備えています。これを構成するには、ビュー・オブジェクトに対して |
可能であればスピルオーバー構成を無効にします。 |
JVMコンテナのメモリーが不足した場合は、データ・ソースを仮想メモリーとして使用できます。デフォルトでは、この機能は無効になっていますが、(必要な場合は) |
SQLスタイルの構成を確認します。 |
SQL92準拠の汎用データベースにSQL92の汎用SQLスタイルを使用して接続する場合は、ビュー・オブジェクトの一部のチューニング・オプションが適用されません。ビュー・オブジェクトのフェッチ・サイズは、そのようなチューニング・オプションの1つです。SQL92のSQLスタイルを使用した場合、ビュー・オブジェクトの構成にかかわらず、フェッチ・サイズはデフォルトで10行に設定されます。SQLスタイルは、データベース接続の定義時に設定されます。デフォルトでは、Oracleデータベース接続を定義する際のSQLスタイルは |
ビュー・オブジェクトの問合せにバインド変数を使用します。 |
ビュー・オブジェクトに関連付けられた問合せに、実行のたびに変わる可能性のある値が含まれる場合は、バインド変数の使用を検討してください。そうすることで、データベースへの問合せを再解析する必要がなくなります。バインド変数は、ビュー・オブジェクト定義の「問合せ」セクションでビュー・オブジェクトに追加できます。 |
ビュー・オブジェクトの問合せに問合せオプティマイザ・ヒントを使用します。 |
ビュー・オブジェクトからデータベースにヒントを渡して、関連する問合せで使用される実行計画に影響を与えることができます。オプティマイザ・ヒントは、「データベースから取得」グループ・ボックスで指定できます。 |
動的SQL生成を使用します。 |
ビュー・オブジェクトは、設計時にSQL文を定義するかわりに、実行時にSQLを動的に生成するよう構成できます。ビュー・オブジェクト・インスタンスがSQL文を動的に生成するように構成されていれば、データベースへの再問合せが不要になります。この効果は、ページ・ナビゲーションの際に、同じキー・エンティティ・オブジェクト・リストを持つすべての属性のサブセットが後続のページ・ナビゲーションで使用される場合に、特に大きくなります。必要なすべての属性のスーパーセットを有効にすると、後続の問合せを実行する必要がなくなり、パフォーマンスが向上します。 |
バッチ処理とは、操作をデータベースへ送信する際に、複数の挿入、更新および削除をまとめて処理できる機能です。この機能をエンティティ・オブジェクト(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
属性で構成します。
アプリケーション・モジュール(AM)・プーリングを使用すると、複数のユーザーが複数のアプリケーション・モジュール・インスタンスを共有できます。AMプールの構成は、予想されるアプリケーションの使用状況によって異なります。
ほとんどのAMプール・パラメータは、Oracle JDeveloperを介して設定できます。構成内容はbc4j.xcfg
に保存されますが、必要に応じて手動で編集できます。パラメータをJVMパラメータ(-D
プロパティ=
値)として指定し、システム・レベルで設定することもできます。bc4j.xcfg
の構成は、JVMの構成より優先されます。そのため、システムレベルの汎用構成をアプリケーション固有の例外でオーバーライドすることも可能です。
表9-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プールに戻された後もデータベース接続を保持します。この関連付けを維持することには、パフォーマンス上、多くの利点があります。パフォーマンスを確保するには、指定したデータベース接続の最大数より多くのAMインスタンスを構成することを検討してください。 注意: AMプールの1つをルート・プールとして使用する必要がある場合は、そのAMプール・レベルでのチューニングを検討してください。使用頻度の低いプールについては、トップレベルのアプリケーション・パラメータが使用されないように、プール・サイズをプール・レベルでチューニングすることを検討してください。 |
次のガイドラインは、AMおよびAMプールの動作をチューニングする際の一般的な出発点として使用してください。メモリー使用率またはCPU使用率の具体的なチューニングについては、アプリケーション・モジュール・プール・サイズの構成を参照してください。
表9-8 AMプールのチューニング・パラメータ
パラメータ | 説明 |
---|---|
初期プール・サイズ
|
プールの初期化時に作成するアプリケーション・モジュール・インスタンスの数を指定します(デフォルトはゼロです)。初期プール・サイズをゼロ以外に設定すると、アプリケーションの初期化にかかる時間が増えますが、その後、AMインスタンスを必要とする操作のパフォーマンスは向上します。 この値は、すべてのユーザーへのサービス提供に必要な同時AMインスタンスの予想数より10%多くなるように構成してください。 |
最大プール・サイズ
|
プールで割り当てることのできるアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは |
最小使用可能サイズ
|
サーバーの負荷が軽い場合に、リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なアプリケーション・モジュール・インスタンスの最小数。 リソースのクリーンアップ後にすべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、 デフォルト値は、 アプリケーション・モジュール・プール・チューニングは、 |
最大使用可能サイズ
|
サーバーに負荷がかかっている場合に利用できるプール内のアプリケーション・モジュール・インスタンスの理想的な最大数。 プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。 デフォルト値は、 アプリケーション・モジュール・プール・チューニングは、 |
参照プール・サイズ
|
管理状態モードでプールに解放される前に、自身を最後に使用したセッションが次に行うリクエストに備えてセッション・アフィニティを保持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは このパラメータ値は常に、「最大プール・サイズ」の値以下である必要があります。そうすれば、設定された数の使用可能インスタンスが、管理状態モードで自身を解放した直近のセッションとのアフィニティに従うようになります。 短い思考時間で複数の操作を行う同時ユーザー数の予想値に構成します。短い思考時間でアプリケーションを使用する予定のユーザーがいない場合は、この値を0(ゼロ)に設定して、アフィニティを解消してもかまいません。 |
インスタンスの最大有効時間
|
この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内の接続モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。 デフォルト値は |
アイドル・インスタンス・タイムアウト
|
この時間(ミリ秒)を超えると、プール内の非アクティブなアプリケーション・モジュール・インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。 デフォルト値は、 |
プール・ポーリング間隔
|
プール・リソース・クリーンアップの時間間隔(ミリ秒)。 プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。 アプリケーション・モジュール・プール・モニターは、デフォルトでは |
フェイルオーバー
|
フェイルオーバーを無効にするか有効にするかを指定します。デフォルトでは、フェイルオーバーは無効になっています。フェイルオーバーを有効にするには、このパラメータを 注意: アプリケーション・モジュール状態の受動化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。このタイプの障害によって、SQLException (Connection has already been closed)が生成されます。この例外は、サーバー・ログに保存されます。例外は、ユーザー・インタフェースを通してレポートされません。 状態の受動化が発生し、変更が保存されるようにするには、 デプロイメント・ディスクリプタ・パラメータを数分に設定すると、ほとんどの場合、非アクティブな接続のタイムアウトは強制されず、その結果受動化は失敗します。ご使用の環境に合せて、この設定値を調整してください。 |
ロック・モード
|
ロック・モード( |
データベース接続プーリング
|
AMインスタンスがAMプールに戻されたときに、そのAMインスタンスをデータベース接続から切断できるかどうかを指定します。これにより、アプリケーションのAMプールをデータベース接続プールより大きなサイズに設定することができます。デフォルトは |
トランザクション切断レベル
|
|
システムのメモリーに制約がある場合に構成可能なパラメータについては、表9-9を参照してください。
表9-9 AMプール・サイズの構成 - メモリーに関する考慮事項
パラメータ | 説明 |
---|---|
初期プール・サイズ
|
追加のAMインスタンスが必要な場合は、これを小さい値に設定するとメモリーを節約できますが、パフォーマンスの低下というコストが発生します。デフォルト値の0(ゼロ)の場合、AMプールの初期化時にAMインスタンスが作成されません。 |
最大プール・サイズ
|
これを構成すると、AMインスタンスの数が指定の値を超えるのを防止できます。ただし、設定した値が小さすぎると、使用可能なAMインスタンスがない場合に、アプリケーションへのアクセス・エラーが発生することがあります。 |
最小使用可能プール・サイズ
|
ゼロ(0)に設定すると、リソース・クリーンアップ後、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
最大使用可能プール・サイズ
|
これを構成すると、リソース・クリーンアップ後に指定した最大数の使用可能インスタンスを残すことができます。 |
構成するとCPUの負荷をある程度軽減できるパラメータについては、表9-10を参照してください。
表9-10 AMプール・サイズの構成 - CPUに関する考慮事項
パラメータ | 説明 |
---|---|
|
この値は、アプリケーション・プールの初期のAMインスタンス数に設定します。初期化時にAMインスタンスを作成する場合、追加のAMインスタンスが必要になったときにオンデマンドで作成するのではなく、初期化時に作成するためのCPU処理コストがかかります。 |
|
ユーザーのセッションに対するAMインスタンスのアフィニティを維持するには、この値を設定します。このアフィニティを可能なかぎり維持することで、あるユーザーから別のユーザーへAMインスタンスを切り替える際に必要なCPU処理コストを削減できます。 |
アプリケーション・モジュール・プール・サイズの構成は、予想される同時ユーザーの数に大きく依存します。パフォーマンスの問題を防ぐには、AMプール・サイズがすべての同時ユーザーにサービスを提供するために十分であるかを確認する必要があります。
注意:
次の例では、同時ユーザーを少なくとも100人と仮定しています。必ず各自のユースケース・シナリオを検討して、デプロイメントに適した設定を決定してください。
これらのパラメータを構成するには、WebLogic ServerインスタンスのsetDomainEnv.sh
ファイルを開き、次の行を見つけます。
JAVA_OPTIONS="${JAVA_OPTIONS}" export JAVA_OPTIONS
これらの行を、次の行に置き換えます。
JAVA_OPTIONS="-Djbo.ampool.doampooling=true -Djbo.ampool.minavailablesize=1 -Djbo.ampool.maxavailablesize=120 -Djbo.recyclethreshold=60 -Djbo.ampool.timetolive=-1 -Djbo.load.components.lazily=true -Djbo.doconnectionpooling=true -Djbo.txn.disconnect_level=1 -Djbo.connectfailover=false -Djbo.max.cursors=5 -Doracle.jdbc.implicitStatementCacheSize=5 -Doracle.jdbc.maxCachedBufferSize=19 ${JAVA_OPTIONS}"
注意:
パフォーマンスの影響を制限するには、ampool.maxavailablesize
を各自のユースケース・シナリオで予想される同時ユーザーの最大数よりも少なくとも20%多い値に設定します。
次のパラメータは、AMプールのリソース・クリーンアップの頻度および特性に影響を与えます。
システムのメモリーに制約がある場合は、より多くのAMインスタンスをより頻繁にクリーンアップするようAMプールを構成します。そうすることで、AMインスタンスによって消費されるメモリーを解放して、他の目的で使用できるようになります。ただし、使用可能なAMインスタンスの数を減らしてクリーンアップの頻度を高めると、CPU使用率が上昇し、レスポンス時間も長くなる可能性があります。詳細は、表9-11を参照してください。
表9-11 AMプールのリソース・クリーンアップの構成 - メモリーに関する考慮事項
パラメータ | 説明 |
---|---|
|
ゼロ(0)に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
一般に、値を小さくすると、クリーンアップ時にプールから削除されるAMインスタンスが増加します。 |
|
値を小さくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が短くなります。 |
|
値を小さくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが増加します。 |
|
これは、リソース・クリーンアップがトリガーされる頻度を制御します。間隔を短く設定すると、メモリーの節約のために非アクティブのAMインスタンスが削除される頻度が高まります。 |
AMプールを構成して、より多くのAMインスタンスがより長い期間プール内に存在できるようにすることで、CPU処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。
表9-12 AMプールのリソース・クリーンアップの構成 - CPUに関する考慮事項
パラメータ | 説明 |
---|---|
|
これらを大きな値に設定すると、プール内に残されるアイドル・インスタンスが増えるため、後でAMインスタンスを再作成する必要がなくなります。ただし、過度に大きな値を設定して、最大負荷時に必要な数より多くのAMインスタンスを保持することは避けてください。 |
|
値を大きくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が長くなります。 |
|
値を大きくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが減少します。 |
|
間隔を長くすると、リソース・クリーンアップの頻度が低くなります。 |
アプリケーション・モジュールの粒度の設計は、パフォーマンスおよびスケーラビリティに大きな影響を与える重要な考慮事項です。各ルート・アプリケーション・モジュールは通常、専用のデータベース接続を保持していることに注意してください。ユーザー・セッションが複数のルート・アプリケーション・モジュールを消費する場合、そのユーザー・セッションは同時に複数のデータベース接続を保持している可能性があります。このような状況は、アプリケーション・モジュールとユーザー・セッションの間で全般的なアフィニティが維持されるために、接続が実際には使用されていない場合でも発生します。ユーザーが同時に複数の接続を保持する可能性を減らすには、次の方法を検討します。
ユーザーが必要とする機能をすべて網羅した大きなアプリケーション・モジュールを設計します。
小さなアプリケーション・モジュールを単一のルート・アプリケーション・モジュールの下にネストし、ネストされたアプリケーション・モジュールの間で同じデータベース接続を共有できるようにします。
アプリケーション・モジュールで遅延ロードを使用します。アプリケーション・モジュールのチューニング・セクションで、遅延ロードを使用するように実行時のインスタンス化動作をカスタマイズします。遅延ロードは、次のJVM引数を追加して、JVM全体で設定することもできます。
-Djbo.load.components.lazily=true
ページにリージョンを追加すると、アプリケーションが大きく強化されます。JSFページにレンダリングできるリモート・リージョンの数に制限はありませんが、この機能は慎重に使用する必要があります。タブが使用されていない単純なページの場合、リージョンをページにまとめ、リージョンの設計やそれが実行するビュー・オブジェクト問合せによってリージョンの最大数が決定されるようにできます。または、タブを使用する複雑なページの場合、パフォーマンスを最大化するためにリージョンの使用を制限します。複雑なタブ付きページの場合、ADFでは、リージョンがロードされた後は、タスク・フロー・トランザクションを非アクティブ化しません。タブを切り替える場合は、パフォーマンスを最大化するために進行中のトランザクションを停止する必要があります。
デフォルトでは、ページがロードされると、最初はレンダリングされなくても、タスク・フローはアクティブ化されます。このため、タスク・フローがまったく表示されない場合、不要なオーバーヘッドが発生します。
注意:
リージョンとタスク・フローの場合、現在のviewIdを評価するためにかかる時間とフローへの入力パラメータを計算するためにかかる時間が、全体のパフォーマンスに影響することがあります。設計フェーズではこれを検討してください。
デフォルトでは、ポップアップにアクセスしなくても、ポップアップの下に子コンポーネントが作成されます。このオーバーヘッドを回避するには、次のことを検討してください。
childCreation
をdeferred
に設定
ポップアップに対するchildCreation="deferred"
の設定
タスク・フローに対するactivation="deferred"
の設定
注意:
この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。
f:attribute
af:setPropertyListener
af:clientListener
af:serverListener
また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"
を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。その場合は、条件付きアクティブ化を使用します。
条件付きアクティブ化の使用
jsff内のポップアップでプロパティ・リスナーを追加して条件を設定します。
タスク・フローに対するactivation="conditional"
の設定
タスク・フローに対するactivate=
condition
の設定
デフォルトでは、スイッチャの下のタスク・フローは、スイッチャ・ファセットが表示されるときではなく、ページがロードされるとアクティブ化されます。これを回避するには、条件付きアクティブ化を使用し、ファセットが表示されるとtrue
を戻す式言語(EL)式にactive
を設定します。
アプリケーション全体で再利用可能な静的データがアプリケーションに含まれている場合、共有アプリケーション・モジュールを使用してキャッシュ・データを収集できます。共有アプリケーション・モジュールの作成と使用の詳細は、Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発で、共有アプリケーション・モジュール・ビュー・インスタンスに関する項を参照してください。