| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース1 (11.1.1.9.0) B61006-12 |
|
 前 |
 次 |
この章では、Oracle Application Development Framework (ADF)のパフォーマンスおよびスケーラビリティを最大化する方法についての基本的なガイドラインを示します。次の各項で、設計時、構成時およびデプロイメント時のパフォーマンスに関する考慮事項を取り上げます。
この章では、読者がADFアプリケーションの構築に精通しているものと想定しています。ADFについては、次のマニュアルを参照してください。
Oracle Application Development Framework開発者ガイド
Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド
Oracle Application Development Framework (Oracle ADF)は、Java Platform, Enterprise Edition (Java EE)標準およびオープンソース・テクノロジをベースとするエンドツーエンドのアプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、Webサービスなどのインタフェースを使用してデータを検索、表示、作成、変更、検証するアプリケーションの構築を目指す企業内開発者に最適です。
詳細は、Oracle Application Development Framework開発者ガイドの「Oracle ADFの概要」を参照してください。
ADFアプリケーションの構築、構成およびデプロイを行う前に、最適なパフォーマンスが得られるよう、チューニングに関する次の推奨事項に目を通してください。
この項では、ADF Facesの構成およびプロファイリングの概念について説明します。Oracle ADF Facesの構成オプションは、web.xmlファイルに設定されています。ほとんどのパラメータにはデフォルト値があります。パフォーマンスのためにそれらのデフォルト値をチューニングすることができます。表8-1に、これらの構成オプションの一部を示します。
表8-1 web.xmlのADF Faces構成オプション
| 構成に関する推奨事項 | 説明 |
|---|---|
|
|
パラメータ |
|
|
パラメータ |
|
トークンのみを保存するには、 |
パラメータ |
|
クライアント側のログ・レベルをオフに設定します。 |
パラメータ |
|
クライアント側のプロセス・アサーションが無効になっていることを確認してくだい。 |
|
|
ページでインラインJavaScriptの使用を避けます。 |
インラインJavaScriptは、レスポンス・ペイロード・サイズを増加させる可能性があり、ブラウザにまったくキャッシュされないため、ブラウザのレンダリングをブロックすることがあります。インラインJavaScriptを使用するかわりに、すべてのスクリプトをJavaScriptライブラリ内の.jsファイルに入れることを検討し、スクリプトをaf:resourceタグを使用してページに追加してください。 注意: 可能であれば、trh:scriptではなくaf:resourceを使用することを検討してください。 |
|
自己署名SSL証明書を避けます。かわりに、公式に署名されたセキュリティ証明書を選択します。 |
ブラウザには、自己署名SSL証明書を利用するとリソースのキャッシングを妨げるものがあります。JavaScriptライブラリ、イメージ、スタイルシートなどのリソースは、ユーザーがアプリケーションにアクセスするたびにリロードが必要となり、ネットワークのパフォーマンスに影響を与える可能性があります。 公式に署名されたSSL証明書を使用すると、自己署名証明書よりも充実したセキュリティ保証を受けられる利点が加わります。 |
|
JSPタイムアウト・パラメータを構成します。 |
JavaServer Pages (JSP)タイムアウト・パラメータを使用すると、web.xmlの次の設定によって使用頻度の低いページがキャッシュからフラッシュされます。
<servlet>
<servlet-name>
oraclejsp
<init-param>
<param-name>
jsp_timeout
</param-name>
<param-value>
600
</param-value>
</init-param>
</servlet-name>
</servlet>
注意: このパラメータは各自のユースケース・シナリオに基づいて設定してください。 |
|
ドロップダウン・ポップアップを使用して単一のツールバー項目を作成します。 |
画面解像度のためにブラウザ・サイズが小さい場合、Internet Explorer 7および8ではメニューバーまたはツールバーのオーバーフロー・ロジックが高コストになります。特に、コマンド・アイテムを含むDOM構造のレイアウトに問題があります。 ドロップダウン・ポップアップを使用して単一のツールバー項目を作成し、すべての入力フィールドをその中に入れます。このポップアップは、子の作成およびcontentDelivery="lazy"を延期します。 |
|
コレクションベースのコンポーネント(表など)で共有ポップアップを使用します。 |
表内で複数のポップアップがスタンプ設定されると、ページ用に生成されたHTMLのサイズを増やすことがパフォーマンスに影響を与える場合があるため、コレクションベースのコンポーネント(表など)では共有ポップアップを使用してオーバーヘッドを削減することを検討してください。 |
|
ナビゲーション・リンクでホバー・ポップアップを使用しないでください。 |
ナビゲーション・リンクでホバー・ポップアップを使用すると、ナビゲーションはホバーが最初にフェッチされるのを待機します。 表内のナビゲーション・リンクのホバー・ポップアップを、表セル内の別のアイコンに移動します。 |
|
部分ページ・ナビゲーションを使用します。 |
部分ページ・ナビゲーションはADF Facesフレームワークの機能です。これを使用すると、ブラウザであるADF Facesページから別のADF Facesページへ移動する際に、ページ全体の遷移が不要になります。新しいページは、部分ページ・レンダリング(PPR)/Ajaxチャネルを使用してクライアントに送信されます。 従来のページ全体のナビゲーションと比較した部分ページ・ナビゲーションの主な利点は、パフォーマンスの向上です。ブラウザがJavaScriptライブラリを再度解釈して実行する必要はなく、ページ全体のクリーンアップ/初期化に時間を費やすこともありません。このような最適化から得られるパフォーマンス上の利点は非常に大きいため、部分ページ・ナビゲーションは可能なかぎり有効にしてください。 この機能には次のような既知の制限があります。
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の部分ページ・ナビゲーションの使用に関する項を参照してください。 |
|
ページ・テンプレートを使用します。 |
ページ・テンプレートとは、開発者がデータ・バインドされた再利用可能なテンプレートを作成して、これを任意のページのシェルとして使用できる機能です。開発者は、Webページを作成する他の開発者に構成を伝えて一貫性を確保するためのテンプレートを1つ以上作成できます。テンプレートには、使用時に変更できない静的領域と、開発者が作成中のページ固有のコンテンツを配置できる動的領域があります。 テンプレートを使用する際の重要な考慮事項を次に示します。
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のページ・テンプレートの使用に関する項を参照してください。 |
|
ADF Facesのジオメトリ管理を有効にします。 |
ADF Rich Clientは、親コンポーネントが明示的にUIに含められているブラウザ・レイアウトのジオメトリ管理をサポートしています。子コンポーネントは、ブラウザの使用可能領域一杯まで広がるようサイズ設定されます。この機能を使用するとUIの見栄えはよくなりますが、コストが発生します。影響が出るのはクライアント側です。これは、ブラウザがコンポーネントのサイズを変更するのに時間がかかるためです。デフォルトでジオメトリ管理の対象となるコンポーネントは次のとおりです。
注意:
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のジオメトリ管理およびコンポーネントの拡大に関する項を参照してください。 |
|
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)によって実装されます。
ネイティブ・コンポーネント・リフレッシュはフレームワークに組み込まれていますが、クロスコンポーネント・リフレッシュは、場合によっては開発者が実装作業を行う必要があります。 クロスコンポーネント・リフレッシュは、ページ上の異なるコンポーネントが互いにセマンティックな関係を持つ概念です。たとえば、国の選択を要求するページ上でユーザーがある選択コンポーネントを選択するような場合です。この選択の結果により、ページ上の別のコンポーネントは、国の有効な状態を表示するように変更および更新される必要があります。この関係は、クロスコンポーネント・リフレッシュを必要とします。これは、宣言またはプログラムのいずれによっても実行できます。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください)。 クロスコンポーネント・リフレッシュを使用する場合は、部分ターゲットと部分トリガーの違いに注意することが必要です。部分トリガーは、コンポーネントが別のコンポーネントでの変更をリスニングする際に使用します。部分ターゲットは、変更を行うコンポーネントで、ページ上の別のコンポーネントの再レンダリングが確実に行われるようにする場合に使用します。 ページに
前述の手順により、コマンド・ボタンを使用して部分ページ・リフレッシュをトリガーするPPRが実現します。 部分ページ・レンダリングによってパフォーマンスが大幅に向上する主な理由は、ページ全体のリフレッシュが発生せず、フレームワーク・アーティファクト(ADF Rich ClientのJSライブラリやスタイルシートなど)がリロードされるかわりに、ページの小さい部分のみがリフレッシュされることです。そのため、余分なデータのフェッチやジオメトリ管理が一切行われない場合もあります。 ADF Rich Clientは、部分ページ・レンダリングを使用すればクライアント側で最適なパフォーマンスが得られることを実証しています。クライアント側での影響に加えて、サーバー側の処理が高速化され、サーバー側のスループットおよびスケーラビリティが向上します。 詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の「部分ページ・コンテンツの再レンダリング」を参照してください。 |
|
ADF Rich Clientのナビゲーションを使用します。 |
ADF Rich Clientは、ナビゲーションを幅広くサポートしています。一般的なユースケースの1つに、タブ付きナビゲーションがあります。この機能は現在、xmlMenuModelにバインドして簡単にナビゲーションを定義できるnavigationPaneなどのコンポーネントでサポートされています。 ただし、この方法にはデメリットが1つあります。ADF Rich Clientのナビゲーションでは、ユーザーがタブを切り替えるたびにページ全体のリフレッシュが発生することです。1つの選択肢として、panelTabbedをかわりに使用します。panelTabbedには、タブ付きコンテンツの部分ページ・レンダリングのサポートが組み込まれており、開発者の作業は必要ありません。しかし、panelTabbedはナビゲーションにバインドできず、コンテンツをページ内から取得できるようにする必要があるため、応用可能な範囲は限られています。 |
|
リソースをキャッシュします。 |
キャッシュ可能なリソース(イメージ、CSS、JavaScript)には、必ずキャッシュ・ヘッダーを正しく指定しておくことを強くお薦めします。また、サーバーにないリソースに対するクライアント・リクエストはサーバーへのラウンドトリップが増加する原因となります。これを防ぐには、すべてのリソースがサーバーに存在することを確認してください。 ResourceServletを使用してweb.xmlを構成し、リソース・キャッシングを有効にすることを検討してください。
<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>
|
|
状態トークン・キャッシュのサイズを小さくします。 |
web.xmlに定義されたorg.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENSプロパティにより、トークンベースのクライアント側状態保存において一度に保存するトークンの数を決定します。デフォルト値は15です。この値を超えると、表示されてから最も長い時間が経過したページの状態が失われます。「戻る」ボタンを頻繁に使用するユーザーや複数のウィンドウを同時に開くユーザーは、影響を受ける可能性があります。 セッションごとの使用中メモリーを減らすには、この値を2に減らすことを検討してください。状態トークン・キャッシュを2に減らすことは、「戻る」ボタンのクリック1回または外部ダイアログで起動された1つのタスク・フローがサポートされることを意味します。「戻る」ボタンがサポートされないアプリケーションについては、この値を1に設定してください。 注意: JSPエラーIllegalStateExceptionが発生する場合があるため、このパラメータを1に設定することは |
|
af:resourceコンポーネントを使用してcssスクリプトおよびjsスクリプトを配信します。 |
開発者が共通して行う作業の1つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読み取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスをより向上させるために、 コンポーネント(または静的なCDATAコンテンツ)をヘッダーに表示するには、metaContainerファセットを使用します。 |
|
カスタムJavaScriptコードを最適化します。 |
ADF Rich Clientは、クライアント側でJavaScriptを使用します。必要な機能のほとんどはフレームワークそのものに組み込まれています。しかし、カスタムJavaScriptコードの記述が必要になる場合もあります。最適なパフォーマンスを得るには、JavaScriptコードを1つのJS lib (1つのJavaScriptファイル)にまとめてクライアントに配布することを検討してください。最も簡単な方法は、ADFタグ< ほとんどのページでカスタムJavaScriptコードが必要になる場合は、このタグをアプリケーション・テンプレートに含めてください。それ以外の場合は、特定のページのみに含めることでパフォーマンスを改善できます。カスタムのJavaScriptコード・ライブラリ・ファイルが大きくなりすぎた場合は、そのファイルを内容に応じて分割し、ページで必要な部分のみを含めることを検討してください。全般的に、この方法では、ブラウザ・キャッシュが使用され、ページのhtmlコンテンツが小さくなるため、より高速な実行が可能になります。 |
|
デバッグ出力モードを無効にします。 |
|
|
テストの自動化を無効にします。 |
テスト自動化パラメータ パフォーマンスを改善するには、 |
|
アニメーションを無効にします。 |
ADF Rich Clientフレームワークでは、クライアント側のアニメーションがデフォルトで有効になっています。アニメーションは、高度なユーザー体験を提供する目的で使用されます。ポップアップ表など、一部のコンポーネントには、一部の操作に対応するアニメーション・セットが用意されています。アニメーションを使用するとユーザー体験を改善できますが、アクションを実行したときのレスポンス時間が長くなる可能性があります。速度が最大の懸念事項である場合は、 |
|
JavaScriptのプロファイラを無効にします。 |
JavaScriptの |
|
リソース・デバッグ・モードを無効にします。 |
リソース・デバッグ・モードを有効にすると、ブラウザ(またはWebCache)はリソース(JSライブラリ、CSSスタイルシート、イメージなど)がキャッシュ可能であることをHTTPレスポンス・ヘッダーから判断できません。 キャッシュを確実に有効にするには、 |
|
タイムスタンプのチェックを無効にします。 |
web.xmlファイルで |
|
CSSファイルの変更のチェックを無効にします。 |
|
|
コンテンツの圧縮を有効にします。 |
デフォルトでは、レンダリングされたスタイル・クラスは、ページ・サイズを小さくするために圧縮されます。本番環境では、必ず デバッグの際には、スタイル・クラスのコンテンツの圧縮をオフにします。そのためには、 |
|
JavaScriptの曖昧化を有効にします。 |
ADF Facesは、曖昧化されていないJavaScriptライブラリを提供するためのランタイム・オプションをサポートしています。デフォルトでは曖昧化されたバージョンが提供されますが、開発用に曖昧化されていないバージョンも提供されます。曖昧化を行うと、JavaScriptライブラリ全体のサイズが約50%削減されます。 曖昧化されたADF Facesビルドを提供するには、web.xmlファイルで |
|
ライブラリのパーティション化を有効にします。 |
Oracle 11g リリースでは、ライブラリのパーティション化がデフォルトでオンになっています。旧バージョンでは、ライブラリのパーティション化はデフォルトでオフになっていました。ライブラリのパーティション化がオンになっていることを確認してください。そのためには、web.xmlファイルで |
|
注意: Firefoxブラウザを使用してクライアントのレスポンス時間のプロファイリングまたは測定を行う際には、Firebugプラグインが無効になっていることを確認してください。ページの情報を取得したり、ページのJavaScriptコードをデバッグしたりする目的では、このプラグインは非常に有効ですが、総レスポンス時間に影響を与える可能性があります。Firefox Firebugプラグインの無効化の詳細は、Firefox Support Home Page ( |
表8-2に、ADF Facesコンポーネント属性の構成に関する推奨事項を示します。
表8-2 ADF Facesコンポーネント属性
| 構成に関する推奨事項 | 説明 |
|---|---|
|
panelTabbedコンポーネントで |
デフォルトでは、panelTabbed内のshowDetailItemsの子コンポーネントは、それらが公開されない場合でも作成されます。これにより、不要なメモリーおよびCPUが消費される場合があります。 showDetailItemsの子のコンテンツが作成されるタイミングを制御するには、
|
|
ADF Rich Clientコンポーネントとともに、 |
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が長いとパフォーマンスに影響が出ます。 |
|
|
注意: この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。
また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。 |
|
|
このシナリオでは、次の手順を実行します。
|
table、treeおよびtreeTableは、最も複雑で使用頻度の高いコンポーネントです。これらのコンポーネントは大きなデータ・セットを格納できるため、よくパフォーマンスの問題の原因となります。表8-3に、パフォーマンスに関する推奨事項を示します。
表8-3 tableコンポーネントおよびtreeコンポーネントの構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
editingMode="clickToEdit"を使用します。 |
editingMode="editAll"を使用すると、編集可能な値ホルダーの全コンテンツとその子コンポーネントが送信されます。これにより、クライアントのHTTPペイロードおよびDocument Object Model (DOM)コンテンツは大幅に増加します。 editingMode="clickToEdit"に切り替えて送信されるデータ量を削減し、ユーザーとのやり取りを向上させることを検討してください。 |
|
|
デフォルトでは、表コンポーネントは、「既知の行カウント」モードでレンダリングされます。つまり、合計行数に応じてスクロールバーのサイズが変わります。このモードでは、リッチUIが提供されますが、合計行数を取得するために、ADF表レンダリングのための ADF-Business Components (BC)が使用されている場合は、 他には、 |
|
可能であれば、fetchSizeを減らします。 |
af:tableのfetch size属性が大きいほど、処理、サーバーからのフェッチおよびクライアントでの表示が必要なデータが多いことを示します。これは、クライアントで表示されるDOMの量を増やす可能性もあります。 |
|
表のフェッチ・サイズを変更します。 |
表には、1回のラウンドトリップでクライアントに送信される行数を定義したフェッチ・サイズがあります。最適なパフォーマンスを得るには、この数を最低限に抑えます。ただし、表ビューの初期ポートを実行するのに十分な行を確保してください。そうすることで、最適なパフォーマンスを得ながら余分なサーバー・リクエストを排除できます。 また、表のフェッチ・サイズとイテレータの範囲サイズを合せることを検討してください。デフォルトでは、表のフェッチ・サイズはEL式 詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表およびツリーの使用に関する項を参照してください。 |
|
列の拡大を無効にします。 |
tableコンポーネントおよびtreeTableコンポーネントの列は、最後の列の端とtableコンポーネントまたはtreeTableコンポーネントの輪郭との間に未使用の領域が残らないよう、拡大することができます。この機能は、パフォーマンスに影響を与える可能性があるため、デフォルトでオフになっています。この機能をオンにすると、クライアントのレンダリング時間に影響が出ることがあります。したがって、この機能を複雑な表に対して有効にするときは十分に注意してください。 |
|
ヘッダー行および固定列は、必要な場合にのみ使用するようにしてください。 |
tableコンポーネントには、行ヘッダーおよび固定列を設定できる機能があります。これらのオプションを使用すると、優れたデザインのインタフェースを作成でき、ユーザー体験も向上します。ただし、クライアント側のパフォーマンスに影響が出る可能性があります。tableコンポーネントで最適なパフォーマンスを得るには、これらのオプションを必要な場合にのみ使用します。 |
|
ユーザーが表示できないポップアップを無効にします。 |
ある特定の時点で適切でないポップアップは、 |
table、tree、その他のスタンプ設定されたコンポーネントのデータは、遅延配信または即時配信が可能です。次の表では、あるオプションが他のオプションよりも優れたパフォーマンスを実現するチューニング・シナリオを示します。多くの場合、何がチューニングされるかを考慮して、使用するオプションを決定する必要があります。
デフォルトでは、遅延配信が使用されます。つまり、サーバーからの最初のレスポンスではデータは配信されません。初期ページがレンダリングされた後、クライアントがサーバーにデータを要求し、2番目のリクエストへのレスポンスとしてデータを取得します。
即時配信の場合は、ページ・リクエストへのレスポンスと同時にデータを取得できます。データ配信が行われるのはコンポーネントごとであり、ページごとではないので注意してください。つまり、この2つを同じページ上に混在させることが可能です。
この2つのオプションから選択する際には、次の点を考慮してください。
| 遅延配信(デフォルト) | 遅延配信は、表やフェッチ時間の遅いスタンプ設定された他のコンポーネントに使用する必要があります。たとえば、スタンプ設定されたコンポーネントがWebサービス呼出しを使用したデータ・コントロールや遅いデータ・フェッチの他のデータ・コントロールに基づく場合です。ユーザーが下にスクロールしないとすぐに内容が表示されないページにも遅延配信を使用できます。この場合、クライアントに表示されるコンテキストの配信時間が短くなり、ユーザーがパフォーマンスの向上を認識します。
遅延配信は、データ・ストリーミング技術を使用して実現されます。この方式が優れているのは、サーバーがデータ・フェッチを並行して実行し、データが使用可能になると同時に、そのデータをクライアントへストリーミング配信することが可能な点です。この方式は、ページに表が2つあり、一方の表ではデータがごく短時間で返され、もう一方の表ではデータが返されるまで長時間かかるといった場合に、高い効果を発揮します。高速な表のデータは、取得されると同時にユーザーに対して表示されます。 注意: 遅延配信を使用する際は、データが利用可能であるかどうかを最初に判断するためにwhenAvailableの使用を検討してください。利用可能でない場合はレンダリングします。 また、並行してデータ・フェッチを実行すると、データ・フェッチの合計時間が短縮されます。これは、複数の遅くなる可能性のあるデータ・フェッチの遅延ロードに利点があります。ストリーミングは遅延モードのデータ配信のデフォルト・メカニズムですが、データ・コントロールのパラレル実行はそうではありません。パラレル実行を有効にするには、ページ定義を開いて、イテレータの 場合によっては、パラレル実行のレスポンス時間が短縮される利点があります。パラレル実行では並行してリクエストを実行する複数のスレッドのために多くのリソースを使用する可能性があり、開くデータベース接続が多くなる場合があります。 ページに複数の遅いコンポーネントが存在し、スタンプ設定されたコンポーネントが異なるデータ・コントロール・フレーム(分離したタスクフローなど)に属する場合のみ、パラレル実行を使用することを検討してください。パラレル実行がデータ・コントロール・フレーム・レベルで同期化するため、単一のデータ・コントロール・フレームのパラレル実行ではパフォーマンスが改善しない場合があります。 |
| 即時配信 | 即時配信(contentDelivery="immediate")を使用するのは、表データ・コントロールが高速な場合、または小さいデータ・セットを返す場合です。このような場合には、遅延配信を使用するよりレスポンス時間が短くなります。
即時配信のもう1つの利点は、遅延配信に比べてサーバー・リソースの使用率が低いことです。即時配信では、サーバーに送信されるリクエストは1つのみなので、特定のユーザー・インタラクションにおけるCPUおよびメモリーの使用率が低下します。 |
autoSuggestは、inputText、inputListOfValues、inputComboboxListOfValuesの各コンポーネントに対して有効にできる機能です。ユーザーが入力フィールドに文字を入力すると、コンポーネントは候補となる項目のリストを表示します。この機能により、データベース表で問合せが実行され、結果がフィルタ処理されます。データベース処理を高速化するために、autoSuggestが有効になっている列にデータベース索引を作成してください。そうすることで、特にデータベース表の行数が多い場合に、コンポーネントのレスポンス時間が改善されます。
|
注意: 多数のautoSuggest項目が返されることを避けるために、autoSuggestBehaviorのmaxSuggestedItemsプロパティを使用する(使用状況に応じた値を設定する)ことを検討してください。 |
データ視覚化ツール(DVT)コンポーネントは、ADF Rich Clientコンポーネントをベースとして構築されています。DVTコンポーネントには、グラフ、ゲージ、ガント・チャート、ピボット・テーブル、マップなどがあります。表8-4に、DVTコンポーネントの構成に関する推奨事項を示します。
表8-4 DVTコンポーネントの構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
RangeSize属性を使用します。 |
RangeSize属性は、同時に返す行の数を定義します。RangeSizeに値-1を指定すると、イテレータはすべての行を返します。より小さい値を使用することでパフォーマンスが向上する可能性がありますが、データ管理が複雑化する場合があります。また、rangeSizeの範囲外にあるデータがビューに表示されなくなります。 |
|
縦方向のテキストではなく横方向のテキストを使用します。 |
デフォルトでは、ピボット・テーブルの列ヘッダーとして横方向のテキストが使用されます。ただし、縦方向のテキストを使用するオプションもあります。縦方向のテキストを使用するには、ヘッダー・フォーマットとして次のようなCSSスタイルを指定します。
縦方向のテキストの方が見栄えがよいこともありますが、Firefoxブラウザを使用する場合はパフォーマンスに影響が出ます。 問題なのは、FirefoxがInternet Explorerのように縦方向のテキストに対応していないことです。縦方向のテキストを表示するために、ピボット・テーブルではGaugeServletによって生成されたイメージが使用されます。テキストは動的で、バインディング値に依存しているので、このイメージをキャッシュすることはできません。そのため、ピボット・テーブルをレンダリングするたびに、イメージをフェッチする目的でサーバーへの余分なラウンドトリップが発生し、ネットワーク・トラフィック、サーバーのメモリーおよびCPUに影響を与えます。 最適なパフォーマンスを得るには、縦方向のテキストではなく横方向のテキストを使用することを検討してください。 |
|
動的サイズ変更の使用を避けます。 |
DVTグラフおよびゲージの 追加のフェッチがパフォーマンスに影響を与える可能性があります。可能であれば、コンポーネントで動的サイズ変更プロパティを設定して、動的サイズ変更の使用を避け、正しい領域サイズを明示的に設定します。 |
|
デフォルトのイメージ形式として、Flashではなく、HTML5を使用します。 |
Oracle Fusion Middleware 11gリリース1 (11.1.1.7.0)では、グラフおよびゲージはHTML5出力形式をサポートしています。新しいweb.xmlコンテキスト・パラメータが導入され、デフォルトの出力形式をHTML5に変更できるようになりました。コンテキスト・パラメータ アプリケーションにこのコンテキスト・パラメータがあるものの、イメージ形式が指定されていない場合、デフォルトでHTML5に自動で設定されます。有効な値は、HTML5およびFLASHです。このコンテキスト・パラメータがないアプリケーションの場合、グラフおよびゲージのデフォルト・レンダリングはFlashになります。 最適なパフォーマンスを保つために、すべての最新ブラウザでHTML5を使用してください。 |
前の項で推奨されているチューニングの変更を行った後、ADFサーバー・デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
Oracle ADFサーバー・コンポーネントは、ADF内のUI以外のコンポーネントからなります。これには、モデル・レイヤーのADF実装(ADFm)、ビジネス・サービス・レイヤーのADF実装(ADFbc)、およびコントローラ・レイヤーのADF実装(ADFc)が含まれます。サーバー・コンポーネントは自由に構成できますが、重要なのは、指定したアプリケーション・パフォーマンスおよび機能を備える使用可能リソースに最適な構成の組合せを選択することです。
重要なユーザー・コミュニティを持つADFアプリケーションの場合、デフォルトのHTTPセッション・タイムアウトの45分を使用すると、期限切れを待機しているセッションによって保持されるメモリー量がパフォーマンスに悪影響を与えることがあります。保持されるメモリーは物理的に使用可能な量より大きくなる可能性があり、サーバーは負荷を処理できなくなります。公開Webサイトを使用しているユーザーなど、ユーザー数が多い場合は、セッション・タイムアウトをできるだけ短くする必要があります。
パフォーマンスを向上させるには、web.xmlファイルでセッション・タイムアウトのデフォルト値(分単位)を変更することを検討してください。ユースケース・シナリオで機能するセッション・タイムアウト値を使用します。次の例は、10分のセッション・タイムアウトを示しています。
<session-config> <session-timeout> 10 </session-timeout> </session-config>
ビュー・オブジェクト(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を使用して、ビュー・オブジェクトを実行時に作成できます。ただし、パフォーマンスに影響が出る可能性があり、チューニングも複雑になるため、実行時に作成されるビュー・オブジェクトを使用するのは絶対に必要でないかぎり避けてください。 |
ビュー・オブジェクトのパフォーマンスは、ビュー・オブジェクトによるデータ・フェッチがどのように構成されているかによって大きく変わります。フェッチ・オプションがアプリケーションに対して正しくチューニングされていないと、ビュー・オブジェクトが必要以上のデータをフェッチしたり、データベースへのラウンドトリップの回数が多くなりすぎたりする可能性があります。フェッチ・オプションは、図8-1に示した「ビュー・オブジェクト」ダイアログの「データベースから取得」グループ・ボックスで構成できます。
| フェッチ・オプション | 説明 |
|---|---|
| フェッチ・モード | デフォルトのフェッチ・オプションは「すべての行」オプションです。この場合、必要に応じて取得(FetchMode="FETCH_AS_NEEDED")するか、一度にすべて取得(FetchMode="FETCH_ALL")するか、適切な方のオプションを選択します。ETCH_AS_NEEDEDオプションを指定すると、ビュー・オブジェクトに対するexecuteQuery()操作によって、表示される最初のページに必要な数の行のみがまず取得されます。行数は、ビュー・オブジェクトの範囲サイズに基づいて設定されます。
注意: 必要のないかぎり、 |
| フェッチ・サイズ | 「次の単位で」フィールドは、フェッチ・モード・オプションとともに、データベースから同時にフェッチされるレコードの数を制御します(ビュー・オブジェクトのXMLのFetchSize)。デフォルト値は1ですが、この値では、1行のみフェッチされる場合を除き、パフォーマンスに影響を与える可能性があります。推奨構成として、この値をn+1に設定することをお薦めします。nはユーザー・インタフェースに表示される行数です。
同じビュー・オブジェクトが複数の画面で使用されているケースで、それぞれに異なるレコードの数が表示されている場合、ビュー・オブジェクトの複数の使用方法をAMで定義することを検討してください。それぞれの使用方法設定で、適切なフェッチ・サイズを定義し、ビュー・オブジェクトがそれを使用するUIと適合するようにします。 DVTオブジェクトについては、フェッチ・サイズをn+1に設定してください。nは、rangeSizeか、rangeSizeが-1の場合は予想される最大行セット・サイズです。 |
| 最大フェッチ・サイズ | ビュー・オブジェクトのデフォルト最大フェッチ・サイズは-1です。つまり、ビュー・オブジェクトがフェッチできる行の数に制限はありません。最大フェッチ・サイズを0(ゼロ)に設定すると、ビュー・オブジェクトは挿入専用になります。結果セットにn行のデータのみを含める場合は、「行番号までのみ」オプションを選択して設定するか、setMaxFetchSize(N)をコールしてこれをプログラム的に設定します。この設定を手動で行うには、パラメータMaxFetchSizeをビュー・オブジェクトのXMLに追加します。
ビュー・オブジェクトのWHERE句に単一行を取得することを指定するには、「最大で1行」オプションを設定します。このオプションを設定すると、ビュー・オブジェクトは行がそれ以上返されないことを認識し、その状況における通常のテストを省略します。この場合、SELECT問合せは発行されず、行はフェッチされません。 最大フェッチ・サイズを使用して、何百(または何千)もの行を返す非選択的な問合せが与える影響を抑えることもできます。その場合は、最大フェッチ・サイズを指定することで、フェッチしてメモリーに格納することのできる行の数が制限されます。 |
| 順方向専用モード | データ・セットが順方向にのみトラバースされる場合は、順方向専用モードを使用すると、データ・セットを反復する際のパフォーマンスが向上します。これを構成するには、ビュー・オブジェクトに対してsetForwardOnly(true)をプログラム的にコールします。順方向専用に設定すれば、データ・セットのトラバースの際に前の行セットがキャッシュされるのを防ぐこともできます。 |
表8-5に、ビュー・オブジェクト使用時のチューニングに関するその他の考慮事項を示します。
表8-5 ビュー・オブジェクトのその他の構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
大きなデータ・セットを最適化します。 |
大きなデータ・セットがある場合、データを1回に1ページずつスクロールしたくない場合もあります。範囲ページングは、大きなデータ・セット内でページ移動できるようにすることで、ユーザーが結果の特定のページにジャンプできるようになります。 これを構成するには、ビュー・オブジェクトに対して 範囲ページングでは、現在のページの行のみがフェッチされて、ビュー・オブジェクトの行キャッシュに入れられるため、1ページのデータを取得するたびに問合せ実行のコストがかかります。範囲ページングは、すべての行をフェッチしてビュー・オブジェクトの行キャッシュに入れる方が有利な場合には適していません(たとえば、データ・セットのすべての行を読み取ってLOVを生成したり、小さいデータ・セットのレコードを前後にページ移動したりする必要がある場合です)。 範囲ページングの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の範囲ページングを使用して大きい結果セットを効率的にスクロールする方法に関する項を参照してください。 |
|
|
パフォーマンスへの影響を防ぐには、 |
|
可能であればスピルオーバー構成を無効にします。 |
JVMコンテナのメモリーが不足した場合は、データ・ソースを仮想メモリーとして使用できます。デフォルトでは、この機能は無効になっていますが、(必要な場合は) |
|
SQLスタイルの構成を確認します。 |
SQL92準拠の汎用データベースにSQL92の汎用SQLスタイルを使用して接続する場合は、ビュー・オブジェクトの一部のチューニング・オプションが適用されません。ビュー・オブジェクトのフェッチ・サイズは、そのようなチューニング・オプションの1つです。SQL92のSQLスタイルを使用した場合、ビュー・オブジェクトの構成にかかわらず、フェッチ・サイズはデフォルトで10行に設定されます。SQLスタイルは、データベース接続の定義時に設定されます。デフォルトでは、Oracleデータベース接続を定義する際のSQLスタイルは |
|
ビュー・オブジェクトの問合せにバインド変数を使用します。 |
ビュー・オブジェクトに関連付けられた問合せに、実行のたびに変わる可能性のある値が含まれる場合は、バインド変数の使用を検討してください。そうすることで、データベースへの問合せを再解析する必要がなくなります。バインド変数は、ビュー・オブジェクト定義の「問合せ」セクションでビュー・オブジェクトに追加できます。 パフォーマンスを向上させるには、使用していないリスト・バインディングを削除します。 |
|
ビュー・オブジェクトの問合せに問合せオプティマイザ・ヒントを使用します。 |
ビュー・オブジェクトからデータベースにヒントを渡して、関連する問合せで使用される実行計画に影響を与えることができます。オプティマイザ・ヒントは、「データベースから取得」グループ・ボックスで指定できます。 注意: パフォーマンスの問題を回避するために、必須/選択的に必須のビュー基準アイテムでは |
|
動的SQL生成を使用します。 |
ビュー・オブジェクトは、設計時にSQL文を定義するかわりに、実行時にSQLを動的に生成するよう構成できます。ビュー・オブジェクト・インスタンスがSQL文を動的に生成するように構成されていれば、データベースへの再問合せが不要になります。この効果は、ページ・ナビゲーションの際に、同じキー・エンティティ・オブジェクト・リストを持つすべての属性のサブセットが後続のページ・ナビゲーションで使用される場合に、特に大きくなります。必要なすべての属性のスーパーセットを有効にすると、後続の問合せを実行する必要がなくなり、パフォーマンスが向上します。 |
|
一時式を受動化します。 |
パフォーマンスを保つために、一時式を受動化することを検討してください。これは、EO/VOレベルまたは個々の式レベルのフラグによって制御されます。「ビュー・オブジェクト」ダイアログ画面で、「受動化」を有効にする際に「一時的な値をすべて含む」を選択します。 |
バッチ処理とは、操作をデータベースへ送信する際に、複数の挿入、更新および削除をまとめて処理できる機能です。この機能をエンティティ・オブジェクト(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
アプリケーション・モジュール(AM)・プーリングを使用すると、複数のユーザーが複数のアプリケーション・モジュール・インスタンスを共有できます。AMプールの構成は、予想されるアプリケーションの使用状況によって異なります。
ほとんどのAMプール・パラメータは、Oracle JDeveloperを介して設定できます。構成内容はbc4j.xcfgに保存されますが、必要に応じて手動で編集できます。パラメータをJVMパラメータ(-Dプロパティ=値)として指定し、システム・レベルで設定することもできます。bc4j.xcfgの構成は、JVMの構成より優先されます。そのため、システムレベルの汎用構成をアプリケーション固有の例外でオーバーライドすることも可能です。
表8-6 アプリケーション・モジュール(AM)・プールのチューニング
| 構成に関する推奨事項 | 説明 |
|---|---|
|
遅延データ配信方法を使用します。 |
デフォルトでは、AMのインスタンスが作成されるときに、AMは関連するすべての定義をロードします。AMは、関連する多数のVOを保持できます。このことは、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の使用状況をさらに詳細にチューニングする方法は、次に記載されています。
表8-7 AMプールのチューニング・パラメータ
| パラメータ | 説明 |
|---|---|
|
初期プール・サイズ
|
プールの初期化時に作成するアプリケーション・モジュール・インスタンスの数を指定します(デフォルトはゼロです)。初期プール・サイズをゼロ以外に設定すると、アプリケーションの初期化にかかる時間が増えますが、その後、AMインスタンスを必要とする操作のパフォーマンスは向上します。 この値は、すべてのユーザーへのサービス提供に必要な同時AMインスタンスの予想数より10%多くなるように構成してください。 |
|
最大プール・サイズ
|
プールで割り当てることのできるアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは4096です)。この制限を超える数のアプリケーション・モジュール・インスタンスは作成できません。一般的なガイドラインとして、この値は、さらなる増加分を見込んで初期プール・サイズより20%大きくなるように構成してください。 |
|
最小使用可能サイズ
|
サーバーの負荷が軽い場合に、リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なアプリケーション・モジュール・インスタンスの最小数。 リソースのクリーンアップ後にすべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、0(ゼロ)を設定します。 デフォルト値は、5(インスタンス)です。 アプリケーション・モジュール・プール・チューニングは、 |
|
最大使用可能サイズ
|
サーバーに負荷がかかっている場合に利用できるプール内のアプリケーション・モジュール・インスタンスの理想的な最大数。 プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。 使用できるデフォルトの最大サイズは、25インスタンスです。リソース・クリーンアップ後に利用可能にしておきたいインスタンス数の最大数に構成します。一般に、値を低くすると、クリーンアップの際にプールから削除されるアプリケーション・モジュール・インスタンスの数が増えます。 アプリケーション・モジュール・プール・チューニングは、 |
|
参照プール・サイズ
|
管理状態モードでプールに解放される前に、自身を最後に使用したセッションが次に行うリクエストに備えてセッション・アフィニティを保持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは10です)。 参照されるプール・サイズは常に最大プール・サイズ以下になるようにしてください。そうすれば、設定された数の使用可能インスタンスが、管理状態モードで自身を解放した直近のセッションとのアフィニティに従うようになります。 短い思考時間で複数の操作を行う同時ユーザー数の予想値に構成します。短い思考時間でアプリケーションを使用する予定のユーザーがいない場合は、この値を0(ゼロ)に設定して、アフィニティを解消してもかまいません。 |
|
インスタンスの最大有効時間
|
この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内の接続モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。 デフォルト値は3600000ミリ秒(3600秒または1時間)です。値を低くすると、次回のリソース・クリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が短くなります。ほとんどのアプリケーションでは、デフォルト値で十分です。値を高くすると、次回のクリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が長くなります。 |
|
アイドル・インスタンス・タイムアウト
|
この時間(ミリ秒)を超えると、プール内の非アクティブなアプリケーション・モジュール・インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。 デフォルト値は、600000ミリ秒(600秒または10分)です。値を低くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が増えます。値を高くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が減ります。 |
|
プール・ポーリング間隔
|
プール・リソース・クリーンアップの時間間隔(ミリ秒)。 プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。 アプリケーション・モジュール・プール・モニターは、デフォルトでは600000ミリ秒(600秒または10分)ごとにウェイクアップします。短い間隔を構成すると、アクティブでないアプリケーション・モジュール・インスタンスを、メモリーを節約するために削除する頻度が高くなります。大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。 |
|
フェイルオーバー
|
フェイルオーバーを無効にするか有効にするかを指定します。デフォルトでは、フェイルオーバーは無効になっています。フェイルオーバーを有効にするには、このパラメータを 注意: アプリケーション・モジュール状態の受動化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。このタイプの障害によって、SQLException (Connection has already been closed)が生成されます。この例外は、サーバー・ログに保存されます。例外は、ユーザー・インタフェースを通してレポートされません。 状態の受動化が発生し、変更が保存されるようにするには、weblogic-application.xmlの< デプロイメント・ディスクリプタ・パラメータを数分に設定すると、ほとんどの場合、非アクティブな接続のタイムアウトは強制されず、その結果受動化は失敗します。ご使用の環境に合せて、この設定値を調整してください。 |
|
ロック・モード
|
ロック・モード( |
|
データベース接続プール
|
AMインスタンスがAMプールに戻されたときに、そのAMインスタンスをデータベース接続から切断できるかどうかを指定します。これにより、アプリケーションのAMプールをデータベース接続プールより大きなサイズに設定することができます。デフォルトは |
|
トランザクション切断レベル
|
|
システムのメモリーに制約がある場合に構成可能なパラメータについては、表8-8を参照してください。
表8-8 AMプール・サイズの構成 - メモリーに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
初期プール・サイズ
|
追加のAMインスタンスが必要な場合は、これを小さい値に設定するとメモリーを節約できますが、パフォーマンスの低下というコストが発生します。デフォルト値の0(ゼロ)の場合、AMプールの初期化時にAMインスタンスが作成されません。 |
|
最大プール・サイズ
|
これを構成すると、AMインスタンスの数が指定の値を超えるのを防止できます。ただし、設定した値が小さすぎると、使用可能なAMインスタンスがない場合に、アプリケーションへのアクセス・エラーが発生することがあります。 |
|
最小使用可能プール・サイズ
|
ゼロ(0)に設定すると、リソース・クリーンアップ後、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
最大使用可能プール・サイズ
|
これを構成すると、リソース・クリーンアップ後に指定した最大数の使用可能インスタンスを残すことができます。 |
構成するとCPUの負荷をある程度軽減できるパラメータについては、表8-9を参照してください。
表8-9 AMプール・サイズの構成 - CPUに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
初期プール・サイズ
|
この値は、アプリケーション・プールの初期のAMインスタンス数に設定します。初期化時にAMインスタンスを作成する場合、追加のAMインスタンスが必要になったときにオンデマンドで作成するのではなく、初期化時に作成するためのCPU処理コストがかかります。 |
|
セッション・リサイクルのしきい値 |
ユーザーのセッションに対するAMインスタンスのアフィニティを維持するには、この値を設定します。このアフィニティを可能なかぎり維持することで、あるユーザーから別のユーザーへAMインスタンスを切り替える際に必要なCPU処理コストを削減できます。 |
次のパラメータは、AMプールのリソース・クリーンアップの頻度および特性に影響を与えます。
システムのメモリーに制約がある場合は、より多くのAMインスタンスをより頻繁にクリーンアップするようAMプールを構成します。そうすることで、AMインスタンスによって消費されるメモリーを解放して、他の目的で使用できるようになります。
AMプールを構成して、より多くのAMインスタンスがより長い期間プール内に存在できるようにすることで、CPU処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。
注意: 使用可能なAMインスタンスの数を減らしてクリーンアップの頻度を高めると、CPU使用率が上昇し、レスポンス時間も長くなる可能性があります。
表8-10 AMプールのリソース・クリーンアップの構成 - メモリーに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
最小使用可能サイズ |
ゼロ(0)に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
最大使用可能サイズ
|
一般に、値を小さくすると、クリーンアップ時にプールから削除されるAMインスタンスが増加します。 これらを大きな値に設定すると、プール内に残されるアイドル・インスタンスが増えるため、後でAMインスタンスを再作成する必要がなくなります。ただし、過度に大きな値を設定して、最大負荷時に必要な数より多くのAMインスタンスを保持することは避けてください。 |
|
有効時間
|
値を小さくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が短くなります。 値を大きくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が長くなります。 注意: -1に設定すると、有効時間は無制限になります。この設定は、メモリー・リークのない、十分にテストされたアプリケーションでのみ使用するようにしてください。 |
|
非アクティブ最長有効時間
|
値を小さくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが増加します。 値を大きくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが減少します。 |
|
モニターのスリープ間隔
|
これは、リソース・クリーンアップがトリガーされる頻度を制御します。間隔を短く設定すると、メモリーの節約のために非アクティブのAMインスタンスが削除される頻度が高まります。 大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。 |
表8-11 ADFcリージョン構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
特定の機能が必要とされる場合にのみ、ページにリージョンを追加してください。 |
ページにリージョンを追加すると、アプリケーションが大きく強化されます。ただし、リージョンはページで大量のリソースを消費するコンポーネントでもあります。パフォーマンスを高めるには、特定の機能が必要とされる場合にのみリージョンの使用を検討してください。 |
|
adf-configで |
adf-configでdetect-metadata-changesを メタデータの変更の検出は、バインドなしタスク・フローをカスタマイズするアプリケーションでのみ必要です。アプリケーションでバインドなしフローがカスタマイズされている場合、RT APIを使用して必要に応じてこのプロパティを有効にしたり、無効にしたりすることができます。 |
|
可能な場合は、1つの表示されるルート・コンポーネントの内部に非表示のポップアップをネストすることを検討します。 |
複数のルート・コンポーネントを持つリージョンは、パフォーマンスに悪影響を与える可能性があります。表示されるルート・コンポーネントが1つだけ存在し、それ以外は非表示のポップアップである場合でも、パフォーマンスに影響することがあります。 たとえば、拡大を行う必要がない場合、すべてを |
デフォルトでは、ページがロードされると、最初はレンダリングされなくても、タスク・フローはアクティブ化されます。このため、タスク・フローがまったく表示されない場合、不要なオーバーヘッドが発生します。
デフォルトでは、スイッチャの下のタスク・フローは、スイッチャ・ファセットが表示されるときではなく、ページがロードされるとアクティブ化されます。これを回避するには、条件付きアクティブ化を使用し、ファセットが表示されるとtrueを戻す式言語(EL)式に"active"を設定します。タスク・フローの条件付きアクティブ化を行うために、スイッチャに対して同じ条件を使用することを検討してください。
スイッチャの例:
<af:switcher id="s1" defaultFacet="1" facetName="#{pageFlowScope.facet}">
<f:facet name="1">
<af:region value="#{bindings.TF1.regionModel}" id="r1"/>
</f:facet>
<f:facet name="2">
<af:region value="#{bindings.TF2.regionModel}" id="r2"/>
</f:facet>
</af:switcher>
関連するバインディング:
<taskFlow id="tTF1" taskFlowId="-----" active="#{pageFlowScope.facet=='1'}" activation="conditional" xmlns="http://example.host.com/adf/controller/binding"/>
<taskFlow id="tTF2" taskFlowId="-----" active="#{pageFlowScope.facet=='2'}" activation="conditional" xmlns="http://example.host.com/adf/controller/binding"/>
アプリケーション全体で再利用可能な静的データがアプリケーションに含まれている場合、共有アプリケーション・モジュールを使用してキャッシュ・データを収集できます。共有アプリケーション・モジュールの作成および使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュール・ビュー・インスタンスの共有に関する項を参照してください。
エンティティ属性に対してリソース消費量の多い検証を実行するときは、事前条件を使用し、必要な場合にのみ検証を選択して適用することを検討してください。検証のコストを事前条件のコストと比較し、事前条件がパフォーマンス上有益かどうかを判断する必要があります。検証の事前条件を指定する方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の検証の事前条件の設定方法に関する項を参照してください。
Groovyを使用して式を評価するアプリケーションがある場合、パフォーマンスを向上させるために式をチューニングする必要があることがあります。Groovyスクリプトの解析はパフォーマンスに影響を与えます。そのため、必要な場合にのみ使用することが適切です。
たとえば、次のように、一般的な式を評価するためにgroovyを使用しているとします。
Date currentDate = null;
.......
ExprEval expression = new ExprEval("adf.currentDate", ExprEval.EXPR_STYLE_GROOVY);
currentDate = (Date)expression.evaluate(null);
次の変更を加えることで、パフォーマンスが向上する可能性があります。
日付と時間が重要な場合は、次のようにすることで、パフォーマンスが向上する可能性があります。
currentDate = new Date(System.currentTimeMillis());
日付と時刻が必要ない場合は、次のようにすることを検討してください。
Calendar cal = Calendar.getInstance();
cal.set(Calendar.HOUR, 0);
cal.set(Calendar.HOUR_OF_DAY, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
currentDate = new java.sql.Date(cal.getTimeInMillis());
