| Oracle® Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.1.2) E47969-01 |
|
 前 |
 次 |
この章では、Oracle Application Development Framework (ADF)のパフォーマンスおよびスケーラビリティを最大化する方法についての基本的なガイドラインを示します。次の各項で、設計時、構成時およびデプロイメント時のパフォーマンスに関する考慮事項を取り上げます。
この章では、読者がADFアプリケーションの構築に精通しているものと想定しています。ADFについては、次のマニュアルを参照してください。
Oracle Application Development FrameworkによるFusion Webアプリケーションの開発
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 Application Development FrameworkによるFusion Webアプリケーションの開発』のOracle ADFの概要に関する項を参照してください。
ADFアプリケーションの構築、構成およびデプロイを行う前に、最適なパフォーマンスが得られるよう、チューニングに関する次の推奨事項に目を通してください。
この項では、ADF Facesの構成およびプロファイリングの概念について説明します。Oracle ADF Facesの構成オプションは、web.xmlファイルに設定されています。ほとんどの構成オプションには、パフォーマンスを考慮してチューニングされたデフォルト値があります。表8-1に、これらの構成オプションの一部を示します。
表8-1 ADFの構成オプション
| パラメータ | 説明 |
|---|---|
|
圧縮ビューの状態
|
ページ状態を圧縮するかどうかを制御します。データのサイズが圧縮されると、待機時間を減らすことができます。このパラメータは |
|
拡張デバッグ
|
出力をデバッグ用に拡張するするかどうかを制御します。このパラメータは削除するか、 |
|
ファイル変更の確認
|
ADF FacesがJSPページの変更日付をチェックして、ファイルに変更があった場合は保存されている状態を破棄するかどうかを制御します。このパラメータは削除するか、 |
|
クライアント状態のメソッド
|
クライアント側での状態の保存が有効になっている場合に、どのタイプの保存( |
|
クライアント側ログ・レベル |
クライアント側のログ・レベルを設定します。デフォルト値は |
|
アサーション処理
|
クライアント側でアサーションをいつ処理するかを指定します。デフォルト値は |
|
注意: Firefoxブラウザを使用してクライアントのレスポンス時間のプロファイリングまたは測定を行う際には、Firebugプラグインが無効になっていることを確認してください。ページの情報を取得したり、ページのJavaScriptコードをデバッグしたりする目的では、このプラグインは非常に有効ですが、総レスポンス時間に影響を与える可能性があります。 Firefox Firebugプラグインの無効化の詳細は、Firefox Support Home Page( |
表8-2に、ADF Facesのパフォーマンス向上につながる、構成に関する推奨事項を示します。
表8-2 ADF Facesの構成パラメータ
| 構成に関する推奨事項 | 説明 |
|---|---|
|
ページでインラインJavaScriptの使用を避けます。 |
インラインJavaScriptは、レスポンス・ペイロード・サイズを増加させる可能性があり、ブラウザにまったくキャッシュされないため、ブラウザのレンダリングをブロックすることがあります。インラインJavaScriptを使用するかわりに、すべてのスクリプトをJavaScriptライブラリ内の.jsファイルに入れることを検討し、スクリプトをaf:resourceタグを使用してページに追加してください。 ヒント: 可能であればtrh:scriptではなく、af:resourceの使用を検討してください。 |
|
JSPタイムアウト・パラメータを構成します。 |
JavaServer Pages (JSP)タイムアウト・パラメータを使用すると、web.xmlの次の設定によって使用頻度の低いページがキャッシュからフラッシュされます。
<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構造のレイアウトに問題があります。 ドロップダウン・ポップアップを使用して単一のツールバー項目を作成し、すべての入力フィールドをその中に入れます。このポップアップは、子の作成およびcontentDelivery="lazy"を延期します。 |
|
不明なrowCountを削除します。 |
不明なrowCountがある表は、行の最終セットを取得するとスクロールが過度に行われるため、パフォーマンスに影響を与える可能性があり、アプリケーションが非常に遅く感じられることがあります。 ビュー・オブジェクト(VO)でDeferEstimatedRowCountProperty="false"を設定して、不明なrowCountを削除します。 |
|
ユーザーが表示できないポップアップを無効にします。 |
fnd:attachmentコンポーネントは、表にスタンプ設定されると、大量のDOMおよびクライアント・コンポーネントを生成する可能性があります。DOMおよびクライアント・コンポーネントの量は、1セル当たり8Kまでですが、特に速度の遅いブラウザではページ全体のパフォーマンスに影響を与えます。 ほとんどのセルには、最初は添付ファイルがなく、ユーザーが表示できるポップアップは1つのみです。したがって、ユーザーが表示できないポップアップには、renderer="false"を設定します。これにより、ブラウザに送信される不要なDOMおよびクライアント・コンポーネントを削減できます。同様に、DOMには、空のセルの数を指定したpanelGroupLayoutを設定します。空のセルのDOMを送信する必要はありません。 |
|
ナビゲーション・リンクでホバー・ポップアップを使用しないでください。 |
ナビゲーション・リンクでホバー・ポップアップを使用すると、ナビゲーションはホバーが最初にフェッチされるのを待機します。 補正要員表のナビゲーション・リンク列のホバー・ポップアップを削除し、かわりに別の列かセル内のアイコンに配置することを検討してください。 |
|
表のスクロール・タイムアウトを増やします。 |
表は、タイムアウト後、スクロールについてフェッチ・リクエストをサーバーに送信します。タイムアウト(フェッチがサーバーに送信されるまで)は、ユーザーが短いスクロールを行う場合、通常20ミリ秒ですが、ユーザーがさらにスクロールする場合は200ミリ秒に増やすことができます。したがって、ユーザーがページの一番下までスクロールし、表が複数のリクエストをサーバーに送信すると、パフォーマンスに影響が出る可能性があります。 パフォーマンスに影響が出ないようにするには、タイムアウト制限を300ミリ秒に増やすことを検討してください。 |
|
タイムアウトを使用して_prepareForIncompleteImagesをコールします。 |
部分ページ・レンダリング(PPR)中、一部のイメージが完全にロードされないことがあります。この事象が発生した場合、子孫の1つのサイズが変更されたことを親コンポーネントに通知する必要があります。これまで、この通知はimageタグのcomplete属性を使用して行われました。現在、Internet Explorer 8では、complete属性が常にfalseで、Internet Explorer 7および8のパフォーマンス問題を軽減しています。PPRコンテンツがフェッチされた直後、キャッシュされたイメージに対してさえ、属性はfalseと表示されます。 Internet Explorer 8の場合、.xml HTTPリクエストの直後にコールされたimageタグが処理されるように、タイムアウト(10ミリ秒)を使用して_prepareForIncompleteImagesをコールします。これは、Mozilla FirefoxまたはGoogle Chromeの問題ではありません。 |
|
GetFirstVisibleRowKeyandRowをキャッシュします。 |
パフォーマンスは、最初の表示可能なRowkeyおよび行をローカルにキャッシュすると向上する可能性があります。このキャッシュされた値は、スクロールまたはサイズ変更で削除できます。 |
|
部分ページ・ナビゲーションを使用します。 |
部分ページ・ナビゲーションは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 Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。 ページに
前述の手順により、コマンド・ボタンを使用して部分ページ・リフレッシュをトリガーするPPRが実現します。 部分ページ・レンダリングによってパフォーマンスが大幅に向上する主な理由は、ページ全体のリフレッシュが発生せず、フレームワーク・アーティファクト(ADF Rich ClientのJSライブラリやスタイルシートなど)がリロードされるかわりに、ページの小さい部分のみがリフレッシュされることです。そのため、余分なデータのフェッチやジオメトリ管理が一切行われない場合もあります。 ADF Rich Clientは、部分ページ・レンダリングを使用すればクライアント側で最適なパフォーマンスが得られることを実証しています。クライアント側での影響に加えて、サーバー側の処理が高速化され、サーバー側のスループットおよびスケーラビリティが向上します。 |
|
ADF Rich Clientのナビゲーションを使用します。 |
ADF Rich Clientは、ナビゲーションを幅広くサポートしています。一般的なユースケースの1つに、タブ付きナビゲーションがあります。これは現在、xmlMenuModelにバインドして簡単にナビゲーションを定義できるnavigationPaneなどのコンポーネントでサポートされています。 ただし、この方法にはデメリットが1つあります。それは、ユーザーがタブを切り替えるたびにページ全体のリフレッシュが発生することです。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つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスを改善するには、スタイルをページ先頭で定義し、可能であれば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の |
|
リソース・デバッグ・モードを無効にします。 |
リソース・デバッグ・モードを有効にすると、ブラウザはリソース(JSライブラリ、CSSスタイルシート、イメージなど)がキャッシュ可能であることをHTTPレスポンス・ヘッダーから判断できません。 キャッシュを確実に有効にするには、 |
|
タイムスタンプのチェックを無効にします。 |
web.xmlファイルで |
|
CSSファイルの変更のチェックを無効にします。 |
|
|
コンテンツの圧縮を有効にします。 |
デフォルトでは、レンダリングされたスタイル・クラスは、ページ・サイズを小さくするために圧縮されます。本番環境では、必ず デバッグの際には、スタイル・クラスのコンテンツの圧縮をオフにします。そのためには、 |
|
JavaScriptの曖昧化を有効にします。 |
ADF Facesは、曖昧化されていないJavaScriptライブラリを提供するためのランタイム・オプションをサポートしています。デフォルトで提供されるのは曖昧化されたJavaScriptライブラリですが、開発ビルド用に曖昧化されていないものも提供されます。曖昧化を行うと、JavaScriptライブラリ全体のサイズが約50%削減されます。 曖昧化されたADF Facesビルドを提供するには、web.xmlファイルで Firebugが有効なFirefoxを使用して、コードが曖昧化されていることを確認するには、2つの方法があります。 ダウンロード・サイズの確認:
ソースの確認:
|
|
ライブラリのパーティション化を有効にします。 |
Oracle 11g リリースでは、ライブラリのパーティション化がデフォルトでオンになっています。旧バージョンでは、ライブラリのパーティション化はデフォルトでオフになっていました。ライブラリのパーティション化がオンになっていることを確認してください。そのためには、web.xmlファイルで |
表8-3に、ADF Facesコンポーネント属性の構成に関する推奨事項を示します。
表8-3 ADF Facesコンポーネント属性
| 構成に関する推奨事項 | 説明 |
|---|---|
|
immediate属性を使用します。 |
ADF Rich Clientのコンポーネントには
ADF Rich ClientはJSFをベースとし、標準のJSFライフサイクルを採用しています。『 Oracle ADF Facesによる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 ADF FacesによるWebユーザー・インタフェースの開発』のクライアント側コンポーネントに関する項を参照してください。 |
|
|
注意: この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。
また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。 |
table、treeおよびtreeTableは、最も複雑で使用頻度の高いコンポーネントです。これらのコンポーネントは大きなデータ・セットを格納できるため、よくパフォーマンスの問題の原因となります。表8-4に、パフォーマンスに関する推奨事項を示します。
表8-4 tableコンポーネントおよびtreeコンポーネントの構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
editingMode="clickToEdit"を使用します。 |
editingMode="editAll"を使用すると、編集可能な値ホルダーの全コンテンツとその子コンポーネントが送信されます。これにより、クライアントのHTTPペイロードおよびDocument Object Model (DOM)コンテンツは大幅に増加します。 editingMode="clickToEdit"に切り替えて送信されるデータ量を削減し、ユーザーとのやり取りを向上させることを検討してください。 |
|
可能であれば、fetchSizeを減らします。 |
af:tableのfetch size属性が大きいほど、処理、サーバーからのフェッチおよびクライアントでの表示が必要なデータが多いことを示します。これは、クライアントで表示されるDOMの量を増やす可能性もあります。 |
|
表のフェッチ・サイズを変更します。 |
表には、1回のラウンドトリップでクライアントに送信される行数を定義したフェッチ・サイズがあります。最適なパフォーマンスを得るには、この数を最低限に抑えます。ただし、表ビューの初期ポートを実行するのに十分な行を確保してください。そうすることで、最適なパフォーマンスを得ながら余分なサーバー・リクエストを排除できます。 また、表のフェッチ・サイズとイテレータの範囲サイズを合せることを検討してください。デフォルトでは、表のフェッチ・サイズはEL式 詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表およびツリーの使用に関する項を参照してください。 |
|
列の拡大を無効にします。 |
tableコンポーネントおよびtreeTableコンポーネントの列は、最後の列の端とtableコンポーネントまたはtreeTableコンポーネントの輪郭との間に未使用の領域が残らないよう、拡大することができます。この機能は、パフォーマンスに影響を与える可能性があるため、デフォルトでオフになっています。この機能をオンにすると、クライアントのレンダリング時間に影響が出ることがあります。したがって、この機能を複雑な表に対して有効にするときは十分に注意してください。 |
|
ヘッダー行および固定列は必要な場合にのみ使用することを検討します。 |
tableコンポーネントには、行ヘッダーおよび固定列を設定できる機能があります。これらのオプションを使用すると、優れたデザインのインタフェースを作成でき、ユーザー体験も向上します。ただし、クライアント側のパフォーマンスに影響が出る可能性があります。tableコンポーネントで最適なパフォーマンスを得るには、これらのオプションを必要な場合にのみ使用します。 |
|
invokeOnComponentのかわりにvisitTreeの使用を検討します。 |
visitTreeを使用した部分的な訪問は常に、少なくともinvokeOnComponentと同じ速さです。さらに、訪問を制御するコンポーネントの場合、invokeOnComponentおよびvisitTreeの両方の実装を提供することはエラーの原因となります。invokeOnComponentは非推奨として扱われるため、かわりにvisitTreeの使用を検討してください。 詳細は、『Oracle ADF FacesによるWebユーザー・インタフェースの開発』の表およびツリーの使用に関する項を参照してください。 |
autoSuggestは、inputText、inputListOfValues、inputComboboxListOfValuesの各コンポーネントに対して有効にできる機能です。ユーザーが入力フィールドに文字を入力すると、コンポーネントは候補となる項目のリストを表示します。この機能により、データベース表で問合せが実行され、結果がフィルタ処理されます。データベース処理を高速化するために、autoSuggestが有効になっている列にデータベース索引を作成してください。そうすることで、特にデータベース表の行数が多い場合に、コンポーネントのレスポンス時間が改善されます。
table、tree、その他のスタンプ設定されたコンポーネントのデータは、遅延配信または即時配信が可能です。デフォルトでは、遅延配信が使用されます。つまり、サーバーからの最初のレスポンスではデータは配信されません。初期ページがレンダリングされた後、クライアントがサーバーにデータを要求し、2番目のリクエストへのレスポンスとしてデータを取得します。
即時配信の場合は、ページ・リクエストへのレスポンスと同時にデータを取得できます。データ配信が行われるのはコンポーネントごとであり、ページごとではないので注意してください。つまり、この2つを同じページ上に混在させることが可能です。
この2つのオプションから選択する際には、次の点を考慮してください。
|
遅延配信(デフォルト) |
遅延配信は、表やフェッチ時間の遅いスタンプ設定された他のコンポーネントに使用する必要があります。たとえば、スタンプ設定されたコンポーネントがWebサービス呼出しを使用したデータ・コントロールや遅いデータ・フェッチの他のデータ・コントロールに基づく場合です。ユーザーが下にスクロールしないとすぐに内容が表示されないページにも遅延配信を使用できます。この場合、クライアントに表示されるコンテキストの配信時間が短くなり、ユーザーがパフォーマンスの向上を認識します。 遅延配信は、データ・ストリーミング技術を使用して実現されます。この方式が優れているのは、サーバーがデータ・フェッチを並行して実行し、データが使用可能になると同時に、そのデータをクライアントへストリーミング配信することが可能な点です。この方式は、ページに表が2つあり、一方の表ではデータがごく短時間で返され、もう一方の表ではデータが返されるまで長時間かかるといった場合に、高い効果を発揮します。高速な表のデータは、取得されると同時にユーザーに対して表示されます。 また、並行してデータ・フェッチを実行すると、データ・フェッチの合計時間が短縮されます。これは、複数の遅くなる可能性のあるデータ・フェッチの遅延ロードに利点があります。ストリーミングは遅延モードのデータ配信のデフォルト・メカニズムですが、データ・コントロールのパラレル実行はそうではありません。パラレル実行を有効にするには、ページ定義を開いて、イテレータの 場合によっては、パラレル実行のレスポンス時間が短縮される利点があります。パラレル実行では並行してリクエストを実行する複数のスレッドのために多くのリソースを使用する可能性があり、開くデータベース接続が多くなる場合があります。 ページに複数の遅いコンポーネントが存在し、スタンプ設定されたコンポーネントが異なるデータ・コントロール・フレーム(分離したタスクフローなど)に属する場合のみ、パラレル実行を使用することを検討してください。パラレル実行がデータ・コントロール・フレーム・レベルで同期化するため、単一のデータ・コントロール・フレームのパラレル実行ではパフォーマンスが改善しない場合があります。 |
|
即時配信 |
即時配信( 即時配信のもう1つの利点は、遅延配信に比べてサーバー・リソースの使用率が低いことです。即時配信では、サーバーに送信されるリクエストは1つのみなので、特定のユーザー・インタラクションにおけるCPUおよびメモリーの使用率が低下します。 |
DVTコンポーネントは、ADF Rich Clientコンポーネントをベースとするデータ視覚化コンポーネントです。DVTコンポーネントには、グラフ、ゲージ、ガント・チャート、ピボット・テーブル、マップなどがあります。表8-5に、DVTコンポーネントの構成に関する推奨事項を示します。
表8-5 DVTコンポーネントの構成
| 構成に関する推奨事項 | 説明 |
|---|---|
|
RangeSize属性を使用します。 |
RangeSize属性は、同時に返す行の数を定義します。RangeSizeに値-1を指定すると、イテレータはすべての行を返します。小さい値を使用すればパフォーマンスは向上しますが、データを止めるのが難しくなる場合があります。また、rangeSizeを超えるデータはビューに表示されません。 |
|
縦方向のテキストではなく横方向のテキストを使用します。 |
デフォルトでは、ピボット・テーブルの列ヘッダーとして横方向のテキストが使用されます。ただし、縦方向のテキストを使用するオプションもあります。縦方向のテキストを使用するには、ヘッダー・フォーマットとして次のようなCSSスタイルを指定します。
縦方向のテキストのほうが見栄えがよいこともありますが、Firefoxブラウザを使用する場合はパフォーマンスに影響が出ます。 問題なのは、FirefoxがInternet Explorerのように縦方向のテキストに対応していないことです。縦方向のテキストを表示するために、ピボット・テーブルではGaugeServletによって生成されたイメージが使用されます。テキストは動的で、バインディング値に依存しているので、このイメージをキャッシュすることはできません。そのため、ピボット・テーブルをレンダリングするたびに、イメージをフェッチする目的でサーバーへの余分なラウンドトリップが発生し、ネットワーク・トラフィック、サーバーのメモリーおよびCPUに影響を与えます。 最適なパフォーマンスを得るには、縦方向のテキストではなく横方向のテキストを使用することを検討してください。 |
前の項で推奨されているチューニングの変更を行った後、ADFサーバー・デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
Oracle ADFサーバー・コンポーネントは、ADF内のUI以外のコンポーネントからなります。これには、モデル・レイヤーのADF実装(ADFm)、ビジネス・サービス・レイヤーのADF実装(ADFbc)、およびコントローラ・レイヤーのADF実装(ADFc)が含まれます。サーバー・コンポーネントは自由に構成できますが、重要なのは、指定したアプリケーション・パフォーマンスおよび機能を備える使用可能リソースに最適な構成の組合せを選択することです。
|
注意: ADFmを使用するときには、パフォーマンスを維持するために遅延実行の使用を検討し、リフレッシュ状態を監視してください。 |
重要なユーザー・コミュニティを持つADFアプリケーションの場合、デフォルトのHTTPセッション・タイムアウトの45分を使用すると、期限切れを待機しているセッションによって保持されるメモリー量がパフォーマンスに悪影響を与えることがあります。保持されるメモリーは物理的に使用可能な量より大きくなる可能性があり、サーバーは負荷を処理できなくなります。公開Webサイトを使用しているユーザーなど、ユーザー数が多い場合は、セッション・タイムアウトをできるだけ短くする必要があります。
パフォーマンスを向上させるには、web.xmlファイルでセッション・タイムアウトのデフォルト値(分単位)を変更することを検討してください。ユースケース・シナリオで機能するセッション・タイムアウト値を使用します。次の例は、10分のセッション・タイムアウトを示しています。
<session-config> <session-timeout> 10 </session-timeout> </session-config>
ビュー・オブジェクト(VO)にはチューニング・オプションが数多く用意されているため、開発者はアプリケーション固有のニーズに合せてビュー・オブジェクトをカスタマイズできます。ビュー・オブジェクトは、機能要件を満たすのに必要な最小限の機能セットを使用するよう構成してください。『Oracle ADF FacesによるWebユーザー・インタフェースの開発』は、ビュー・オブジェクトのチューニングに関する詳細情報を提供しています。ここでは、ビュー・オブジェクトのパフォーマンスに関するヒントをいくつか示します。
ビュー・オブジェクトのパフォーマンスを最大化するには、ビュー・オブジェクトを目的の用途に合致させる必要があります。たとえば、値リストのピックリスト用に取得されたデータは読取り専用であるのが一般的です。したがって、このデータを問い合せるには、読取り専用のビュー・オブジェクトを使用します。ビュー・オブジェクトをアプリケーション固有のニーズに合せてカスタマイズすると、パフォーマンス、メモリー使用率、CPU使用率およびネットワーク使用率を改善できます。
| ビュー・オブジェクトのタイプ | 説明 |
|---|---|
|
読取り専用のビュー・オブジェクト |
ビュー・オブジェクトがデータの挿入や更新を行う必要がない場合は、読取り専用のビュー・オブジェクトの使用を検討してください。読取り専用のビュー・オブジェクトには2つの種類があります。
更新不可能なEOベースのビュー・オブジェクトには、カスタマイズ可能な選択リストによってUIで必要とされる属性を実行時に取得できる、ローカル・キャッシュからデータを読み取ることができる(データベース問合せの再実行が不要)、同じEOに基づいた他の更新可能なビュー・オブジェクトとの間でデータの一貫性を確保できる、といった利点があります。 エキスパートモードのビュー・オブジェクトには、EOがサポートしていないSQL操作を実行し、ビュー・オブジェクトとEOの行の連携によって発生するパフォーマンスへのわずかな影響を回避するという機能があります。EOベースのビュー・オブジェクトに対して選択したEOでupdatableオプションを選択解除すると、そのビュー・オブジェクトは更新不可能としてマークされます。また、ビュー・オブジェクトのXML定義で |
|
挿入専用のビュー・オブジェクト |
レコードを挿入する目的でのみ使用されるビュー・オブジェクトの場合、そのビュー・オブジェクトを使用する際に不要なSELECT問合せが実行されるのを防ぐことができます。そのためには、ビュー・オブジェクトの概要タブの「データベースから取得」グループ・ボックスでオプション「行なし」を設定します。これで、ビュー・オブジェクト定義のMaxFetchSizeが0(ゼロ)に設定されます。 |
|
実行時に作成されるビュー・オブジェクト |
AMで |
ビュー・オブジェクトのパフォーマンスは、ビュー・オブジェクトによるデータ・フェッチがどのように構成されているかによって大きく変わります。フェッチ・オプションがアプリケーションに対して正しくチューニングされていないと、ビュー・オブジェクトが必要以上のデータをフェッチしたり、データベースへのラウンドトリップの回数が多くなりすぎたりする可能性があります。フェッチ・オプションは、図8-1に示した「ビュー・オブジェクト」ダイアログの「データベースから取得」グループ・ボックスで構成できます。
| フェッチ・オプション | 説明 |
|---|---|
|
フェッチ・モード |
デフォルトのフェッチ・オプションは「すべての行」オプションです。この場合、必要に応じて取得( |
|
フェッチ・サイズ |
「次の単位で」フィールドは、フェッチ・モード・オプションとともに、データベースから同時にフェッチされるレコードの数を制御します(ビュー・オブジェクトのXMLのFetchSize)。デフォルト値は1ですが、この値では、1行のみフェッチされる場合を除き、パフォーマンスに影響を与える可能性があります。推奨構成として、この値をn+1に設定することをお薦めします。nはユーザー・インタフェースに表示される行数です。 DVTオブジェクトについては、フェッチ・サイズをn+1に設定してください。nは、rangeSizeか、rangeSizeが-1の場合は予想される最大行セット・サイズです。 |
|
最大フェッチ・サイズ |
ビュー・オブジェクトのデフォルト最大フェッチ・サイズは-1です。つまり、ビュー・オブジェクトがフェッチできる行の数に制限はありません。最大フェッチ・サイズを0(ゼロ)に設定すると、ビュー・オブジェクトは挿入専用になります。結果セットにn行のデータのみを含める場合は、「行番号までのみ」オプションを選択して設定するか、 ビュー・オブジェクトのWHERE句に単一行を取得することを指定するには、「最大で1行」オプションを設定します。このオプションを設定すると、ビュー・オブジェクトは行がそれ以上返されないことを認識し、その状況における通常のテストを省略します。この場合、SELECT問合せは発行されず、行はフェッチされません。 最大フェッチ・サイズを使用して、何百(または何千)もの行を返す非選択的な問合せが与える影響を抑えることもできます。その場合は、最大フェッチ・サイズを指定することで、フェッチしてメモリーに格納することのできる行の数が制限されます。 |
|
順方向専用モード |
データ・セットが順方向にのみトラバースされる場合は、順方向専用モードを使用すると、データ・セットを反復する際のパフォーマンスが向上します。これを構成するには、ビュー・オブジェクトに対して |
表8-6に、ビュー・オブジェクト使用時のチューニングに関するその他の考慮事項を示します。
表8-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属性で構成します。
アプリケーション・モジュールの粒度の設計は、パフォーマンスおよびスケーラビリティに大きな影響を与える重要な考慮事項です。各ルート・アプリケーション・モジュールは通常、専用のデータベース接続を保持していることに注意してください。ユーザー・セッションが複数のルート・アプリケーション・モジュールを消費する場合、そのユーザー・セッションは同時に複数のデータベース接続を保持している可能性があります。このような状況は、アプリケーション・モジュールとユーザー・セッションの間で全般的なアフィニティが維持されるために、接続が実際には使用されていない場合でも発生します。ユーザーが同時に複数の接続を保持する可能性を減らすには、次の方法を検討します。
ユーザーが必要とする機能をすべて網羅した大きなアプリケーション・モジュールを設計します。
小さなアプリケーション・モジュールを単一のルート・アプリケーション・モジュールの下にネストし、ネストされたアプリケーション・モジュールの間で同じデータベース接続を共有できるようにします。
アプリケーション・モジュールで遅延ロードを使用します。アプリケーション・モジュールのチューニング・セクションで、遅延ロードを使用するように実行時のインスタンス化動作をカスタマイズします。遅延ロードは、次のJVM引数を追加して、JVM全体で設定することもできます。
-Djbo.load.components.lazily=true
アプリケーション・モジュール(AM)・プーリングを使用すると、複数のユーザーが複数のアプリケーション・モジュール・インスタンスを共有できます。AMプールの構成は、予想されるアプリケーションの使用状況によって異なります。
ほとんどのAMプール・パラメータは、Oracle JDeveloperを介して設定できます。構成内容はbc4j.xcfgに保存されますが、必要に応じて手動で編集できます。パラメータをJVMパラメータ(-Dプロパティ=値)として指定し、システム・レベルで設定することもできます。bc4j.xcfgの構成は、JVMの構成より優先されます。そのため、システムレベルの汎用構成をアプリケーション固有の例外で上書きすることも可能です。
表8-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使用率の具体的なチューニングについては、第8.3.1.6.2項「AMプール・サイズの構成」を参照してください。
表8-8 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-9を参照してください。
表8-9 AMプール・サイズの構成 - メモリーに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
初期プール・サイズ
|
追加のAMインスタンスが必要な場合は、これを小さい値に設定するとメモリーを節約できますが、パフォーマンスの低下というコストが発生します。デフォルト値の0(ゼロ)の場合、AMプールの初期化時にAMインスタンスが作成されません。 |
|
最大プール・サイズ
|
これを構成すると、AMインスタンスの数が指定の値を超えるのを防止できます。ただし、設定した値が小さすぎると、使用可能なAMインスタンスがない場合に、アプリケーションへのアクセス・エラーが発生することがあります。 |
|
最小使用可能プール・サイズ
|
ゼロ(0)に設定すると、リソース・クリーンアップ後、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
最大使用可能プール・サイズ
|
これを構成すると、リソース・クリーンアップ後に指定した最大数の使用可能インスタンスを残すことができます。 |
構成するとCPUの負荷をある程度軽減できるパラメータについては、表8-10を参照してください。
表8-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}"
|
注意: パフォーマンスの影響を制限するには、 |
次のパラメータは、AMプールのリソース・クリーンアップの頻度および特性に影響を与えます。
システムのメモリーに制約がある場合は、より多くのAMインスタンスをより頻繁にクリーンアップするようAMプールを構成します。そうすることで、AMインスタンスによって消費されるメモリーを解放して、他の目的で使用できるようになります。ただし、使用可能なAMインスタンスの数を減らしてクリーンアップの頻度を高めると、CPU使用率が上昇し、レスポンス時間も長くなる可能性があります。詳細は、表8-11を参照してください。
表8-11 AMプールのリソース・クリーンアップの構成 - メモリーに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
|
ゼロ(0)に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。 |
|
|
一般に、値を小さくすると、クリーンアップ時にプールから削除されるAMインスタンスが増加します。 |
|
|
値を小さくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が短くなります。 |
|
|
値を小さくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが増加します。 |
|
|
これは、リソース・クリーンアップがトリガーされる頻度を制御します。間隔を短く設定すると、メモリーの節約のために非アクティブのAMインスタンスが削除される頻度が高まります。 |
AMプールを構成して、より多くのAMインスタンスがより長い期間プール内に存在できるようにすることで、CPU処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。
表8-12 AMプールのリソース・クリーンアップの構成 - CPUに関する考慮事項
| パラメータ | 説明 |
|---|---|
|
|
これらを大きな値に設定すると、プール内に残されるアイドル・インスタンスが増えるため、後でAMインスタンスを再作成する必要がなくなります。ただし、過度に大きな値を設定して、最大負荷時に必要な数より多くのAMインスタンスを保持することは避けてください。 |
|
|
値を大きくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が長くなります。 |
|
|
値を大きくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが減少します。 |
|
|
大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。 |
ページにリージョンを追加すると、アプリケーションが大きく強化されます。ただし、リージョンはページで大量のリソースを消費するコンポーネントでもあります。パフォーマンスを高めるには、特定の機能が必要とされる場合にのみリージョンの使用を検討してください。
デフォルトでは、ページがロードされると、最初はレンダリングされなくても、タスク・フローはアクティブ化されます。このため、タスク・フローがまったく表示されない場合、不要なオーバーヘッドが発生します。
|
注意: 領域とタスク・フローの場合、現在のviewIdを評価するためにかかる時間とフローへの入力パラメータを計算するためにかかる時間が、全体のパフォーマンスに影響することがあります。設計フェーズではこれを検討してください。 |
デフォルトでは、ポップアップにアクセスしなくても、ポップアップの下に子コンポーネントが作成されます。このオーバーヘッドを回避するには、次のことを検討してください。
childCreationをdeferredに設定します。
ポップアップでchildCreation="deferred"を設定します。
タスクフローでactivation="deferred"を設定します。
|
注意: この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。
また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。その場合は、次に説明するように、条件付きアクティブ化を使用します。 |
条件付きアクティブ化を使用します。
jsff内のポップアップでプロパティ・リスナーを追加して条件を設定します。
タスクフローでactivation="conditional"を設定します。
タスクフローでactivate=<condition>を設定します。
デフォルトでは、スイッチャの下のタスク・フローは、スイッチャ・ファセットが表示されるときではなく、ページがロードされるとアクティブ化されます。これを回避するには、条件付きアクティブ化を使用し、ファセットが表示されるとtrueを戻す式言語(EL)式に"active"を設定します。
アプリケーション全体で再利用可能な静的データがアプリケーションに含まれている場合、共有アプリケーション・モジュールを使用してキャッシュ・データを収集できます。共有アプリケーション・モジュールの作成と使用の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の共有アプリケーション・モジュール・ビュー・インスタンスに関する項を参照してください。
エンティティ属性に対してリソース消費量の多い検証を実行するときは、事前条件を使用し、必要な場合にのみ検証を選択して適用することを検討してください。検証のコストを事前条件のコストと比較し、事前条件がパフォーマンス上有益かどうかを判断する必要があります。検証の事前条件を指定する方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の検証の事前条件の設定方法に関する項を参照してください。
