ヘッダーをスキップ
Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド
11g リリース1 (11.1.1)
B61006-10
  目次へ移動
目次

前
 
次
 

8 Oracle Application Development Frameworkのパフォーマンス・チューニング

この章では、Oracle Application Development Framework (ADF)のパフォーマンスおよびスケーラビリティを最大化する方法についての基本的なガイドラインを示します。次の各項で、設計時、構成時およびデプロイメント時のパフォーマンスに関する考慮事項を取り上げます。

この章では、読者がADFアプリケーションの構築に精通しているものと想定しています。ADFについては、次のマニュアルを参照してください。

8.1 Oracle ADFについて

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の概要に関する項を参照してください。

8.2 チューニングに関する基本的な考慮事項

ADFアプリケーションの構築、構成およびデプロイを行う前に、最適なパフォーマンスが得られるよう、チューニングに関する次の推奨事項に目を通してください。

8.2.1 Oracle ADF Facesの構成およびプロファイリング

この項では、ADF Facesの構成およびプロファイリングの概念について説明します。Oracle ADF Facesの構成オプションは、web.xmlファイルに設定されています。ほとんどの構成オプションには、パフォーマンスを考慮してチューニングされたデフォルト値があります。表8-1に、これらの構成オプションの一部を示します。

表8-1 ADFの構成オプション

パラメータ 説明

org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE

ページ状態を圧縮するかどうかを制御します。データのサイズが圧縮されると、待機時間を減らすことができます。デフォルトはFalseですが、パフォーマンスを最適化するには、このパラメータの設定をTrueにすることをお薦めします。

org.apache.myfaces.trinidad.resource.DEBUG

出力をデバッグ用に拡張するするかどうかを制御します。このパラメータは削除するか、Falseに設定してください。

oracle.adf.view.rich.CHECK_FILE_MODIFICATION

ADF FacesがJSPページの変更日付をチェックして、ファイルに変更があった場合は保存されている状態を破棄するかどうかを制御します。このパラメータは削除するか、Falseに設定してください。

oracle.adf.view.rich.CLIENT_STATE_METHOD

クライアント側での状態の保存が有効になっている場合に、どのタイプの保存(allまたはtoken)を使用するかを指定します。デフォルト値はtokenです。パフォーマンスを最適化するには、tokenの使用をお薦めします。

oracle.adf.view.rich.LOGGER_LEVEL

クライアント側のログ・レベルを設定します。デフォルト値はOFFです。このパラメータは削除するか、OFFに設定してください。

oracle.adf.view.rich.ASSERT_ENABLED

クライアント側でアサーションを処理するかどうかを指定します。デフォルト値はOFFです。このパラメータは削除するか、OFFに設定してください。



注意:

Firefoxブラウザを使用してクライアントのレスポンス時間のプロファイリングまたは測定を行う際には、Firebugプラグインが無効になっていることを確認してください。ページの情報を取得したり、ページのJavaScriptコードをデバッグしたりする目的では、このプラグインは非常に有効ですが、総レスポンス時間に影響を与える可能性があります。

Firefox Firebugプラグインの無効化の詳細は、Firefox Support Home Page(http://support.mozilla.com/en-US/kb/)を参照してください。


8.2.2 ADF Facesのパフォーマンスに関する考慮事項

表8-2に、ADF Facesのパフォーマンス向上につながる、構成に関する推奨事項を示します。

表8-2 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"を延期します。

不明なrowCountを削除します。

不明なrowCountがある表は、行の最終セットを取得するとスクロールが過度に行われるため、パフォーマンスに影響を与える可能性があり、アプリケーションが非常に遅く感じられることがあります。不明なrowCountは、行カウントの取得のために別途コールする必要がないため、サーバー側のパフォーマンスには適しています。

デフォルトでは、表は既知のrowCountです。

必要に応じて、ビュー・オブジェクト(VO)でDeferEstimatedRowCountProperty="false"を設定して、不明なrowCountを削除します。

ユーザーが表示できないポップアップを無効にします。

ほとんどのセルには、最初は添付ファイルがなく、ユーザーが表示できるポップアップは1つのみです。したがって、ユーザーが表示できないポップアップには、renderer="false"を設定します。このように、ブラウザに送信される不要なDOMおよびクライアント・コンポーネントを削減します。同様に、DOMには、空のセルの数を指定したpanelGroupLayoutを設定します。空のセルのDOMを送信する必要はありません。

サーバー側のパフォーマンスに対しては、遅延ポップアップ作成を使用します。

ポップアップを無効にすることにより、生成され、クライアントに送信されるHTMLのパフォーマンスは向上しますが、コンポーネント・ツリーがポップアップ用にすでに作成されているため、サーバー側で問題が発生する場合があります。可能な場合、遅延ポップアップ作成の使用を検討してください。

ただし、遅延ポップアップ作成を使用すると、既存のアプリケーションがページの別の部分からコンポーネントにアクセスしているにもかかわらずそのコンポーネントが表示されていない場合に、アプリケーションに障害が発生する場合があります。

コレクションベースのコンポーネント(表など)で共有ポップアップを使用します。

表内で複数のポップアップがスタンプ設定されるとパフォーマンスに影響を与える場合があるため、コレクションベースのコンポーネント(表など)では共有ポップアップを使用してオーバーヘッドを削減することを検討してください。

ナビゲーション・リンクでホバー・ポップアップを使用しないでください。

ナビゲーション・リンクでホバー・ポップアップを使用すると、ナビゲーションはホバーが最初にフェッチされるのを待機します。

補正要員表のナビゲーション・リンク列のホバー・ポップアップを削除し、かわりに別の列かセル内のアイコンに配置することを検討してください。

タイムアウトを使用して_prepareForIncompleteImagesをコールします。

部分ページ・レンダリング(PPR)中、一部のイメージが完全にロードされないことがあります。この事象が発生した場合、子孫の1つのサイズが変更されたことを親コンポーネントに通知する必要があります。これまで、この通知はimageタグのcomplete属性を使用して行われました。現在、Internet Explorer 8では、complete属性が常にfalseで、Internet Explorer 7および8のパフォーマンス問題を軽減しています。PPRコンテンツがフェッチされた直後、キャッシュされたイメージに対してさえ、属性はfalseと表示されます。

GetFirstVisibleRowKeyandRowをキャッシュします。

パフォーマンスは、最初の表示可能なRowkeyおよび行をローカルにキャッシュすると向上する可能性があります。このキャッシュされた値は、スクロールまたはサイズ変更で削除できます。

部分ページ・ナビゲーションを使用します。

部分ページ・ナビゲーションはADF Facesフレームワークの機能です。これを使用すると、ブラウザであるADF Facesページから別のADF Facesページへ移動する際に、ページ全体の遷移が不要になります。新しいページは、部分ページ・レンダリング(PPR)/Ajaxチャネルを使用してクライアントに送信されます。

従来のページ全体のナビゲーションと比較した部分ページ・ナビゲーションの主な利点は、パフォーマンスの向上です。ブラウザがJavaScriptライブラリを再度解釈して実行する必要はなく、ページ全体のクリーンアップ/初期化に時間を費やすこともありません。このような最適化から得られるパフォーマンス上の利点は非常に大きいため、部分ページ・ナビゲーションは可能なかぎり有効にしてください。

この機能には次のような既知の制限があります。

  • ドキュメントのmetaContainerファセット(HEADセクション)については、スクリプトのみが新しいページに引き継がれます。アイコン・リンクやスタイル規則などのその他のコンテンツは無視されることがあります。

  • アプリケーション独自の目的でアンカー(ハッシュ)URLを使用することはできません。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の部分ページ・ナビゲーションの使用に関する項を参照してください。

ページ・テンプレートを使用します。

ページ・テンプレートとは、開発者がデータ・バインドされた再利用可能なテンプレートを作成して、これを任意のページのシェルとして使用できる機能です。開発者は、Webページを作成する他の開発者に構成を伝えて一貫性を確保するためのテンプレートを1つ以上作成できます。テンプレートには、使用時に変更できない静的領域と、開発者が作成中のページ固有のコンテンツを配置できる動的領域があります。

テンプレートを使用する際の重要な考慮事項を次に示します。

  • テンプレートはすべてのアプリケーション・ページで使用されるため、共通のパフォーマンスへの影響が発生しないよう最適化する必要があります。たとえば、テンプレートに丸い角を追加すると、すべてのページのパフォーマンスに影響が出る可能性があります。

  • 複雑なテンプレートを作成する場合は、複数の部分に分けて作成したテンプレートを<f:subview>タグを使用してトップレベルのテンプレートに含めることは避けます。パフォーマンスの点から見ると、この方法はサーバー側のメモリー使用率に影響を与えます。<f:subview>を使用すると、IDのスコープ階層にレベルがもう1つ追加されるため、IDが長くなります。長いIDは、パフォーマンスに悪影響を与えます。必要のないかぎり、<f:subview>を使用することは避けてください。すべてのIDが一意であることを保証できる場合は、<jsp:include><f:subview>で囲む必要はありません。たとえば、<jsp:include>を使用する場合は、大きなページを複数の部分に分割して編集しやすくします。そして、<f:subview>を使用することは可能なかぎり避けます。他の人が開発したコンテンツを組み込む場合は、その開発者が使用したIDが不明であれば<f:subview>を使用します。また、領域定義の先頭に<f:subview>を置く必要はありません。

  • どのような場合も(特に、pageTemplate、subview、subformと表または表内では)長いIDは避けてください。長いIDは、サーバー側、ネットワーク・トラフィックおよびクライアント処理のパフォーマンスに影響を与える可能性があります。

ADF Rich Clientのジオメトリ管理を有効にします。

ADF Rich Clientは、親コンポーネントが明示的にUIに含められているブラウザ・レイアウトのジオメトリ管理をサポートしています。子コンポーネントは、ブラウザの使用可能領域いっぱいまで広がるようサイズ設定されます。この機能を使用するとUIの見栄えはよくなりますが、コストが発生します。影響が出るのはクライアント側です。これは、ブラウザがコンポーネントのサイズを変更するのに時間がかかるためです。デフォルトでジオメトリ管理の対象となるコンポーネントは次のとおりです。

  • PanelGridLayout

  • panelAccordion

  • panelStretchLayout

  • panelTabbed

  • breadCrumbs

  • navigationPane

  • panelSplitter

  • toolbar

  • toolbox

  • table

  • train

注意:

  • スタンプされないコンポーネント用にページ・レイアウトを設計する場合、HTML階層をフラット化し、パフォーマンスを向上させるために、panelGridLayoutの使用を検討してください。panelGridLayoutはJavaScriptを使用してPSLのようなページ・レイアウトを実現しますが、JSレイアウト・コンポーネントをネストするオーバーヘッドはありません。

    パフォーマンスの低下を避けるために、スタンプされたコンポーネントではPanelGridLayoutを使用しないでください。

  • ジオメトリ管理を使用する際には、ジオメトリ管理された親コンポーネントに属する子コンポーネントの数を最小限に抑えてください。

  • ジオメトリ管理のコストは、子コンポーネントの複雑さに直接関係しています。

  • 表データのストリーミングを使用している場合、表またはその他のデータがスタンプ設定されたコンポーネントを含むページでは、ジオメトリ管理のパフォーマンス・コストが(ユーザーから見て)小さくなることがあります。クライアント側のジオメトリ管理は、ブラウザがサーバーからのデータ・レスポンスを待っている間に実行できるためです。

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開発者ガイド』を参照してください)。

クロスコンポーネント・リフレッシュを使用する場合は、部分ターゲットと部分トリガーの違いに注意することが必要です。部分トリガーは、コンポーネントが別のコンポーネントでの変更をリスニングする際に使用します。部分ターゲットは、変更を行うコンポーネントで、ページ上の別のコンポーネントの再レンダリングが確実に行われるようにする場合に使用します。

ページにaf:inputTextコンポーネント、af:commandButtonコンポーネントおよびaf:outputTextコンポーネントが含まれているという、よくある状況を考えてみます。ユーザーがaf:inputTextの値を入力し、af:commandButtonをクリックすると、入力値がaf:outputTextに反映されます。PPRを使用しないと、af:commandButtonのクリックによってページ全体のリフレッシュがトリガーされます。PPRを使用すれば、リフレッシュの範囲をリフレッシュ対象のコンポーネント(この場合はaf:outputTextコンポーネント)のみに制限できます。そのためには、次の2つの作業を行います。

  • partialSubmit属性をtrueに設定し、部分送信用のaf:commandButtonを設定します。こうすると、コマンド・コンポーネントをクリックするたびに、部分ページ・リクエストがトリガーされるようになります。

  • 各コンポーネントのpartialTriggers属性を、リフレッシュをトリガーするコンポーネントのIDに設定し、部分送信が発生したときにリフレッシュするコンポーネント(この例ではaf:outputTextコンポーネント)を定義します。この例では、af:outputTextコンポーネントのpartialTriggers属性を、af:commandButtonコンポーネントのIDに設定します。

前述の手順により、コマンド・ボタンを使用して部分ページ・リフレッシュをトリガーする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に設定してください。

注意: JSPエラーIllegalStateExceptionが発生する場合があるため、このパラメータを1に設定することはWebCenter PortalまたはWebCenter Portal Frameworkアプリケーションではお薦めしません。たとえば、WebCenter PortalおよびWebCenter Framework Portalアプリケーションの両方では、JSFビュー・ツリーの直前の状態を格納する必要があることを示唆するダイアログ・ウィンドウが起動されます。数が1に設定されている場合、現在のメイン・ビュー・ページが格納され、たとえばメールを表示する際にダイアログ・ページが表示されます。そのダイアログ・ページは(応答または転送のために)別のダイアログ・ページを開こうとしますが、サーバーは直前のページの状態を保存できずIllegalStateExceptionを返します。

af:resourceコンポーネントを使用してcssスクリプトおよびjsスクリプトを配信します。

開発者が共通して行う作業の1つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読み取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスをより向上させるために、af:resourceコンポーネントを使用してcssスクリプトおよびjsスクリプトを配信します。

HTMLページは基本的に、ヘッダーと本文の2つの部分からなります。ページにaf:documentコンポーネントを配置すると、このコンポーネントからページのヘッダーおよび本文が自動的に作成されます。af:documentの子コンポーネントは、ページの本文の部分に属します。ヘッダーに表示されるコンポーネント(または静的なCDATAコンテンツ)を取得するには、metaContainerファセットを使用します。

ヘッダーに表示されるコンポーネント(または静的な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>

ページ・テンプレートを使用する場合は、テンプレート定義にaf:documentおよびaf:formを含めることを検討してください。そして、これらのタグでカスタマイズするものを、ページ・テンプレート属性およびページ・テンプレートaf:facetRefを使用して公開してください。そうすれば、前述のようなテンプレート固有のスタイルが指定されている場合に、そのテンプレートでmetaContainerファセットを利用できるようになります。また、使用状況ページでは、各ページで同じドキュメント・タグおよびフォーム・タグを繰り返す必要はありません。

af:facetRefの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

カスタムJavaScriptコードを最適化します。

ADF Rich Clientは、クライアント側でJavaScriptを使用します。必要な機能のほとんどはフレームワークそのものに組み込まれています。しかし、カスタムJavaScriptコードの記述が必要になる場合もあります。最適なパフォーマンスを得るには、JavaScriptコードを1つのJS lib (1つのJavaScriptファイル)にまとめてクライアントに配布することを検討してください。最も簡単な方法は、ADFタグ<af:resource type="javascript" source=" "/>を使用することです。

ほとんどのページでカスタムJavaScriptコードが必要になる場合は、このタグをアプリケーション・テンプレートに含めてください。それ以外の場合は、特定のページのみに含めることでパフォーマンスを改善できます。カスタムJavaScriptコードのlibファイルが大きくなりすぎた場合は、意味のある単位に分割して、ページに必要な部分のみを含めます。この方法では、ブラウザ・キャッシュが使用され、ページのHTMLコンテンツが小さくなるため、全体として見れば高速になります。

デバッグ出力モードを無効にします。

trinidad-config.xmlファイルのdebug-output要素は、デバッグに役立つ冗長モードでの出力を行うかどうかを示します。TRUEに設定すると、Trinidadの出力デバッグ・メカニズムにより、整形されたコメント付きのHTMLコンテンツが生成されます。出力サイズを小さくしてパフォーマンスを改善するために、本番環境ではデバッグ出力モードを無効にしてください。

debug-output要素をFALSEに設定するか、必要に応じてtrinidad-config.xmlファイルから完全に削除します。

テストの自動化を無効にします。

テスト自動化パラメータoracle.adf.view.rich.automation.ENABLEDを有効にすると、ページ上のすべてのコンポーネントに対してクライアント・コンポーネントが生成され、パフォーマンスに悪影響を与えることがあります。

パフォーマンスを改善するには、web.xmlファイルでoracle.adf.view.rich.automation.ENABLEDパラメータの値をFALSE(デフォルト値)に設定します。

アニメーションを無効にします。

ADF Rich Clientフレームワークでは、クライアント側のアニメーションがデフォルトで有効になっています。アニメーションは、高度なユーザー体験を提供する目的で使用されます。ポップアップ表など、一部のコンポーネントには、一部の操作に対応するアニメーション・セットが用意されています。アニメーションを使用するとユーザー体験を改善できますが、アクションを実行したときのレスポンス時間が長くなる可能性があります。速度が最大の懸念事項である場合は、trinidad-config.xmlにフラグを設定してアニメーションを無効にしてもかまいません。

クライアント側のアサーションを無効にします。

クライアント側のコード・ベースに対するアサーションは、クライアント側のパフォーマンスに大きな影響を与えることがあります。クライアント側のアサーションを無効にするには、パラメータの値をFALSE(デフォルト値)に設定します。また、web.xmlファイルでoracle.adf.view.rich.ASSERT_ENABLEDが明示的にTRUEに設定されていないことも確認してください。

JavaScriptのプロファイラを無効にします。

JavaScriptのoracle.adf.view.rich.profiler.ENABLEDプロファイラを有効にすると、プロファイラ・データをフェッチするための余分なラウンドトリップがすべてのページで発生します。この余分なラウンドトリップを回避するには、web.xmlファイルでプロファイラを無効にします。デフォルトはDISABLEDです。

リソース・デバッグ・モードを無効にします。

リソース・デバッグ・モードを有効にすると、ブラウザ(またはWebCache)はリソース(JSライブラリ、CSSスタイルシート、イメージなど)がキャッシュ可能であることをHTTPレスポンス・ヘッダーから判断できません。

キャッシュを確実に有効にするには、web.xmlファイルでorg.apache.myfaces.trinidad.resource.DEBUGパラメータを無効にします。

タイムスタンプのチェックを無効にします。

org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONパラメータは、jspファイルまたはjspxファイルにアクセスするたびに、これらのファイルの変更をチェックするかどうかを制御します。

web.xmlファイルでorg.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONパラメータの値がFALSE(デフォルト値)に設定されていることを確認してください。

CSSファイルの変更のチェックを無効にします。

org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATIONパラメータは、CSSファイルの変更のチェックを行うタイミングを制御します。パフォーマンスを確保するために、この構成オプションはデフォルトでfalse (CSSファイルの変更をチェックしない)に設定されています。サーバーの停止および起動を行わずに、スキンのCSSファイルへの変更を反映するには、これをTRUEに設定します。

コンテンツの圧縮を有効にします。

デフォルトでは、レンダリングされたスタイル・クラスは、ページ・サイズを小さくするために圧縮されます。本番環境では、必ずDISABLE_CONTENT_COMPRESSIONパラメータをweb.xmlファイルから削除するか、FALSEに設定してください。

デバッグの際には、スタイル・クラスのコンテンツの圧縮をオフにします。そのためには、DISABLE_CONTENT_COMPRESSIONプロパティをTRUEに設定します。

JavaScriptの曖昧化を有効にします。

ADF Facesは、曖昧化されていないJavaScriptライブラリを提供するためのランタイム・オプションをサポートしています。デフォルトでは曖昧化されたバージョンが提供されますが、開発ビルド用に曖昧化されていないバージョンも提供されます。曖昧化を行うと、JavaScriptライブラリ全体のサイズが約50%削減されます。

曖昧化されたADF Facesビルドを提供するには、web.xmlファイルでorg.apache.myfaces.trinidad.DEBUG_JAVASCRIPTパラメータをFALSEに設定します。

Firebugが有効なFirefoxを使用して、コードが曖昧化されていることを確認するには、2つの方法があります。

ダウンロード・サイズの確認:

  1. 「接続」タブで「すべて」または「JS」が選択されていることを確認します。

  2. all-11-version.jsエントリを見つけます。

  3. 列のサイズを確認します。(2.8MBではなく)約1.3MBになっているはずです。

ソースの確認:

  1. 「スクリプト」タブで、タブの上にあるドロップダウン・メニューからall-11-version.jsを選択します。

  2. コードを確認します。コメントや長い変数名がある場合、ライブラリは曖昧化されていません。

    注意: 著作権を示すコメントは、曖昧化されたJSファイルでも保持されます。

ライブラリのパーティション化を有効にします。

Oracle 11g リリースでは、ライブラリのパーティション化がデフォルトでオンになっています。旧バージョンでは、ライブラリのパーティション化はデフォルトでオフになっていました。ライブラリのパーティション化がオンになっていることを確認してください。そのためには、web.xmlファイルでoracle.adf.view.rich.libraryPartitioning.DISABLEDプロパティがfalseに設定されていることを確認します。


8.2.3 ADF Facesコンポーネント属性のチューニング

表8-3に、ADF Facesコンポーネント属性の構成に関する推奨事項を示します。

表8-3 ADF Facesコンポーネント属性

構成に関する推奨事項 説明

immediate属性を使用します。

ADF Rich Clientのコンポーネントにはimmediate属性があります。コンポーネントのimmediate属性がTRUEに設定されている場合(immediate="true")、そのコンポーネントに関連する検証、変換およびイベントはapplyRequestValuesフェーズで処理されます。immediateTRUEに設定すると、パフォーマンスが向上する場合があります。

  • navigationPane内のcommandNavigationItemに対してimmediate属性をTRUEに設定すると、新しいページへの移動中に現在の画面からデータが処理されるのを回避できます。

  • 入力コンポーネントの値を他の値より先に検証する必要がある場合は、immediateTRUEに設定してください。エラーが発生した場合に、それがサイクルの早い段階で検出されるため、余分な処理を行わずに済みます。

ADF Rich ClientはJSFをベースとし、標準のJSFライフサイクルを採用しています。『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のJSFおよびADF Facesのライフサイクルの理解に関する項を参照してください。

immediate属性については、重要な問題がいくつかあります。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のimmediate属性の使用に関する項を参照してください。

これは高度な機能であることに注意してください。パフォーマンス向上効果のほとんどは、af:subformコンポーネントを使用すれば得られます。af:subformの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』を参照してください。

visible属性およびrendered属性を使用します。

ADF Faces Rich Clientのすべての表示コンポーネントには、ページへのコンポーネントの表示方法を指定する2つのプロパティがあります。

  • visibleプロパティは、コンポーネントをページに表示するか、非表示にするかを示します。

  • renderedプロパティは、コンポーネントをクライアント・ページに存在させるかどうかを示します。

通常、これらのプロパティを制御するにはEL式を使用します。パフォーマンスを高めるために、クライアントがコンポーネントとやり取りしない場合は、コンポーネントが(非表示ではなく)レンダリングされないように設定することを検討してください。コンポーネントがレンダリングされないようにすると、そのコンポーネントはクライアント側での表現を持たなくなるため、サーバーのパフォーマンスおよびクライアントのレスポンス時間が改善されます。

クライアント側イベントを使用します。

ADF Rich Clientフレームワークは、DOMレベルではなくコンポーネントレベルのイベントに基づいたクライアント側イベント・モデルを提供します。クライアント側イベント・モデルは、アプリケーションの高速化が可能な、非常に便利な機能です。パフォーマンスに関する次の考慮事項を確認してください。

  • クライアント側で実行できる比較的単純なイベント処理には、クライアント側イベントを使用することを検討してください。そうすることで、サーバーへのラウンドトリップ数が減少するため、クライアント側のパフォーマンスが向上します。また、リクエストをサーバーで処理する必要がなくなり、サーバー側のスループットおよびスケーラビリティも向上します。

  • デフォルトでは、クライアント・コンポーネントによってクライアントで生成されるイベントはサーバーに伝播されます。クライアント側イベント・ハンドラが提供される場合は、イベントがサーバーに伝播されないよう、処理の最後にイベントを取り消すことを検討してください。

id属性を使用します。

id属性は、長さが7文字を超えないようにしてください。このことは、ネーミング・コンテナにとって特に重要です。クライアントに送信する必要のあるHTMLの量はIDの長さの影響を受けるため、IDが長いとパフォーマンスに影響が出ます。

クライアント側コンポーネントを使用します。

ADF Rich Clientフレームワークは、クライアント側イベントの処理およびコンポーネントの動作において一定の役割を果すクライアント側コンポーネントを備えています。クライアント側コンポーネントを生成するタイミング(あるいは、生成するかどうか)を構成するには、clientComponent属性を使用します。clientComponent属性をTRUEに設定すると、パフォーマンスに影響が出るため、クライアント側コンポーネントの生成が必要かどうかを判断してください。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』のクライアント側コンポーネントに関する項を参照してください。

af:popupchildCreation属性をdeferredに設定して、サーバー側のパフォーマンスを強化します。

childCreationdeferredに設定すると、コンテンツが配信されるまで、ポップアップでのコンポーネントの構成が延期されます。したがって、deferredを設定することで、サーバー側の状態のフットプリントを削減できる場合があります。

注意: この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。

  • f:attribute

  • af:setPropertyListener

  • af:clientListener

  • af:serverListener

また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。


8.2.4 tableコンポーネントおよびtreeコンポーネントのパフォーマンスに関する考慮事項

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式#{bindings.<name>.rangeSize}に設定されており、イテレータ・サイズと同一です。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』の表およびツリーの使用に関する項を参照してください。

列の拡大を無効にします。

tableコンポーネントおよびtreeTableコンポーネントの列は、最後の列の端とtableコンポーネントまたはtreeTableコンポーネントの輪郭との間に未使用の領域が残らないよう、拡大することができます。この機能は、パフォーマンスに影響を与える可能性があるため、デフォルトでオフになっています。この機能をオンにすると、クライアントのレンダリング時間に影響が出ることがあります。したがって、この機能を複雑な表に対して有効にするときは十分に注意してください。

ヘッダー行および固定列は必要な場合にのみ使用することを検討します。

tableコンポーネントには、行ヘッダーおよび固定列を設定できる機能があります。これらのオプションを使用すると、優れたデザインのインタフェースを作成でき、ユーザー体験も向上します。ただし、クライアント側のパフォーマンスに影響が出る可能性があります。tableコンポーネントで最適なパフォーマンスを得るには、これらのオプションを必要な場合にのみ使用します。

ユーザーが表示できないポップアップを無効にします。

ほとんどのセルには、最初は添付ファイルがなく、ユーザーが表示できるポップアップは1つのみです。したがって、ユーザーが表示できないポップアップには、renderer="false"を設定します。このように、ブラウザに送信される不要なDOMおよびクライアント・コンポーネントを削減します。同様に、DOMには、空のセルの数を指定したpanelGroupLayoutを設定します。空のセルのDOMを送信する必要はありません。


8.2.5 autoSuggestのパフォーマンスに関する考慮事項

autoSuggestは、inputText、inputListOfValues、inputComboboxListOfValuesの各コンポーネントに対して有効にできる機能です。ユーザーが入力フィールドに文字を入力すると、コンポーネントは候補となる項目のリストを表示します。この機能により、データベース表で問合せが実行され、結果がフィルタ処理されます。データベース処理を高速化するために、autoSuggestが有効になっている列にデータベース索引を作成してください。そうすることで、特にデータベース表の行数が多い場合に、コンポーネントのレスポンス時間が改善されます。

8.2.6 データ配信 - 遅延配信と即時配信

table、tree、その他のスタンプ設定されたコンポーネントのデータは、遅延配信または即時配信が可能です。デフォルトでは、遅延配信が使用されます。つまり、サーバーからの最初のレスポンスではデータは配信されません。初期ページがレンダリングされた後、クライアントがサーバーにデータを要求し、2番目のリクエストへのレスポンスとしてデータを取得します。

即時配信の場合は、ページ・リクエストへのレスポンスと同時にデータを取得できます。データ配信が行われるのはコンポーネントごとであり、ページごとではないので注意してください。つまり、この2つを同じページ上に混在させることが可能です。

この2つのオプションから選択する際には、次の点を考慮してください。

遅延配信(デフォルト)

遅延配信は、表やフェッチ時間の遅いスタンプ設定された他のコンポーネントに使用する必要があります。たとえば、スタンプ設定されたコンポーネントがWebサービス呼出しを使用したデータ・コントロールや遅いデータ・フェッチの他のデータ・コントロールに基づく場合です。ユーザーが下にスクロールしないとすぐに内容が表示されないページにも遅延配信を使用できます。この場合、クライアントに表示されるコンテキストの配信時間が短くなり、ユーザーがパフォーマンスの向上を認識します。

遅延配信は、データ・ストリーミング技術を使用して実現されます。この方式が優れているのは、サーバーがデータ・フェッチを並行して実行し、データが使用可能になると同時に、そのデータをクライアントへストリーミング配信することが可能な点です。この方式は、ページに表が2つあり、一方の表ではデータがごく短時間で返され、もう一方の表ではデータが返されるまで長時間かかるといった場合に、高い効果を発揮します。高速な表のデータは、取得されると同時にユーザーに対して表示されます。

注意: 遅延配信を使用する際は、データが利用可能であるかどうかを最初に判断するためにwhenAvailableの使用を検討してください。利用可能でない場合はレンダリングします。

また、並行してデータ・フェッチを実行すると、データ・フェッチの合計時間が短縮されます。これは、複数の遅くなる可能性のあるデータ・フェッチの遅延ロードに利点があります。ストリーミングは遅延モードのデータ配信のデフォルト・メカニズムですが、データ・コントロールのパラレル実行はそうではありません。パラレル実行を有効にするには、ページ定義を開いて、イテレータのRenderHintbackgroundに変更します。

場合によっては、パラレル実行のレスポンス時間が短縮される利点があります。パラレル実行では並行してリクエストを実行する複数のスレッドのために多くのリソースを使用する可能性があり、開くデータベース接続が多くなる場合があります。

ページに複数の遅いコンポーネントが存在し、スタンプ設定されたコンポーネントが異なるデータ・コントロール・フレーム(分離したタスクフローなど)に属する場合のみ、パラレル実行を使用することを検討してください。パラレル実行がデータ・コントロール・フレーム・レベルで同期化するため、単一のデータ・コントロール・フレームのパラレル実行ではパフォーマンスが改善しない場合があります。

即時配信

即時配信(contentDelivery="immediate")を使用するのは、表データ・コントロールが高速な場合、または小さいデータ・セットを返す場合です。このような場合には、遅延配信を使用するよりレスポンス時間が短くなります。

即時配信のもう1つの利点は、遅延配信に比べてサーバー・リソースの使用率が低いことです。即時配信では、サーバーに送信されるリクエストは1つのみなので、特定のユーザー・インタラクションにおけるCPUおよびメモリーの使用率が低下します。


8.2.7 DVTコンポーネントのパフォーマンスに関する考慮事項

DVTコンポーネントは、ADF Rich Clientコンポーネントをベースとするデータ視覚化コンポーネントです。DVTコンポーネントには、グラフ、ゲージ、ガント・チャート、ピボット・テーブル、マップなどがあります。表8-5に、DVTコンポーネントの構成に関する推奨事項を示します。

表8-5 DVTコンポーネントの構成

構成に関する推奨事項 説明

RangeSize属性を使用します。

RangeSize属性は、同時に返す行の数を定義します。RangeSizeに値-1を指定すると、イテレータはすべての行を返します。小さい値を使用すればパフォーマンスは向上しますが、データを止めるのが難しくなる場合があります。また、rangeSizeを超えるデータはビューに表示されません。

縦方向のテキストではなく横方向のテキストを使用します。

デフォルトでは、ピボット・テーブルの列ヘッダーとして横方向のテキストが使用されます。ただし、縦方向のテキストを使用するオプションもあります。縦方向のテキストを使用するには、ヘッダー・フォーマットとして次のようなCSSスタイルを指定します。

writing-mode:tb-rl;filter:flipV flipH;

縦方向のテキストのほうが見栄えがよいこともありますが、Firefoxブラウザを使用する場合はパフォーマンスに影響が出ます。

問題なのは、FirefoxがInternet Explorerのように縦方向のテキストに対応していないことです。縦方向のテキストを表示するために、ピボット・テーブルではGaugeServletによって生成されたイメージが使用されます。テキストは動的で、バインディング値に依存しているので、このイメージをキャッシュすることはできません。そのため、ピボット・テーブルをレンダリングするたびに、イメージをフェッチする目的でサーバーへの余分なラウンドトリップが発生し、ネットワーク・トラフィック、サーバーのメモリーおよびCPUに影響を与えます。

最適なパフォーマンスを得るには、縦方向のテキストではなく横方向のテキストを使用することを検討してください。


8.3 チューニングに関する高度な考慮事項

前の項で推奨されているチューニングの変更を行った後、ADFサーバー・デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。

8.3.1 ADFサーバーのパフォーマンス

Oracle ADFサーバー・コンポーネントは、ADF内のUI以外のコンポーネントからなります。これには、モデル・レイヤーのADF実装(ADFm)、ビジネス・サービス・レイヤーのADF実装(ADFbc)、およびコントローラ・レイヤーのADF実装(ADFc)が含まれます。サーバー・コンポーネントは自由に構成できますが、重要なのは、指定したアプリケーション・パフォーマンスおよび機能を備える使用可能リソースに最適な構成の組合せを選択することです。

8.3.1.1 HTTPセッション・タイムアウトのチューニング

重要なユーザー・コミュニティを持つADFアプリケーションの場合、デフォルトのHTTPセッション・タイムアウトの45分を使用すると、期限切れを待機しているセッションによって保持されるメモリー量がパフォーマンスに悪影響を与えることがあります。保持されるメモリーは物理的に使用可能な量より大きくなる可能性があり、サーバーは負荷を処理できなくなります。公開Webサイトを使用しているユーザーなど、ユーザー数が多い場合は、セッション・タイムアウトをできるだけ短くする必要があります。

パフォーマンスを向上させるには、web.xmlファイルでセッション・タイムアウトのデフォルト値(分単位)を変更することを検討してください。ユースケース・シナリオで機能するセッション・タイムアウト値を使用します。次の例は、10分のセッション・タイムアウトを示しています。

<session-config>
 <session-timeout>
 10
 </session-timeout>
</session-config>

8.3.1.2 ビュー・オブジェクトのチューニング

ビュー・オブジェクト(VO)にはチューニング・オプションが数多く用意されているため、開発者はアプリケーション固有のニーズに合せてビュー・オブジェクトをカスタマイズできます。ビュー・オブジェクトは、機能要件を満たすのに必要な最小限の機能セットを使用するよう構成してください。ビュー・オブジェクトのチューニングについては、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』に詳しい説明があります。ここでは、ビュー・オブジェクトのパフォーマンスに関するヒントをいくつか示します。

8.3.1.2.1 ビュー・オブジェクトの作成

ビュー・オブジェクトのパフォーマンスを最大化するには、ビュー・オブジェクトを目的の用途に合致させる必要があります。たとえば、値リストのピックリスト用に取得されたデータは読取り専用であるのが一般的です。したがって、このデータを問い合せるには、読取り専用のビュー・オブジェクトを使用します。ビュー・オブジェクトをアプリケーション固有のニーズに合せてカスタマイズすると、パフォーマンス、メモリー使用率、CPU使用率およびネットワーク使用率を改善できます。

ビュー・オブジェクトのタイプ 説明

読取り専用のビュー・オブジェクト

ビュー・オブジェクトがデータの挿入や更新を行う必要がない場合は、読取り専用のビュー・オブジェクトの使用を検討してください。読取り専用のビュー・オブジェクトには2つの種類があります。

  • 更新不可能なEOベースのビュー・オブジェクト

  • エキスパートモードのビュー・オブジェクト

更新不可能なEOベースのビュー・オブジェクトには、カスタマイズ可能な選択リストによってUIで必要とされる属性を実行時に取得できる、ローカル・キャッシュからデータを読み取ることができる(データベース問合せの再実行が不要)、同じEOに基づいた他の更新可能なビュー・オブジェクトとの間でデータの一貫性を確保できる、といった利点があります。

エキスパートモードのビュー・オブジェクトには、EOがサポートしていないSQL操作を実行し、ビュー・オブジェクトとEOの行の連携によって発生するパフォーマンスへのわずかな影響を回避するという機能があります。EOベースのビュー・オブジェクトに対して選択したEOでupdatableオプションを選択解除すると、そのビュー・オブジェクトは更新不可能としてマークされます。また、ビュー・オブジェクトのXML定義でEntityUsage属性にパラメータReadOnly="true"を追加するという方法でも同じことができます。

挿入専用のビュー・オブジェクト

レコードを挿入する目的でのみ使用されるビュー・オブジェクトの場合、そのビュー・オブジェクトを使用する際に不要なSELECT問合せが実行されるのを防ぐことができます。そのためには、「ビュー・オブジェクトの概要」タブの「データベースから取得」グループ・ボックスでオプション「行なし」を設定します。これで、ビュー・オブジェクト定義のMaxFetchSizeが0(ゼロ)に設定されます。

実行時に作成されるビュー・オブジェクト

AMでcreateViewObjectFromQueryStmt() APIを使用すると、ビュー・オブジェクトを実行時に作成できます。ただし、パフォーマンスに影響が出る可能性があり、チューニングも複雑になるため、実行時に作成されるビュー・オブジェクトを使用するのは絶対に必要でないかぎり避けてください。


8.3.1.2.2 ビュー・オブジェクトによるデータ・フェッチの構成

ビュー・オブジェクトのパフォーマンスは、ビュー・オブジェクトによるデータ・フェッチがどのように構成されているかによって大きく変わります。フェッチ・オプションがアプリケーションに対して正しくチューニングされていないと、ビュー・オブジェクトが必要以上のデータをフェッチしたり、データベースへのラウンドトリップの回数が多くなりすぎたりする可能性があります。フェッチ・オプションは、図8-1に示した「ビュー・オブジェクト」ダイアログの「データベースから取得」グループ・ボックスで構成できます。

図8-1 「ビュー・オブジェクト」ダイアログ

図8-1の説明が続きます
「図8-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)をプログラム的にコールします。順方向専用に設定すれば、データ・セットのトラバースの際に前の行セットがキャッシュされるのを防ぐこともできます。


8.3.1.2.3 ビュー・オブジェクトのその他の構成

表8-6に、ビュー・オブジェクト使用時のチューニングに関するその他の考慮事項を示します。

表8-6 ビュー・オブジェクトのその他の構成

構成に関する推奨事項 説明

大きなデータ・セットを最適化します。

ビュー・オブジェクトは、ユーザーが結果の特定のページにジャンプできるように、大きなデータ・セット内でページ移動するメカニズムを備えています。これを構成するには、ビュー・オブジェクトに対してsetRangeSize(N)setAccessMode(RowSet.RANGE_PAGING)の順にコールします。Nは、1ページに含める行数です。データ・セット内の特定のページに移動する場合は、ビュー・オブジェクトに対してscrollToRangePage(P)をコールするとページPに移動できます。範囲ページングでは、現在のページの行のみがフェッチされて、ビュー・オブジェクトの行キャッシュに入れられるため、1ページのデータを取得するたびに問合せ実行のコストがかかります。範囲ページングは、すべての行をフェッチしてビュー・オブジェクトの行キャッシュに入れるほうが有利な場合には適していません(たとえば、データ・セットのすべての行を読み取ってLOVを生成したり、小さいデータ・セットのレコードを前後にページ移動したりする必要がある場合です)。

可能であればスピルオーバー構成を無効にします。

JVMコンテナのメモリーが不足した場合は、データ・ソースを仮想メモリーとして使用できます。デフォルトでは、この機能は無効になっていますが、(必要な場合は)jbo.use.pers.coll=trueと設定することで有効にできます。パフォーマンスに影響を与えることのないよう、このオプションは(可能であれば)無効にしてください。

SQLスタイルの構成を確認します。

SQL92準拠の汎用データベースにSQL92の汎用SQLスタイルを使用して接続する場合は、ビュー・オブジェクトの一部のチューニング・オプションが適用されません。ビュー・オブジェクトのフェッチ・サイズは、そのようなチューニング・オプションの1つです。SQL92のSQLスタイルを使用した場合、ビュー・オブジェクトの構成にかかわらず、フェッチ・サイズはデフォルトで10行に設定されます。SQLスタイルは、データベース接続の定義時に設定されます。デフォルトでは、Oracleデータベース接続を定義する際のSQLスタイルはOracleです。SQLスタイルを手動でオーバーライドするには、起動時にパラメータ-Djbo.SQLBuilder="SQL92"をJVMに渡します。

ビュー・オブジェクトの問合せにバインド変数を使用します。

ビュー・オブジェクトに関連付けられた問合せに、実行のたびに変わる可能性のある値が含まれる場合は、バインド変数の使用を検討してください。そうすることで、データベースへの問合せを再解析する必要がなくなります。バインド変数は、ビュー・オブジェクト定義の「問合せ」セクションでビュー・オブジェクトに追加できます。

ビュー・オブジェクトの問合せに問合せオプティマイザ・ヒントを使用します。

ビュー・オブジェクトからデータベースにヒントを渡して、関連する問合せで使用される実行計画に影響を与えることができます。オプティマイザ・ヒントは、「データベースから取得」グループ・ボックスで指定できます。

動的SQL生成を使用します。

ビュー・オブジェクトは、設計時にSQL文を定義するかわりに、実行時にSQLを動的に生成するよう構成できます。ビュー・オブジェクト・インスタンスがSQL文を動的に生成するように構成されていれば、データベースへの再問合せが不要になります。この効果は、ページ・ナビゲーションの際に、同じキー・エンティティ・オブジェクト・リストを持つすべての属性のサブセットが後続のページ・ナビゲーションで使用される場合に、特に大きくなります。必要なすべての属性のスーパーセットを有効にすると、後続の問合せを実行する必要がなくなり、パフォーマンスが向上します。


8.3.1.3 バッチ処理

バッチ処理とは、操作をデータベースへ送信する際に、複数の挿入、更新および削除をまとめて処理できる機能です。この機能をエンティティ・オブジェクト(EO)に対して有効にするには、EOの「一般」タブの「チューニング」セクションで「バッチ更新を使用」チェック・ボックスを選択するか、EOのXMLファイルを直接変更して、バッチ・サイズを指定したパラメータBatchThresholdEntity属性に追加します。

BatchThresholdの値は、操作を一度に1つずつ実行するかわりに、複数の操作のグループをバッチにまとめるかどうかの基準となるしきい値です。しきい値に達しない場合、行は一度に1つずつ処理されます。一方、しきい値を超える数の行は、単一のバッチにまとめることができます。

挿入後にリフレッシュする(RetrievedOnInsert="true")、または更新後にリフレッシュする(RetrievedOnUpdate="true")よう構成されたEOの属性が存在する場合、EOのBatchThreshold構成は共存できませんので注意してください。

8.3.1.4 RangeSizeのチューニング

このパラメータは、ADFmがBCレイヤーから同時にリクエストするレコードの数を制御します。デフォルトのRangeSizeは25レコードです。この値を、ビュー・オブジェクトのUIに同時に表示するレコードの数に設定して、モデルとBCレイヤーの間のラウンドトリップ回数を1回に減らすことを検討してください。これは、対応するページのページ定義XMLのIterator属性で構成します。

8.3.1.5 アプリケーション・モジュールの設計に関する考慮事項

アプリケーション・モジュールの粒度の設計は、パフォーマンスおよびスケーラビリティに大きな影響を与える重要な考慮事項です。各ルート・アプリケーション・モジュールは通常、専用のデータベース接続を保持していることに注意してください。ユーザー・セッションが複数のルート・アプリケーション・モジュールを消費する場合、そのユーザー・セッションは同時に複数のデータベース接続を保持している可能性があります。このような状況は、アプリケーション・モジュールとユーザー・セッションの間で全般的なアフィニティが維持されるために、接続が実際には使用されていない場合でも発生します。ユーザーが同時に複数の接続を保持する可能性を減らすには、次の方法を検討します。

  • ユーザーが必要とする機能をすべて網羅した大きなアプリケーション・モジュールを設計します。

  • 小さなアプリケーション・モジュールを単一のルート・アプリケーション・モジュールの下にネストし、ネストされたアプリケーション・モジュールの間で同じデータベース接続を共有できるようにします。

  • アプリケーション・モジュールで遅延ロードを使用します。アプリケーション・モジュールのチューニング・セクションで、遅延ロードを使用するように実行時のインスタンス化動作をカスタマイズします。遅延ロードは、次のJVM引数を追加して、JVM全体で設定することもできます。

    -Djbo.load.components.lazily=true
    

8.3.1.6 アプリケーション・モジュール・プーリング

アプリケーション・モジュール(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プール・レベルでのチューニングを検討してください。使用頻度の低いプールについては、トップレベルのアプリケーション・パラメータが使用されないように、プール・サイズをプール・レベルでチューニングすることを検討してください。


8.3.1.6.1 AMプールの一般的な構成

次のガイドラインは、AMおよびAMプールの動作をチューニングする際の一般的な出発点として使用してください。メモリー使用率またはCPU使用率の具体的なチューニングについては、第8.3.1.6.2項「AMプール・サイズの構成」を参照してください。

表8-8 AMプールのチューニング・パラメータ

パラメータ 説明

初期プール・サイズ

jbo.ampool.initpoolsize

プールの初期化時に作成するアプリケーション・モジュール・インスタンスの数を指定します(デフォルトはゼロです)。初期プール・サイズをゼロ以外に設定すると、アプリケーションの初期化にかかる時間が増えますが、その後、AMインスタンスを必要とする操作のパフォーマンスは向上します。

この値は、すべてのユーザーへのサービス提供に必要な同時AMインスタンスの予想数より10%多くなるように構成してください。

最大プール・サイズ

jbo.ampool.maxpoolsize

プールで割り当てることのできるアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは4096です)。この制限を超える数のアプリケーション・モジュール・インスタンスは作成できません。一般的なガイドラインとして、この値は、さらなる増加分を見込んで初期プール・サイズより20%大きくなるように構成してください。

最小使用可能サイズ

jbo.ampool.minavailablesize

サーバーの負荷が軽い場合に、リソースのクリーンアップ処理時にプール・モニターがプールに残す必要のある、利用可能なアプリケーション・モジュール・インスタンスの最小数。

リソースのクリーンアップ後にすべてのインスタンスがアイドル・タイムアウトより長い期間アイドルである場合に、プールにインスタンスが1つも含まれないようにするには、0(ゼロ)を設定します。

デフォルト値は、5(インスタンス)です。

アプリケーション・モジュール・プール・チューニングは、jbo.ampool.minavailablesize | jbo.ampool.maxavailablesizeパラメータに対して異なる値を許容しますが、多くの場合、最小と最大のチューニング・プロパティを同じ値に設定して問題ありません。

最大使用可能サイズ

jbo.ampool.maxavailablesize

サーバーに負荷がかかっている場合に利用できるプール内のアプリケーション・モジュール・インスタンスの理想的な最大数。

プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンス・タイムアウトより長い間使用されていないインスタンスは、この時点でクリーンアップされ、このサイズまで使用可能なインスタンス数を下げる必要がある場合は、追加の使用可能なインスタンスが削除されます。

デフォルト値は、25(インスタンス)です。リソース・クリーンアップ後に利用可能にしておきたいインスタンス数の最大数に構成します。一般に、値を低くすると、クリーンアップの際にプールから削除されるアプリケーション・モジュール・インスタンスの数が増えます。

アプリケーション・モジュール・プール・チューニングは、jbo.ampool.maxavailablesize | jbo.ampool.minavailablesizeパラメータに対して異なる値を許容しますが、多くの場合、最小と最大のチューニング・プロパティを同じ値に設定して問題ありません。

参照プール・サイズ

jbo.recyclethreshold

管理状態モードでプールに解放される前に、自身を最後に使用したセッションが次に行うリクエストに備えてセッション・アフィニティを保持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは10です)。

参照されるプール・サイズは常に最大プール・サイズ以下になるようにしてください。そうすれば、設定された数の使用可能インスタンスが、管理状態モードで自身を解放した直近のセッションとのアフィニティに従うようになります。

短い思考時間で複数の操作を行う同時ユーザー数の予想値に構成します。短い思考時間でアプリケーションを使用する予定のユーザーがいない場合は、この値を0(ゼロ)に設定して、アフィニティを解消してもかまいません。

インスタンスの最大有効時間

jbo.ampool.timetolive

この時間(ミリ秒)を超えると、プール内のインスタンス数がminavailablesize未満になるかどうかには関係なく、プール内の接続モジュール・インスタンスが、次のリソース・クリーンアップ時に削除の候補とみなされます。

デフォルト値は3600000ミリ秒(3600秒または1時間)です。値を低くすると、次回のリソース・クリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が短くなります。ほとんどのアプリケーションでは、デフォルト値で十分です。値を高くすると、次回のクリーンアップで削除されるまでにアプリケーション・モジュール・インスタンスが存在できる時間が長くなります。

アイドル・インスタンス・タイムアウト

jbo.ampool.maxinactiveage

この時間(ミリ秒)を超えると、プール内の非アクティブなアプリケーション・モジュール・インスタンスは、次回のリソース・クリーンアップ時に削除の候補とみなされます。

デフォルト値は、600000ミリ秒(600秒または10分)です。値を低くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が増えます。値を高くすると、次回のクリーンアップで削除する候補としてマークされるアプリケーション・モジュール・インスタンスの数が減ります。

プール・ポーリング間隔

jbo.ampool.monitorsleepinterval

プール・リソース・クリーンアップの時間間隔(ミリ秒)。

プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールから削除される候補のインスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。

アプリケーション・モジュール・プール・モニターは、デフォルトでは600000ミリ秒(600秒または10分)ごとにウェイクアップします。短い間隔を構成すると、アクティブでないアプリケーション・モジュール・インスタンスを、メモリーを節約するために削除する頻度が高くなります。大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。

フェイルオーバー

jbo.dofailover

フェイルオーバーを無効にするか有効にするかを指定します。デフォルトでは、フェイルオーバーは無効になっています。フェイルオーバーを有効にするには、このパラメータをtrueに設定します。

注意: アプリケーション・モジュール状態の受動化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。このタイプの障害によって、SQLException (Connection has already been closed)が生成されます。この例外は、サーバー・ログに保存されます。例外は、ユーザー・インタフェースを通してレポートされません。

状態の受動化が発生し、変更が保存されるようにするには、weblogic-application.xmlの<connection-check-params> pool-params要素にあるデプロイメント・ディスクリプタ・パラメータinactive-connection-timeout-secondsに適切な値を設定します。

デプロイメント・ディスクリプタ・パラメータを数分に設定すると、ほとんどの場合、非アクティブな接続のタイムアウトは強制されず、その結果受動化は失敗します。ご使用の環境に合せて、この設定値を調整してください。

ロック・モード

jbo.locking.mode

ロック・モード(optimisticまたはpessimistic)を指定します。デフォルトはpessimisticです。つまり、行レベル・ロックを行うデータベースで保留トランザクション状態が発生する可能性があります。ペシミスティック・ロック・モードの場合、AMがリサイクルされるたびに、JDBC接続でロールバックが発行されます。Webアプリケーションでは、行レベル・ロックが発生しないように、ロック・モードをoptimisticに設定してください。

データベース接続プール

jbo.doconnectionpooling

AMインスタンスがAMプールに戻されたときに、そのAMインスタンスをデータベース接続から切断できるかどうかを指定します。これにより、アプリケーションのAMプールをデータベース接続プールより大きなサイズに設定することができます。デフォルトはfalseです。つまり、AMインスタンスはAMプールに戻されても引き続きデータベース接続を保持できます。trueに設定すると、AMはAMインスタンスがAMプールに戻されたときに、データベース接続をデータベース接続プールに解放できるようになります。AMがデータベース接続から切断されるまでは、そのデータベース接続に対してロールバックを発行して、保留データベース状態を元に戻すことができますので注意してください。

トランザクション切断レベル

jbo.txn.disconnect_level

jbo.doconnectionpooling=trueとともに使用する場合に、JDBC ResultSetを保持するためのBC4Jの動作を指定します。デフォルトではjbo.txn.disconnect_levelは0です。この場合、データベース接続がAMインスタンスから切断されたときに、受動化を使用してオープンしているResultSetをすべてクローズすることができます。jbo.txn.disconnect_levelを1に設定すると、この動作は行われず、前述の状況で受動化のコストが発生することはありません。


システムのメモリーに制約がある場合に構成可能なパラメータについては、表8-9を参照してください。

表8-9 AMプール・サイズの構成 - メモリーに関する考慮事項

パラメータ 説明

初期プール・サイズ

jbo.ampool.initpoolsize

追加のAMインスタンスが必要な場合は、これを小さい値に設定するとメモリーを節約できますが、パフォーマンスの低下というコストが発生します。デフォルト値の0(ゼロ)の場合、AMプールの初期化時にAMインスタンスが作成されません。

最大プール・サイズ

jbo.ampool.maxpoolsize

これを構成すると、AMインスタンスの数が指定の値を超えるのを防止できます。ただし、設定した値が小さすぎると、使用可能なAMインスタンスがない場合に、アプリケーションへのアクセス・エラーが発生することがあります。

最小使用可能プール・サイズ

jbo.ampool.minavailablesize

ゼロ(0)に設定すると、リソース・クリーンアップ後、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。

最大使用可能プール・サイズ

jbo.ampool.maxavailablesize

これを構成すると、リソース・クリーンアップ後に指定した最大数の使用可能インスタンスを残すことができます。


構成するとCPUの負荷をある程度軽減できるパラメータについては、表8-10を参照してください。

表8-10 AMプール・サイズの構成 - CPUに関する考慮事項

パラメータ 説明

jbo.ampool.initpoolsize

この値は、アプリケーション・プールの初期のAMインスタンス数に設定します。初期化時にAMインスタンスを作成する場合、追加のAMインスタンスが必要になったときにオンデマンドで作成するのではなく、初期化時に作成するためのCPU処理コストがかかります。

jbo.recyclethreshold

ユーザーのセッションに対するAMインスタンスのアフィニティを維持するには、この値を設定します。このアフィニティを可能なかぎり維持することで、あるユーザーから別のユーザーへAMインスタンスを切り替える際に必要なCPU処理コストを削減できます。


8.3.1.6.2 AMプール・サイズの構成

アプリケーション・モジュール・プール・サイズの構成は、予想される同時ユーザーの数に大きく依存します。パフォーマンスの問題を防ぐには、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}"

これらのパラメータの構成には、「Oracle WebLogic Server管理コンソール」→「サーバー」→「サーバー名」→「サーバーの起動」→「引数」も使用できます。


注意:

パフォーマンスの影響を制限するには、ampool.maxavailablesizeを各自のユースケース・シナリオで予想される同時ユーザーの最大数よりも少なくとも20%多い値に設定します。


8.3.1.6.3 AMプールのリソース・クリーンアップの構成

次のパラメータは、AMプールのリソース・クリーンアップの頻度および特性に影響を与えます。

システムのメモリーに制約がある場合は、より多くのAMインスタンスをより頻繁にクリーンアップするようAMプールを構成します。そうすることで、AMインスタンスによって消費されるメモリーを解放して、他の目的で使用できるようになります。ただし、使用可能なAMインスタンスの数を減らしてクリーンアップの頻度を高めると、CPU使用率が上昇し、レスポンス時間も長くなる可能性があります。詳細は、表8-11を参照してください。

表8-11 AMプールのリソース・クリーンアップの構成 - メモリーに関する考慮事項

パラメータ 説明

jbo.ampool.minavailablesize

ゼロ(0)に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。

jbo.ampool.maxavailablesize

一般に、値を小さくすると、クリーンアップ時にプールから削除されるAMインスタンスが増加します。

jbo.ampool.timetolive

値を小さくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が短くなります。

jbo.ampool.maxinactiveage

値を小さくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが増加します。

jbo.ampool.monitorsleepinterval

これは、リソース・クリーンアップがトリガーされる頻度を制御します。間隔を短く設定すると、メモリーの節約のために非アクティブのAMインスタンスが削除される頻度が高まります。


AMプールを構成して、より多くのAMインスタンスがより長い期間プール内に存在できるようにすることで、CPU処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。

表8-12 AMプールのリソース・クリーンアップの構成 - CPUに関する考慮事項

パラメータ 説明

jbo.ampool.minavailablesizejbo.ampool.maxavailablesize

これらを大きな値に設定すると、プール内に残されるアイドル・インスタンスが増えるため、後でAMインスタンスを再作成する必要がなくなります。ただし、過度に大きな値を設定して、最大負荷時に必要な数より多くのAMインスタンスを保持することは避けてください。

jbo.ampool.timetolive

値を大きくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が長くなります。

jbo.ampool.maxinactiveage

値を大きくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが減少します。

jbo.ampool.monitorsleepinterval

大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。


8.3.1.7 ADFc: リージョンの使用

ページにリージョンを追加すると、アプリケーションが大きく強化されます。ただし、リージョンはページで大量のリソースを消費するコンポーネントでもあります。パフォーマンスを高めるには、特定の機能が必要とされる場合にのみリージョンの使用を検討してください。

8.3.1.8 タスク・フロー実行の延期

デフォルトでは、ページがロードされると、最初はレンダリングされなくても、タスク・フローはアクティブ化されます。このため、タスク・フローがまったく表示されない場合、不要なオーバーヘッドが発生します。

8.3.1.9 ポップアップのタスク・フロー

デフォルトでは、ポップアップにアクセスしなくても、ポップアップの下に子コンポーネントが作成されます。このオーバーヘッドを回避するには、次のことを検討してください。

  • childCreationをdeferredに設定します。

    ポップアップでchildCreation="deferred"を設定します。

    タスクフローでactivation="deferred"を設定します。


    注意:

    この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。

    • f:attribute

    • af:setPropertyListener

    • af:clientListener

    • af:serverListener

    また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。その場合は、次に説明するように、条件付きアクティブ化を使用します。


  • 条件付きアクティブ化を使用します。

    jsff内のポップアップでプロパティ・リスナーを追加して条件を設定します。

    タスクフローでactivation="conditional"を設定します。

    タスクフローでactivate=<condition>を設定します。

8.3.1.10 スイッチャ内のタスク・フローの構成

デフォルトでは、スイッチャの下のタスク・フローは、スイッチャ・ファセットが表示されるときではなく、ページがロードされるとアクティブ化されます。これを回避するには、条件付きアクティブ化を使用し、ファセットが表示されるとtrueを戻す式言語(EL)式に"active"を設定します。

8.3.1.11 静的データの再利用

アプリケーション全体で再利用可能な静的データがアプリケーションに含まれている場合、共有アプリケーション・モジュールを使用してキャッシュ・データを収集できます。共有アプリケーション・モジュールの作成および使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュール・ビュー・インスタンスの共有に関する項を参照してください。

8.3.1.12 条件付き検証

エンティティ属性に対してリソース消費量の多い検証を実行するときは、事前条件を使用し、必要な場合にのみ検証を選択して適用することを検討してください。検証のコストを事前条件のコストと比較し、事前条件がパフォーマンス上有益かどうかを判断する必要があります。検証の事前条件を指定する方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の検証の事前条件の設定方法に関する項を参照してください。