Oracle® Fusion Middleware

パフォーマンスのチューニング・ガイド

12c (12.1.2)

E47969-01(原本部品番号:E28643-01)

2013年7月

Oracle Fusion Middleware環境において、パフォーマンスの監視と最適化、最適なパフォーマンスを得るためのコンポーネントの構成、および高性能なアプリケーションの記述を行う方法について説明します。

Oracle Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.1.2)

E47969-01

Copyright © 2013, Oracle and/or its affiliates.All rights reserved.

原本著者: Lisa Jamen

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

このソフトウェアおよびドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 表記規則

第I部 概要

1 概要とロードマップ

- 1.1 マニュアルの範囲および対象読者

- 1.2 このマニュアルの構成

- 1.3 関連ドキュメント

2 主なパフォーマンス分野

- 2.1 主なパフォーマンス分野の特定

- 2.2 十分なハードウェア・リソースの確保

- 2.3 オペレーティング・システムのチューニング

- 2.4 Java仮想マシン(JVM)のチューニング

- 2.5 WebLogic Serverのチューニング

- 2.6 データベース・パラメータのチューニング

- 2.6.1 データベース・パラメータのチューニング

- 2.6.2 REDOログの場所およびサイズのチューニング

- 2.6.3 自動セグメント領域管理(ASSM)のチューニング

- 2.7 データベース接続の再利用

- 2.8 データ・ソースの文キャッシュの有効化

- 2.9 同時実行性の制御

- 2.9.1 サーバー接続制限の設定

- 2.9.1.1 MaxClients/ThreadsPerChild

- 2.9.1.2 KeepAlive

- 2.9.1.3 HTTP Serverモジュールのチューニング

- 2.9.2 接続プールの構成

- 2.9.3 WebLogic Severのスレッド・プールのチューニング

- 2.10 ロギング・レベルの設定

3 パフォーマンス計画

- 3.1 Oracle Fusion Middlewareのパフォーマンス計画について

- 3.2 パフォーマンス計画の方法

- 3.2.1 パフォーマンス目標の定義

- 3.2.1.1 運用要件の定義

- 3.2.1.2 パフォーマンス目標の明確化

- 3.2.1.3 ユーザーの期待の理解

- 3.2.1.4 パフォーマンス評価の実施

- 3.2.2 パフォーマンスおよびスケーラビリティを考慮したアプリケーションの設計

- 3.2.3 パフォーマンス・メトリックの監視および測定

4 Oracle Fusion Middlewareの監視

- 4.1 Oracle Fusion Middlewareの管理ツールについて

- 4.1.1 パフォーマンス・メトリックの測定

- 4.2 Oracle Enterprise Manager Fusion Middleware Control

- 4.3 Oracle WebLogic Server管理コンソール

- 4.4 WebLogic診断フレームワーク(WLDF)

- 4.5 WebLogic Scripting Tool (WLST)

- 4.6 DMSスパイ・サーブレット

- 4.6.1 スパイ・サーブレットを使用したパフォーマンス・メトリックの表示

- 4.6.2 DMSスパイ・サーブレットの使用

- 4.7 オペレーティング・システムのネイティブ・パフォーマンス・コマンド

- 4.8 ネットワーク・パフォーマンス・モニタリング・ツール

5 Oracle Dynamic Monitoring Serviceの使用

- 5.1 Dynamic Monitoring Service (DMS)について

- 5.1.1 共通のDMSの用語と概念の理解

- 5.1.1.1 DMSセンサー

- 5.1.1.1.1 DMS PhaseEventセンサー

- 5.1.1.1.2 DMSイベント・センサー

- 5.1.1.1.3 DMS状態センサー

- 5.1.1.1.4 センサーのネーミング規則

- 5.1.1.2 DMSナウン

- 5.1.1.2.1 一般的なDMSネーミング

- 5.1.1.2.2 一般的なDMSネーミング規則とキャラクタ・セット

- 5.1.1.2.3 ナウンおよびナウン・タイプのネーミング規則

- 5.1.1.3 DMSトレースおよびイベント

- 5.2 DMSの可用性の理解

- 5.3 DMSのアーキテクチャの理解

- 5.4 DMSメトリックの表示

- 5.4.1 スパイ・サーブレットを使用したメトリックの表示

- 5.4.2 WLDF (WebLogic診断フレームワーク)を使用したメトリックの表示

- 5.4.3 WLST (Oracle WebLogic Server)を使用したメトリックの表示

- 5.4.4 JConsoleを使用したメトリックの表示

- 5.4.5 Oracle Enterprise Managerを使用したメトリックの表示

- 5.5 WLDFを使用したDMSメトリックのアクセス

- 5.6 DMS実行コンテキスト

- 5.6.1 DMS実行リクエストおよびサブタスク

- 5.6.2 DMS実行コンテキストの使用

- 5.6.3 DMS実行コンテキストの通信

- 5.7 DMSトレースおよびイベント

- 5.7.1 DMSイベント・システムの構成

- 5.7.1.1 フィルタの追加および編集

- 5.7.1.2 宛先の追加および編集

- 5.7.1.3 イベント・ルートの追加および編集

- 5.7.1.4 複合操作

- 5.7.2 宛先の構成

- 5.7.2.1 LoggerDestination

- 5.7.2.1.1 静的ロガーおよびハンドラ

- 5.7.2.1.2 動的ロガーおよびハンドラ

- 5.7.2.1.3 logging.xmlファイルのデフォルトの場所

- 5.7.2.1.4 CLIコマンドを使用したトレース・ログ・ファイルの問合せ

- 5.7.2.2 MBean Creatorの宛先

- 5.7.2.2.1 メトリックMBeanのオブジェクト名

- 5.7.2.3 HTTPリクエスト・トラッカの宛先

- 5.7.2.3.1 HTTPリクエスト・トラッカのダンプの実行

- 5.7.2.4 Javaフライト・レコーダの宛先

- 5.7.2.4.1 動的に導出されたJFRイベント・タイプ - 名前、値および説明

- 5.7.2.4.2 動的に導出されたプロデューサおよびイベントの例

- 5.7.3 ログ・メッセージのDMSイベント・フォーマットの理解

- 5.7.4 DMSイベント・アクションの理解

- 5.8 DMSのベスト・プラクティス

第II部 コア・コンポーネント

6 Oracle HTTP Serverのパフォーマンス・チューニング

- 6.1 Oracle HTTP Serverについて

- 6.2 Oracle HTTP Serverのパフォーマンスの監視

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

- 6.3.1 Oracle HTTP Serverディレクティブのチューニング

- 6.3.2 永続的な接続によるhttpdプロセスの可用性の低下

- 6.3.3 Oracle HTTP Serverのロギング・オプション

- 6.3.3.1 アクセス・ロギング

- 6.3.3.2 HostNameLookupsディレクティブの構成

- 6.3.3.3 エラー・ロギング

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

- 6.4.1 Oracle HTTP Serverのチューニング

- 6.4.1.1 静的リクエストと動的リクエストの比較分析

- 6.4.1.2 PL/SQLリクエストの管理

- 6.4.1.3 有効モジュール数の制限

- 6.4.1.4 ファイル・ディスクリプタ制限のチューニング

- 6.4.2 Oracle HTTP Serverにおけるセキュリティのチューニング

- 6.4.2.1 Oracle HTTP ServerにおけるSecure Sockets Layer (SSL)のチューニング

- 6.4.2.1.1 Oracle HTTP ServerのSSLキャッシュ

- 6.4.2.1.2 SSLのアプリケーション・レベルのデータ暗号化の使用

- 6.4.2.1.3 SSLパフォーマンスのチューニング

- 6.4.2.2 Oracle HTTP Serverにおけるポート・トンネリングのチューニング

7 Oracle Metadata Service (MDS)のパフォーマンス・チューニング

- 7.1 Oracle Metadata Services (MDS)について

- 7.2 Oracle Metadata Serviceのパフォーマンスの監視

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

- 7.3.1 データベース・リポジトリのチューニング

- 7.3.1.1 スキーマ統計の収集

- 7.3.1.2 REDOログ・サイズの拡大

- 7.3.1.3 ディスク領域の解放

- 7.3.1.4 データベース・パフォーマンスの監視

- 7.3.2 キャッシュ構成のチューニング

- 7.3.2.1 ドキュメント・キャッシュの有効化

- 7.3.3 ドキュメント・バージョン履歴のパージ

- 7.3.3.1 自動パージ

- 7.3.3.2 手動パージ

- 7.3.4 データベース・ポーリング間隔を使用した変更の検出

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

- 7.4.1 カスタマイズがパフォーマンスに与える影響の分析

第III部 Oracle Fusion Middlewareサーバー・コンポーネント

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

- 8.1 Oracle ADFについて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 8.3.1.3 バッチ処理

- 8.3.1.4 RangeSizeのチューニング

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

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

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

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

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

- 8.3.1.7 ADFc: リージョンの使用

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

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

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

- 8.3.1.11 静的データの再利用

- 8.3.1.12 条件付き検証

9 Oracle TopLink (EclipseLink) JPAのパフォーマンス・チューニング

- 9.1 Oracle TopLinkおよびEclipseLinkについて

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

- 9.2.1 効率的なSQL文およびSQL問合せの作成

- 9.2.1.1 エンティティ・リレーションシップ問合せパラメータのチューニング

- 9.2.2 キャッシュ構成のチューニング

- 9.2.2.1 キャッシュ・リフレッシュのシナリオ

- 9.2.2.2 ロック・モード・ポリシーのチューニング

- 9.2.3 マッピングおよびディスクリプタの構成のチューニング

- 9.2.4 データのパーティション化の使用

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

- 9.3.1 Oracle Coherenceとの統合

- 9.3.2 EclipseLink JPAエンティティのパフォーマンス分析

はじめに

このマニュアルでは、パフォーマンスの監視および最適化の方法、パフォーマンスに影響を与える主なコンポーネントの確認方法、複数のコンポーネントを使用して最適なパフォーマンスを得る方法、ならびにOracle Fusion Middleware環境のパフォーマンスを考慮したアプリケーションの設計方法について説明します。

「はじめに」の内容は次のとおりです。

- 対象読者

- ドキュメントのアクセシビリティについて

- 表記規則

対象読者

パフォーマンスのチューニングは、アプリケーション開発者、Oracle Fusion Middleware管理者、データベース管理者およびWebマスターを対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

ドキュメント内のサンプル・コードのアクセシビリティについて

スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じカッコだけを行に記述する必要があります。しかし一部のスクリーン・リーダーはカッコだけの行を読まない場合があります。

外部Webサイトのドキュメントのアクセシビリティについて

このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

第I部

概要

この部では、パフォーマンスに関する基本的な概念、パフォーマンスの測定方法、ならびにパフォーマンスおよびスケーラビリティを考慮したアプリケーションの設計方法について説明します。次の章で構成されています。

- 第1章「概要とロードマップ」

- 第2章「主なパフォーマンス分野」

- 第3章「パフォーマンス計画」

- 第4章「Oracle Fusion Middlewareの監視」

1 概要とロードマップ

この章では、このマニュアルの内容および構成について説明します。

- 第1.1項「マニュアルの範囲および対象読者」

- 第1.2項「このマニュアルの構成」

- 第1.3項「関連ドキュメント」

1.1 マニュアルの範囲および対象読者

パフォーマンスのチューニングは、アプリケーション開発者、Oracle Fusion Middleware管理者、データベース管理者およびWebマスターを対象としています。このマニュアルでは、Fusion Middlewareの管理とハードウェアのパフォーマンス・チューニングに関する基本的な知識、ならびにWebLogic Server、XMLおよびJavaプログラミング言語の知識があることが前提となります。

1.2 このマニュアルの構成

- この章、第1章「概要とロードマップ」では、このマニュアルの目的および構成を示します。

- 第2章「主なパフォーマンス分野」では、Oracle Fusion Middlewareの主なチューニング分野について説明します。この章は、アプリケーション・チューニングのクイック・スタート・ガイドとなります。

- 第3章「パフォーマンス計画」では、Oracle Fusion Middlewareのパフォーマンス計画手法およびチューニングの概念について説明します。

- 第4章「Oracle Fusion Middlewareの監視」では、Oracle Fusion Middlewareとそのコンポーネントを監視してパフォーマンス・データを取得し、システムのチューニングやパフォーマンスに問題のあるアプリケーションのデバッグに役立てる方法を説明します。

- 第5章「Oracle Dynamic Monitoring Serviceの使用」は、Oracle Dynamic Monitoring Service (DMS)の概要と使用可能な機能について説明しています。

- 第6章「Oracle HTTP Serverのパフォーマンス・チューニング」では、Oracle Fusion MiddlewareのWebサーバー・コンポーネントであるOracle HTTP Serverのパフォーマンスを最適化する手法を説明します。Oracle WebLogic Serverのリスナーと静的ページ、動的ページおよびWeb上のアプリケーションのホスティングのフレームワークを提供します。

- 第7章「Oracle Metadata Service (MDS)のパフォーマンス・チューニング」では、Oracle Metadata Service (MDS)のチューニングのヒントを示します。MDSは、Oracle Application Development Frameworkにより、メタデータの管理に使用されます。

- 第8章「Oracle Application Development Frameworkのパフォーマンス・チューニング」では、アプリケーションにおけるADFスタックのパフォーマンスおよびスケーラビリティを最大化する方法についての基本的なガイドラインを示します。Oracle ADFは、Java Platform, Enterprise Edition (Java EE)標準およびオープンソース・テクノロジをベースとするエンドツーエンドのアプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。この章では、設計時、構成時およびデプロイメント時のパフォーマンスに関する考慮事項を取り上げます。

- 第9章「Oracle TopLink (EclipseLink) JPAのパフォーマンス・チューニング」では、Java Persistence API (JPA)エンティティ・アーキテクチャのパフォーマンスに関する選択肢を示します。Oracle TopLinkには、EclipseLinkがJPA実装として含まれています。

1.3 関連ドキュメント

詳細は、Oracle Fusion Middleware 12c (12.1.2)のドキュメント・セットにある次のドキュメントを参照してください。

- Oracle Fusion Middlewareの管理

- Oracle Fusion Middlewareの概要

- Oracle Platform Security Servicesによるアプリケーションの保護

- 高可用性ガイド

- Oracle WebLogic Serverのパフォーマンスのチューニング

- Oracle HTTP Serverの管理

- Webサービスの管理

2 主なパフォーマンス分野

この章では、Oracle Fusion Middlewareの主なチューニング分野について説明します。取り上げるのは、Oracle Fusion Middlewareの重要なパフォーマンス分野です。Javaアプリケーションのチューニングにおけるクイック・スタート・ガイドとなります。内容は次のとおりです。

- 第2.1項「主なパフォーマンス分野の特定」

- 第2.2項「十分なハードウェア・リソースの確保」

- 第2.3項「オペレーティング・システムのチューニング」

- 第2.4項「Java仮想マシン(JVM)のチューニング」

- 第2.5項「WebLogic Serverのチューニング」

- 第2.6項「データベース・パラメータのチューニング」

- 第2.7項「データベース接続の再利用」

- 第2.8項「データ・ソースの文キャッシュの有効化」

- 第2.9項「同時実行性の制御」

- 第2.10項「ロギング・レベルの設定」

2.1 主なパフォーマンス分野の特定

パフォーマンス・チューニングの最も難しい面の1つは、どこから始めればよいかを知ることです。この章は、Oracle Fusion Middlewareアプリケーションのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。

表2-1は、Oracle Fusion Middlewareのパフォーマンスに関する一般的な考慮事項をリストにまとめたものです。このリストは、パフォーマンス・チューニングを始めるうえで有効なツールとなりますが、チューニングが必要な分野をすべて網羅してはいません。アプリケーションにおけるパフォーマンスの問題を個別に監視、追跡し、どこをチューニングすればパフォーマンスが向上するかを把握する必要があります。詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

表2-1 Oracle Fusion Middlewareの主なパフォーマンス分野

パフォーマンス分野

説明と参照先

ハードウェア・リソース

パフォーマンスを最大化するために、アプリケーションのリソース要件と同等またはそれ以上のハードウェア・リソースがあることを確認します。

ハードウェア・リソースが十分かどうかを判断する方法の詳細は、第2.2項「十分なハードウェア・リソースの確保」を参照してください。

オペレーティング・システム

各オペレーティング・システムには、監視用の便利なネイティブ・ツールおよびユーティリティが用意されています。

第2.3項「オペレーティング・システムのチューニング」を参照してください。

Java仮想マシン(JVM)

この項では、ベスト・プラクティスについて説明し、JVMのチューニングおよびJava EEアプリケーションのパフォーマンス向上に役立つ実用的なヒントを示します。ヒープ・サイズおよびJVMガベージ・コレクション関連のオプションについても説明します。

第2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。

データベース

データベースにアクセスするアプリケーションの場合は、データベースがアプリケーションの要件に合せて正しく構成されていることを確認します。

ガベージ・コレクションの詳細は、第2.6項「データベース・パラメータのチューニング」を参照してください。

WebLogic Server

Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、第2.5項「WebLogic Serverのチューニング」を参照してください。

データベース接続

接続を再利用するための接続プーリングは、チューニングの際の重要な考慮事項です。

第2.7項「データベース接続の再利用」を参照してください。

データ・ソースの文キャッシュ

データベースを使用するアプリケーションの場合は、文キャッシュを正しく構成することで、繰り返し実行される文の解析および作成がパフォーマンスに与える影響を軽減できます。

第2.8項「データ・ソースの文キャッシュの有効化」を参照してください。

Oracle HTTP Server

Oracle HTTP Serverディレクティブをチューニングし、HTTP接続数を指定して同時実行性のレベルを設定します。

第2.9項「同時実行性の制御」を参照してください。

同時実行性

この項では、Oracle Fusion Middlewareコンポーネントに対する同時実行性の制御方法について説明します。

第2.9項「同時実行性の制御」を参照してください。

ロギング・レベル

ロギング・レベルは、ログに記録される情報の量を制御するためにシステム管理者が設定するしきい値です。アプリケーションがログに記録する情報の量はパフォーマンスに影響を与えるため、ロギング・レベルを正しく設定することが重要です。

第2.10項「ロギング・レベルの設定」を参照してください。

2.2 十分なハードウェア・リソースの確保

Oracle Fusion Middlewareアプリケーションのパフォーマンス管理における重要な要素は、システムのユーザー要件とアプリケーション要件を満たす十分なCPU、メモリーおよびネットワーク・リソースがあることを確認することです。

どれほど適切にアプリケーションをチューニングしても、適切なハードウェア・リソースがなければ、アプリケーションのパフォーマンスは最適なレベルに達しません。Oracle Fusion Middlewareのアプリケーションおよびデータベース層には、最小限のハードウェア要件があります。Oracle Fusion Middlewareがサポートする構成の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のシステム要件と前提条件に関する項を参照してください。

ハードウェア・リソースが十分であるとは、飽和状態にならずに、アプリケーションで許容されるレベルと同等またはそれ以上のレスポンス時間およびスループットを達成できることです。十分なハードウェア・リソースがあることを確認するには、リソース使用率を長期間にわたって監視し、使用率が一時的にピークに達することがあるのか(あるとすればそれはいつか)、それともリソースが常に飽和状態にあるのかを調べる必要があります。監視の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

ヒント:

CPU使用率が決して100%に達しないようにする必要があります。目標とするCPU使用率は、アプリケーションのニーズ(ピーク時のCPUサイクルなど)に基づいて決定してください。

通常負荷時のCPU使用率が100%になるように最適化した場合、ピーク時の負荷を処理するキャパシティは残っていません。待機時間の影響を受けやすく、高速のレスポンス時間を維持することが重要な意味を持つアプリケーションでは、CPU使用率が高い(100%に近づく)と、レスポンス時間が長くなる一方で、スループットは一定に保たれるか、低下します。このようなアプリケーションの場合、推奨されるCPU使用率は70から80%です。待機時間の影響を受けないアプリケーションの場合は、90%程度を目標とすることをお薦めします。

飽和状態になっている(使用率が常に100%か、それに近い)ハードウェア・リソースが1つでもある場合は、次の状況のうち1つ以上が発生している可能性があります。

- アプリケーションを実行するのに十分なハードウェア・リソースがない。

- システムが正しく構成されていない。

- アプリケーションまたはデータベースのチューニングが必要である。

リソースが常に飽和状態にある場合の解決策は、負荷を減らすか、リソースを増やすことです。レスポンス時間の増大が許されないピーク・トラフィック時については、リソースを増やすことを検討するか、トラフィックをスケジュールしなおして(オフピーク時にバッチ処理やバックグラウンド処理をスケジュールするなど)ピーク時の負荷を減らせるかどうか確認してください。

Oracle Fusion Middlewareには、リソースの同時使用を制御する各種メカニズムが用意されています。これにより、トラフィックの急増による影響を抑えることができます。ただし、常に飽和状態にあるシステムでは、こうしたメカニズムも一時的な解決策にすぎません。詳細は、第2.9項「同時実行性の制御」を参照してください。

2.3 オペレーティング・システムのチューニング

各オペレーティング・システムには、監視やチューニングを目的とする便利なネイティブ・ツールおよびユーティリティが用意されています。オペレーティング・システムのネイティブ・コマンドを使用すれば、CPU使用率、ページング・アクティビティ、スワッピング、その他のシステム・アクティビティ情報を監視できます。

オペレーティング・システム・コマンドの詳細と、ネットワークまたはオペレーティング・システムのパフォーマンス・チューニングに関するガイドラインは、オペレーティング・システム・ベンダー提供のドキュメントを参照してください。

2.4 Java仮想マシン(JVM)のチューニング

Java仮想マシン(JVM)をどのようにチューニングするかによって、Oracle Fusion Middlewareおよびアプリケーションのパフォーマンスが大きく変わります。JVMのチューニングの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のJava仮想マシン(JVM)のパフォーマンス・チューニングに関する項を参照してください。

2.5 WebLogic Serverのチューニング

Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のWebLogic Serverのチューニングに関する項を参照してください。

2.6 データベース・パラメータのチューニング

Oracleデータベースを使用するアプリケーションのパフォーマンスを最適化するには、アクセスの対象となるデータベース表を、パフォーマンスを念頭に置いて設計する必要があります。データベースの監視およびチューニングを行えば、アプリケーションから最適なパフォーマンスを確実に得ることができます。

注意:

この項の情報はFusion Middlewareのデータベース・チューニング情報のサブセットです。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。必ず、データベース・チューニングに関するドキュメントも確認してください。

この項の内容は次のとおりです。

- データベース・パラメータのチューニング

- REDOログの場所およびサイズのチューニング

- 「自動セグメント領域管理(ASSM)のチューニング」

注意:

必ず、ご使用のデータベースのベンダー・ドキュメントでチューニングに関するガイドラインを確認してください。Oracleデータベースのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

2.6.1 データベース・パラメータのチューニング

次の表は、一般的なinit.oraパラメータとその説明をまとめたものです。データベース・パラメータを設定する際には、表に記載されたガイドラインを考慮してください。ただし、最終的にはDBAがデータベースの状態を監視し、必要に応じてパラメータをチューニングする必要があります。詳細は、表2-2を参照してください。

表2-2 Oracle 11gの重要なinti.oraデータベース・チューニング・パラメータ

データベース・パラメータ

説明

AUDIT_TRAIL

DBアクティビティを監査するポリシーがない場合は、このパラメータをNONEに設定することを検討してください。監査を有効にすると、パフォーマンスに影響が出る可能性があります。

MEMORY_MAX_TARGET

MEMORY_MAX_TARGETには、DBAがMEMORY_TARGET初期化パラメータに設定できる最大値を指定します。

MEMORY_TARGET

MEMORY_TARGETをNONEに設定することを検討してください。MEMORY_TARGET設定によって必要に応じてSGAおよびPGAに十分なメモリーが割り当てられないとき、SGAおよびPGAを個別に設定します。

PGA_AGGREGATE_TARGET

最初にPGAに値1Gを使用することを検討してください。その後、本番データベースを日次ベースで監視し、それに応じてSGAおよびPGAを調整します。

データベース・サーバーのメモリーに余裕がある場合は、PGA_AGGREGATE_TARGETを使用ニーズに基づいて1Gより大きい値に設定することを検討してください。

SGA_MAX_SIZE

SGAとPGAを別々に設定するかわりに、MEMORY_TARGETを設定することを検討してください。

SGA_TARGET

最初にSGAに値2Gを使用することを検討してください。その後、本番データベースを日次ベースで監視し、それに応じてSGAおよびPGAを調整します。

データベース・サーバーのメモリーに余裕がある場合は、SGA_TARGETを使用ニーズに基づいて2Gより大きい値に設定することを検討してください。

2.6.2 REDOログの場所およびサイズのチューニング

REDOログ・オプションをチューニングすると、Oracle Fusion Middleware環境で稼働しているアプリケーションのパフォーマンスを改善できます。また、REDOログを別のディスクに移動することで、I/Oスループットを大幅に改善できる場合もあります。

サイズが2GのREDOログ・グループを3つ以上保持することを検討してください。I/Oパフォーマンスを向上させるには、REDOログ・ファイルをデータ・ファイルとは別のディスク上に配置してください。

2.6.3 自動セグメント領域管理(ASSM)のチューニング

永続表領域については、自動セグメント領域管理の使用を検討してください。ビットマップ表領域と呼ばれることも多い永続表領域は、ビットマップ・セグメント領域管理によってローカルに管理される表領域です。

下位互換性を確保するために、ローカル表領域のデフォルトのセグメント領域管理モードはMANUALに設定されています。

表領域を構成する際は、エクステント割当てタイプをSYSTEMに設定することを検討してください。割当てタイプをUNIFORMに設定すると、パフォーマンスに影響を与える場合があります。

詳細は、『Oracle Database概要』の空き領域管理に関する項、および『Oracle Database管理者ガイド』のローカル管理表領域のセグメント領域管理の指定に関する項を参照してください。

2.7 データベース接続の再利用

データベース接続の作成は、環境を問わず、比較的リソース消費量の多いプロセスです。通常、起動時の接続プールには少数の接続が含まれています。クライアントからの接続の要求が増えるにつれて、プール内の接続が不足し、要求を満たせなくなることがあります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。

接続作成の遅れを回避する1つの方法は、クライアントの要求に応じて接続を初期化するのではなく、サーバー起動時にすべての接続を初期化することです。この方法は、負荷が一定で、予測可能な場合に適しています。データ・ソース構成の「接続プール」タブで、初期接続数を最大接続数と同一に設定します。本番前のパフォーマンス・テストの一環として、「最大容量」の最適な値を決定します。

負荷が一定せず、ピーク負荷時の接続数が通常負荷時の接続数よりかなり多い場合は、初期接続数を通常負荷時と同一に設定することを検討してください。さらに、対応可能なピーク負荷に基づいて最大接続数を設定することを検討してください。このように構成すれば、WebLogic Serverは一定期間にわたって使用されていない接続を解放できます。

詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のデータ・ソース接続プールのチューニング・オプションに関する項を参照してください。

2.8 データ・ソースの文キャッシュの有効化

アプリケーションまたはEJBでプリコンパイル文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信の処理、およびデータベース・サーバー上での処理に伴って、パフォーマンスに影響が出ることがあります。処理への影響を最小限に抑えるには、アプリケーションで使用されるプリコンパイル文およびコール可能文をデータ・ソースがキャッシュできるようにします。アプリケーションまたはEJBがキャッシュに格納された文をコールした場合、サーバーはキャッシュに格納された文を再利用します。プリコンパイル文およびコール可能文を再利用することで、データベース・サーバーのCPU使用率が低下します。その結果、現在の文のパフォーマンスが向上し、CPUサイクルを他のタスクに割り当てられるようになります。

データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されますが、文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。

- 文キャッシュ・タイプ: 文キャッシュにどの文を格納するかを決定するアルゴリズム。

- 文キャッシュ・サイズ: 各接続についてキャッシュに格納する文の数。デフォルト値は10です。データベースの文解析メトリックを分析したうえで、文キャッシュはアプリケーションで使用する文の数に十分対応できるサイズに設定してください。

管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソースの文キャッシュの構成」を参照してください。

文キャッシュの使用の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の文キャッシュによるパフォーマンスの向上に関する項を参照してください。

2.9 同時実行性の制御

システムの複数のレイヤーで個別の使用ニーズに合せて同時実行性を制限すると、パフォーマンスを大幅に改善できます。この項では、Oracle Fusion Middlewareの中で同時実行性の制御が可能ないくつかの分野について説明します。

システムのキャパシティに達した後も、Webサーバーやアプリケーション・サーバーがリクエストを受け付け続けると、アプリケーションのパフォーマンスおよび安定性が低下します。Oracle Fusion Middlewareには、リクエストを抑制して中間層またはデータベース層のシステムが過負荷の状態になることを避け、最適なパフォーマンスが得られるようチューニングすることのできる分野があります。

- サーバー接続制限の設定

- 「接続プールの構成」

- WebLogic Severのスレッド・プールのチューニング

2.9.1 サーバー接続制限の設定

Oracle HTTP Serverでは、httpd.confのディレクティブが使用されます。この構成ファイルには、同時に処理可能なHTTPリクエストの最大数、ロギング詳細、ならびに特定の制限およびタイムアウトが指定されています。

httpd.confファイルの変更方法の詳細は、『Oracle HTTP Serverの管理』の「Oracle HTTP Serverの構成」を参照してください。

MaxClientsディレクティブおよびThreadsPerChildディレクティブを使用すると、予想されるクライアント負荷およびシステム・リソースに基づいて、Oracle HTTP ServerからWebLogicインスタンスへの受信リクエストを制限できます。次の各項では、接続制限に関連するOracle HTTP Serverチューニング・パラメータについて説明します。これらは通常、予想されるクライアント負荷に基づいてチューニングする必要があります。詳細とチューニング可能なパラメータの詳しいリストは、第6章「Oracle HTTP Serverのパフォーマンス・チューニング」を参照してください。

2.9.1.1 MaxClients/ThreadsPerChild

注意:

MaxClientsパラメータはUNIXプラットフォームにのみ適用されます。Microsoft Windows (mpm_winnt)では、ThreadsPerChildパラメータとThreadLimitパラメータで同じ機能が実現されています。

MaxClientsプロパティに、稼働しているサーバー・スレッドの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、(ListenBackLogディレクティブで)指定した制限に達するまでTCP/IPシステムのキューに入れられます。

MaxClientsディレクティブはhttpd.confファイルで構成でき、最大値は8K(デフォルト値は150)です。システム・リソースが飽和状態でなく、HTTPの同時接続ユーザー数が150を超えている場合は、MaxClientsを大きくしてサーバーの同時実行性を高めると、パフォーマンスが向上します。システムの利用状況がフル(目安は85%)になるまで、MaxClientsを大きくします。

システム・リソースが飽和状態のときにMaxClientsを大きくしても、パフォーマンスは向上しません。この場合は、サーバーへの同時リクエスト数に対するスロットルとして、MaxClientsの値を小さくします。

サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドルな接続の両方を処理するために十分な数の同時httpdサーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxClientsを指定する際に、アイドル状態の永続的なhttpd接続もhttpdプロセスを消費することを考慮に入れる必要があります。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。使用可能なhttpdサーバー・スレッドがない場合、接続リクエストはスレッドが使用可能になるまでTCP/IPシステムのキューに入れられます。最終的には、クライアントが接続を終了します。

Oracle HTTP Serverへの着信接続を処理するサーバー・プロセスの数、および1プロセス当たりのスレッドの数(ThreadsPerChild)を定義できます。ThreadsPerChildプロパティには、サーバー(子)・プロセスの下に作成可能なスレッドの数の上限を指定します。

注意:

ThreadsPerChild、StartServers、ServerLimitの各プロパティは、MaxClients設定と相互に関係しています。MaxClientsで指定した数の接続を得るには、これらのプロパティをすべて正しく設定する必要があります。すべてのHTTP構成プロパティの説明は、表6-1「Oracle HTTP Server構成プロパティ」を参照してください。

2.9.1.2 KeepAlive

永続的(KeepAlive)なHTTP接続は、接続リクエストの処理中でなくても、接続期間中はhttpd子プロセス(スレッド)を消費します。

十分なキャパシティがある場合は、KeepAliveを有効にしてください。永続的な接続を使用することで、パフォーマンスが向上し、HTTP接続の再確立によるCPUリソースの浪費が回避されます。通常、KeepAliveパラメータの変更は不要です。

注意:

永続的な接続に対するデフォルトの最大リクエスト数は100です。これはhttpd.confのMaxKeepAliveRequestsディレクティブで指定されています。デフォルトでは、サーバーはクライアントからのリクエストを15秒間待ってから接続をクローズします。これはhttpd.confのKeepAliveTimeoutディレクティブで指定されています。

2.9.1.3 HTTP Serverモジュールのチューニング

Oracle HTTP Server (OHS)は、mod_wl_ohsモジュールを使用して、基礎となるWeblogic ServerまたはWeblogic Serverクラスタへリクエストを転送します。mod_wl_ohsの構成の詳細は、configディレクトリのmod_wl_ohs.confファイルで確認できます。

mod_wl_ohsのチューニング・パラメータの詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverモジュールの理解に関する項を参照してください。

2.9.2 接続プールの構成

接続プーリングは、Javaランタイムごとに構成および保守します。接続は、異なるランタイム間で共有されません。接続プーリングを使用するのに、構成は必要ありません。構成が必要なのは、プール・サイズやプールされる接続のタイプを制御するなど、プーリングの実行方法をカスタマイズする場合のみです。

接続プーリングは、プログラムの起動時にシステム・プロパティの数を使用して構成します。これらは環境プロパティではなくシステム・プロパティであるため、すべての接続プーリング・リクエストに作用することに注意してください。

データベースを使用するアプリケーションの場合、データ・ソースに関連付けられている接続プールの接続数を制限すると、パフォーマンスが向上します。MaxCapacity属性を使用してOracle Application Serverからのデータベース・リクエストを制限することで、受信リクエストが原因でデータベースが飽和状態になったり、データベース・アクセスが原因でOracle Application Server層のリソースが過負荷状態になったりすることを回避できます。

接続プールのMaxCapacity属性は、接続プールに作成できる接続の最大数を示します。デフォルトでは、MaxCapacityの値は15に設定されています。最適なパフォーマンスを得るには、データベースのパフォーマンス特性に適した数値をMaxCapacityに指定してください。

オープンしているデータベース接続の総数を、データベースで処理可能な数に制限することは、チューニングの際の重要な考慮事項です。データベースが、すべてのデータ・ソースのMaxCapacityオプションで指定されている値の合計と同じ数以上の接続をオープンできるよう構成されていることを確認してください(このオプションはデータベースにアクセスするすべてのアプリケーションで指定されています)。

関連項目:

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」

『Oracle WebLogic Server JDBCデータ・ソースの管理』のデータ・ソース接続プールのチューニング・オプションに関する項

2.9.3 WebLogic Severのスレッド・プールのチューニング

デフォルトでは、WebLogic Serverが使用するスレッド・プールは1つであり、その中であらゆるタイプの作業が実行されます。WebLogic Serverは、ワーク・マネージャを使用し、ユーザー定義ルールおよびランタイム・メトリック(リクエストの実行に要する実際の時間や、リクエストがプールに入る頻度とプールを出る頻度など)に基づいて処理の優先順位を決定します。共通のスレッド・プールを管理するデフォルトのワーク・マネージャが存在します。

共通のスレッド・プールのサイズは、スループットが最大になるように自動的に変化します。WebLogic Serverでは、履歴に基づいてスループットを長期的に監視し、スレッド数の調整が必要かどうかを判断しています。たとえば、過去のスループット統計から、スレッド数を増やしたらスループットが向上したと判明した場合は、スレッド数を増やします。同様に、スレッド数を減らしてもスループットが低下しなかったと統計から判明した場合は、スレッド数を減らします。

WebLogic Serverのスレッド・プールのサイズはデフォルトで自動的に設定されるため、チューニングの必要はないことがほとんどです。ただし、特殊な要件がある場合は、管理者がカスタム・ワーク・マネージャを構成して、同様のパフォーマンス要件、可用性要件または信頼性要件を持つリクエスト・セットごとに、スレッド・プールをきめ細かく管理できます。カスタム・ワーク・マネージャでは、保留中の作業の割当て方法に関する優先順位およびガイドラインを定義できます。たとえば、最小スレッド数または最大スレッド数に対する制約や、WebLogic Serverがリクエストを拒否し始めるまでにキューに入れる、または実行することのできるリクエストの総数に対する制約を指定します。

ワーク・マネージャを使用してスレッド管理をカスタマイズする必要があるかどうかは、次のガイドラインを基に判断してください。

- デフォルト値では不十分である。
通常、これが該当するのは、特定のアプリケーションに他のアプリケーションより高い優先度を付ける必要がある場合です。

- レスポンス時間の目標を設定する必要がある。

- 最小スレッド数制約を指定して、サーバーのデッドロックを回避する必要がある。

- アプリケーションでMDBを使用している。
MDBに割り当てるサーバー・スレッド・リソースを明確に定義して、それをMDBに確実に使用させる場合や、MDBの同時実行性をチューニングする場合は、最大スレッド数制約が指定されたカスタム・ワーク・マネージャを参照するように、ほとんどのMDBを変更する必要があります。一般に、カスタム・ワーク・マネージャが便利なのは、複数のMDBデプロイメントが存在する場合や、特定のMDBが多くのスレッドを必要とする場合です。

関連項目:

カスタム・ワーク・マネージャを使用してスレッド管理をカスタマイズする方法、およびカスタム・ワーク・マネージャを使用する必要があるかどうかの判断の詳細は、次のドキュメントを参照してください。

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』のプール・サイズのチューニングに関する項

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』のスレッド管理に関する項

- 『Oracle WebLogic Serverのパフォーマンスのチューニング』のMDBスレッド管理に関する項

- 『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュール済作業の最適化に関する項

- 『Oracle WebLogic Serverサーバー環境の管理』の過負荷の回避と管理に関する項

Oracle WebLogic管理コンソールを使用すると、スレッド・プールのステータスの概要(アクティブ・スレッド数、合計スレッド数、キューの長さなど)を確認できます。コンソールでは、監視中ページの「ワークロード」タブから、各アプリケーションに設定したワーク・マネージャ・メトリックも確認できます。表示されるメトリックは、保留中リクエストの数や完了したリクエストの数などです。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 監視: スレッド」および「デプロイメント: 監視: ワークロード」を参照してください。

ワーク・マネージャおよびスレッド・プールのメトリックは、Oracle Fusion Middleware Controlからも確認できます。

2.10 ロギング・レベルの設定

アプリケーションがログに記録する情報の量は、環境の構成およびアプリケーション・コードのインスツルメント状況によって異なります。パフォーマンスを最大化するには、デフォルトのINFOレベルより高いロギング・レベルを設定しないでください。ロギング設定がデフォルト・レベルと異なる場合は、最適なパフォーマンスが得られるよう、ロギング・レベルをデフォルトに戻します。

アプリケーションおよびサーバーのロギング・レベルを正しく設定したら、デバッグ・プロパティやアプリケーション・レベルのその他のデバッグ・フラグが適切なレベルに設定されているか、または無効になっていることも確認します。パフォーマンスへの影響を回避するには、ロギング・レベルを、より多くの診断メッセージが生成されるレベル(FINEレベルまたはTRACEレベル)に設定しないでください。

コンポーネントごとに、特定の推奨ロギング・レベルがあります。詳細は、このドキュメントの該当するコンポーネントの章を参照してください。

3 パフォーマンス計画

この章では、Oracle Fusion Middlewareのパフォーマンスおよびチューニングの概念について説明します。この章の内容は次のとおりです。

- 第3.1項「Oracle Fusion Middlewareのパフォーマンス計画について」

- 第3.2項「パフォーマンス計画の方法」

3.1 Oracle Fusion Middlewareのパフォーマンス計画について

Oracle Fusion Middlewareのパフォーマンスを最大化するには、アプリケーションで使用されるすべてのコンポーネントの監視、分析およびチューニングを行う必要があります。このマニュアルでは、パフォーマンスの監視に使用できるツールと、Oracle Fusion Middlewareコンポーネントのパフォーマンスを最適化する手法について説明しています。

通常、パフォーマンス・チューニングには一連のトレードオフが伴います。ボトルネックの原因を特定した後、他の分野のパフォーマンスを調整しないと、期待される成果が得られない場合もあります。ただし、パフォーマンス目標の達成に向けての明確な計画があれば、最も重要な分野がはっきりするため、パフォーマンス向上のために何を犠牲にするかを判断しやすくなります。

3.2 パフォーマンス計画の方法

Fusion Middlewareコンポーネントは、パフォーマンスおよびスケーラビリティを考慮して構築されています。アプリケーションのパフォーマンス機能を最大限に高めるには、パフォーマンスおよびスケーラビリティを設計に組み込む必要があります。パフォーマンス計画は、現在のパフォーマンス要件を満たし、既知の問題(ボトルネックやハードウェア・リソースの不足など)を解決し、負荷、ユーザーまたはプロセスの予期される変化に対応するものであることが必要です。また、パフォーマンスに影響を与えることなく、ピーク時にコンポーネントを拡張する方法も示す必要があります。

この後の項では、アプリケーション環境をチューニングしてパフォーマンスを最適化するための計画を作成する手順について説明します。

- ステップ1: パフォーマンス目標の定義

- ステップ2: パフォーマンスおよびスケーラビリティを考慮したアプリケーションの設計

- ステップ3: パフォーマンス・メトリックの監視および測定

3.2.1 パフォーマンス目標の定義

アプリケーションのパフォーマンス・チューニングを始める前に、まず達成しようとするパフォーマンス目標を明確化する必要があります。パフォーマンス目標を決定するには、デプロイするアプリケーションおよびシステムの環境面での制約を理解する必要があります。

パフォーマンス目標が何であるかを理解するために、次のステップを実行してください。

- 運用要件の定義

- パフォーマンス目標の明確化

- ユーザーの期待の理解

- パフォーマンス評価の実施

パフォーマンス目標は、次のような制約によって制限されます。

- ハードウェアおよびソフトウェアの構成(CPUタイプ、ディスク・サイズ、ディスクの処理速度、十分なメモリーなど)。
ハードウェア要件を決定するための唯一の公式などありません。アプリケーションのニーズを十分に満たすために必要なハードウェアおよびソフトウェアの構成を決定するプロセスをキャパシティ・プランニングと呼びます。

キャパシティ・プランニングの際には、システムのパフォーマンス目標を評価し、アプリケーションを理解することが求められます。サーバー・ハードウェアのキャパシティ・プランニングでは、最大のパフォーマンス要件に焦点を当てる必要があります。

- ピーク使用量やレスポンス時間に対応した高可用性アーキテクチャの構成。Oracle Fusion Middlewareアプリケーションに高可用性機能を実装する方法の詳細は、『高可用性ガイド』を参照してください。

- ドメイン間の相互運用、レガシー・システムの使用、およびレガシー・データのサポートが可能かどうか。

- 開発、実装およびメンテナンスのコスト。

これらの制約とそれぞれの影響を理解することで、レスポンス時間、スループット、特定のハードウェアにかかる負荷など、アプリケーション環境にとって現実的なパフォーマンス目標を確実に設定できます。

3.2.1.1 運用要件の定義

Oracle Fusion Middlewareにアプリケーションをデプロイしてチューニングする作業を始める前に、運用環境を明確に定義しておくことが重要です。運用環境は、次のような大まかな制約および要件によって決まります。

- アプリケーション・アーキテクチャ

- セキュリティ要件

- ハードウェア・リソース

3.2.1.2 パフォーマンス目標の明確化

新しいシステムを設計するのか、既存のシステムをメンテナンスするのかにかかわらず、具体的なパフォーマンス目標を設定して、最適化の方法と対象を知っておいてください。パフォーマンス目標を決定するには、デプロイするアプリケーションおよびシステムの環境面での制約を理解する必要があります。

アプリケーションのコンポーネントが達成することを求められるアクティビティ・レベルについて、次のような情報を収集します。

- 予想ユーザー数

- リクエストの数およびサイズ

- データの量および一貫性

- 目標とするCPU使用率

3.2.1.3 ユーザーの期待の理解

アプリケーション開発者、データベース管理者およびシステム管理者は、ユーザーのパフォーマンスへの期待を注意深く適切に設定する必要があります。システムで特に複雑な処理を実行している場合は、単純な処理を実行している場合よりレスポンス時間が長くなります。ユーザーには、どの処理に時間がかかるかを知らせておく必要があります。

たとえば、ユーザーの90%に対するレスポンス時間を5秒以内、すべてのユーザーに対する最大レスポンス時間を20秒に抑えようと考えているとします。通常、これは簡単なことではありません。アプリケーションでは様々な処理が実行され、特性も許容されるレスポンス時間も処理ごとに異なります。各処理について、測定可能な目標を設定する必要があります。

負荷の変動がレスポンス時間に与える影響も調べる必要があります。たとえば、ユーザーによるシステムへのアクセスが午前9時から10時の間に集中し、午後1時から2時の間に再度集中するとします(図3-1のグラフを参照)。負荷のピークが定期的に(毎日、毎週など)発生する場合は、システムの構成およびチューニングを負荷のピーク時の要件に合せて行うのが一般的です。オフピーク時にアプリケーションにアクセスしたユーザーに対するレスポンス時間は、ピーク時のユーザーの場合より短くなります。負荷のピークが頻繁に発生しない場合は、負荷のピーク時のレスポンス時間が長くなっても許容し、小規模なハードウェア構成でコストを削減することも考えられます。

図3-1 キャパシティおよび機能面での需要の調整

3.2.1.4 パフォーマンス評価の実施

パフォーマンス目標およびパフォーマンスへの期待が明確に定義されていれば、パフォーマンスのチューニングが成功したかどうかを容易に判断できます。成功を左右するのは、ユーザー・コミュニティに対して設定した機能面での目標、基準が満たされたかどうかを判断する能力、および例外事項を解決するための対策を講じる能力です。

継続的にパフォーマンスを監視することで、十分にチューニングされたシステムを維持できます。アプリケーションのパフォーマンスの履歴を記録することで、有効な比較が可能になります。様々な負荷に対する実際のリソース消費データを使用すれば、客観的なスケーラビリティ調査を実施し、その結果から予想される負荷のボリュームに合せたリソース要件を予測することができます。パフォーマンス評価の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

3.2.2 パフォーマンスおよびスケーラビリティを考慮したアプリケーションの設計

優れたパフォーマンスの鍵となるのは優れた設計です。アプリケーション開発サイクルにおける設計フェーズは、継続的なプロセスとして実施する必要があります。アプリケーション開発サイクルの中で計画、監視、チューニングのフェーズを繰り返すことは、Fusion Middlewareのデプロイメント全般にわたって最適なパフォーマンスを得るうえで不可欠です。反復型の設計手法を使用することで、パフォーマンス目標に影響を与えずにワークロードの変化に対応できます。

3.2.3 パフォーマンス・メトリックの監視および測定

Oracle Fusion Middlewareには、サーバーとアプリケーションのパフォーマンスの監視に使用できる各種テクノロジおよびツールが用意されています。監視を行うことで、サーバー・アクティビティの評価、傾向の観察、システムのボトルネックの診断、パフォーマンスに問題のあるアプリケーションのデバッグ、およびシステムのチューニングに役立つデータの収集が可能になります。詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

パフォーマンス・チューニングの内容は、システムにデプロイしたアプリケーションやリソースによって異なります。一般的なチューニング分野については、第2章「主なパフォーマンス分野」で説明しています。

関連項目:

『Oracle Databaseパフォーマンス・チューニング・ガイド』

Oracle WebLogic Serverのパフォーマンスのチューニング

Oracle Fusion Middlewareの管理

4 Oracle Fusion Middlewareの監視

Oracle Fusion Middlewareには、サーバーとアプリケーションのパフォーマンスの監視に使用できる各種テクノロジおよびツールが用意されています。監視はパフォーマンス・チューニングにおける重要なステップです。監視を行うことで、サーバー・アクティビティの評価、傾向の観察、システムのボトルネックの診断、パフォーマンスに問題のあるアプリケーションのデバッグ、およびシステムのチューニングに役立つデータの収集が可能になります。

この章の内容は次のとおりです。

- 第4.1項「Oracle Fusion Middlewareの管理ツールについて」

- 第4.2項「Oracle Enterprise Manager Fusion Middleware Control」

- 第4.3項「Oracle WebLogic Server管理コンソール」

- 第4.4項「WebLogic診断フレームワーク(WLDF)」

- 第4.5項「WebLogic Scripting Tool (WLST)」

- 第4.6項「DMSスパイ・サーブレット」

- 第4.7項「オペレーティング・システムのネイティブ・パフォーマンス・コマンド」

- 第4.8項「ネットワーク・パフォーマンス・モニタリング・ツール」

注意:

このガイドの製品固有の章には、ほとんどの製品を対象とした追加の監視情報が含まれます。

4.1 Oracle Fusion Middlewareの管理ツールについて

Oracle Fusion Middlewareをインストールして構成した後、グラフィカル・ユーザー・インタフェースまたはコマンドライン・ツールを使用して環境を管理できます。

各ツールは『Oracle Fusion Middlewareの管理』の「Oracle Fusion Middleware管理ツールの概要」に説明されています。

注意:

Oracle Process ManagerおよびNotification Server (OPMN)はOracle Fusion Middlewareで使用されなくなりました。かわりに、システム・コンポーネントはWLST、ノード・マネージャおよび圧縮と圧縮解除などのWebLogic管理フレームワークにより管理されます。『Oracle Fusion Middlewareコンセプトの理解』の「WebLogic管理フレームワークとは」を参照してください。

4.1.1 パフォーマンス・メトリックの測定

メトリックは、シナリオをパフォーマンス目標と比較評価するための基準です。パフォーマンス・メトリックを使用すると、ボトルネックの特定やリソースの可用性に関する問題の検出が可能になります。また、コンポーネントをチューニングしてスループットおよびレスポンス時間を改善することもできます。パフォーマンス基準を決定したら、パフォーマンス目標を定量化するためのメトリックを測定します。

たとえば、レスポンス時間、スループットおよびリソース使用率をメトリックとして使用するとします。各メトリックのパフォーマンス目標となるのは、許容される値です。メトリックの実際の値を目標と照合し、パフォーマンス目標に達しているのか、あるいはパフォーマンス目標を上回っているのか、下回っているのかを確認します。

Oracle Fusion MiddlewareのコンポーネントやアプリケーションをFusion Middleware Controlで管理または監視する場合は、そのコンポーネントまたはアプリケーションの現在のパフォーマンスを詳しく分析するパフォーマンス・メトリックが使用されます。多くの場合、これらのメトリックは対話型グラフの形式で表示されますが、表形式で表示されることもあります。パフォーマンス・メトリックの使用や対比は、監視対象となるコンポーネントまたはアプリケーションの「パフォーマンス・サマリー」ページから行うことをお薦めします。

この後の項では、サーバーおよびアプリケーションのパフォーマンスの監視に使用できるOracle Fusion Middlewareのテクノロジおよびツールについて概説します。

Oracle Fusion Middlewareを初めて使用する場合や、「パフォーマンス・サマリー」ページを使用した環境の監視について詳しい情報が必要な場合は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareのパフォーマンスの表示に関する項を参照してください。また、Fusion Middleware Controlオンライン・ヘルプには、管理および監視のページで使用できる個々のパフォーマンス・メトリックの定義とその他の情報が記載されています。

4.2 Oracle Enterprise Manager Fusion Middleware Control

Fusion Middleware Controlは、ドメインの監視および管理に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。これは、1つのOracle WebLogic Serverドメインとその管理サーバー、1つ以上の管理対象サーバーの他に、クラスタ、ドメインにインストールされ、構成および実行されている複数のOracleミドルウェア・コンポーネント、およびデプロイするアプリケーションを管理します。

詳細は、『Oracle Fusion Middlewareの管理』のOracle Enterprise Manager Fusion Middleware Control使用の概要を参照してください。

4.3 Oracle WebLogic Server管理コンソール

Oracle WebLogic Server管理コンソールは、Oracle WebLogic Serverドメインの管理に使用する、Webブラウザ・ベースのグラフィカル・ユーザー・インタフェースです。これは、管理サーバーへのネットワーク・アクセスでサポートされるWebブラウザからアクセスできます。

WebLogic Serverコンソールの使用法の詳細は、『Oracle Fusion Middlewareの管理』のOracle WebLogic Server管理コンソール使用の概要に関する項を参照してください。

WebLogic Serverコンソールに関するその他のリソースを次に示します。

各サマリー表の内容の詳細は、WebLogic管理コンソール・オンライン・ヘルプの「サーバーの監視」を参照してください。

WebLogic Serverを使用したドメインの監視の詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。

4.4 WebLogic診断フレームワーク(WLDF)

WebLogic診断フレームワーク(WLDF)は、サーバーやアプリケーションで生成された診断データの収集が可能な監視および診断用のフレームワークです。WLDFは、データを収集して、ログ・レコード、データ・イベント、取得したメトリックなどの各種ソースに格納するように構成できます。

詳細は、『Oracle Fusion Middlewareの管理』の診断フレームワークの理解に関する項を参照してください。

注意:

WebLogic診断フレームワーク、およびOracle Fusion Middlewareコンポーネントの監視におけるWebLogic診断フレームワークの利用方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

4.5 WebLogic Scripting Tool (WLST)

Oracle WebLogic Scripting Tool (WLST)は、Oracle WebLogic Serverドメインの作成、管理および監視に使用するコマンドライン・スクリプト環境です。これは、Javaのスクリプト・インタープリタであるJythonがベースとなっています。ローカル変数、条件変数、フロー制御文などのJythonの標準機能のサポートのほかに、WLSTには、Oracle WebLogic Serverに固有のスクリプト関数(コマンド)セットが用意されています。Jythonの言語構文に従うことで、必要に応じてWebLogicのスクリプト言語を拡張できます。

詳細は、『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)使用の概要に関する項を参照してください。

4.6 DMSスパイ・サーブレット

DMSスパイ・サーブレットを使用すると、WebブラウザからDMSメトリック・データにアクセスできます。DMS対応のアプリケーションやコンポーネントで作成および更新されるデータは、DMSスパイ・サーブレットを通じてアクセス可能です。

4.6.1 スパイ・サーブレットを使用したパフォーマンス・メトリックの表示

DMSスパイ・サーブレットはDMS Webアプリケーションの一部です。DMS WebアプリケーションのWebアーカイブ・ファイルはdms.warで、dms.jarと同じディレクトリ/modules/oracle.dms_12.1.2/dms.warにあります。

デフォルトでは、DMS WebアプリケーションはJRF対応のサーバー・インスタンスの一部としてデプロイされます。URLはhttp://host:port/dms/Spyです。

管理者ロールのアクセス権限を持つユーザーのみがこのURLを表示できます。これは、web.xmlの標準的なJava EE要素によってアクセスが制限されているためです。

4.6.2 DMSスパイ・サーブレットの使用

図4-1に、スパイ・サーブレットの初期ページを示します。両側に同じメトリック表のリストが表示されています。

図4-1 スパイ・サーブレット・ページ - メトリック表

スパイ・サーブレットには、WebLogic Serverのメトリック表に加えて、デプロイされる非Java EEコンポーネントのメトリック表も表示されます。

メトリック表がスパイ・サーブレットに表示されるためには、その表の作成および更新を行うコンポーネントがインストールされ、稼働していることが必要です。稼働していないコンポーネントのメトリック表は表示されません。名前に:を含むメトリック表(weblogic_j2eeserver:app_overviewなど)は、メトリック・ルールによって生成された集計メトリック表です。

メトリック表の内容を表示するには、表の名前をクリックします。たとえば、図4-2はMDS_Partition表を示しています。

図4-2 MDS_Partition表

メトリック表のフィールドの説明を参照するには、表の下の「メトリック定義」リンクをクリックします。

4.7 オペレーティング・システムのネイティブ・パフォーマンス・コマンド

各オペレーティング・システムには、監視用の便利なネイティブ・ツールおよびユーティリティが用意されています。オペレーティング・システムのネイティブ・コマンドを使用すれば、CPU使用率、ページング・アクティビティ、スワッピング、その他のシステム・アクティビティ情報などを収集して監視することができます。

オペレーティング・システム・コマンドの詳細は、オペレーティング・システム・ベンダー提供のドキュメントを参照してください。

4.8 ネットワーク・パフォーマンス・モニタリング・ツール

オペレーティング・システムのネットワーク・モニタリング・ツールを使用すると、使用率の監視、ネットワークがボトルネックになっていないかどうかの確認、またはパケット損失やその他のネットワーク・パフォーマンスの問題の検出を行うことができます。ネットワーク・パフォーマンス監視の詳細は、オペレーティング・システムのドキュメントを参照してください。

5 Oracle Dynamic Monitoring Serviceの使用

この章では、Oracle Dynamic Monitoring Service (DMS)の概要および使用できる機能を示します。

- 第5.1項「Dynamic Monitoring Service (DMS)について」

- 第5.2項「DMSの可用性の理解」

- 第5.3項「DMSのアーキテクチャの理解」

- 第5.4項「DMSメトリックの表示」

- 第5.5項「WLDFを使用したDMSメトリックのアクセス」

- 第5.6項「DMS実行コンテキスト」

- 第5.7項「DMSトレースおよびイベント」

- 第5.8項「DMSベスト・プラクティス」

5.1 Dynamic Monitoring Service (DMS)について

Oracle Dynamic Monitoring Service (DMS)を使用すると、Oracle Fusion MiddlewareコンポーネントでOracle Enterprise Managerなどの管理ツールにコンポーネントのパフォーマンス、状態および進行中の動作に関するデータを提供できます。Fusion MiddlewareコンポーネントはDMSにデータをプッシュし、DMSは異なるコンポーネントの範囲でそのデータを公開します。DMSは、メトリック、トレース・イベントおよびシステム・パフォーマンスを測定および報告し、これらのコンポーネントのコンテキスト相関サービスを提供します。

5.1.1 共通のDMSの用語と概念の理解

この項では、次の内容に関連する共通のDMSの用語および概念を定義します。

- DMSセンサー

- DMSナウン

- DMSトレースおよびイベント

5.1.1.1 DMSセンサー

DMS センサーは、パフォーマンス・データを測定します。このセンサーによって、メトリックのセットの定義および収集が可能になります。メトリックには、センサーに常に含まれるものとオプションとして含まれるものがあります。

DMSには3種類のSensorがあります。

- 第5.1.1.1.1項「DMS PhaseEventセンサー」

- 第5.1.1.1.2項「DMSイベント・センサー」

- 第5.1.1.1.3項「DMS状態センサー」

5.1.1.1.1 DMS PhaseEventセンサー

DMS PhaseEventセンサーは、コード内の特定セクションの開始から終了までにかかる時間を測定します。あるメソッドまたはコード・ブロックの処理にかかる時間を追跡する場合は、PhaseEventセンサーを使用します。

DMSでは、PhaseEventセンサーの処理にかかる平均時間、最大時間、最小時間など、PhaseEventに関連するオプションのメトリックを計算できます。

表5-1に、PhaseEventセンサーで使用可能なメトリックを示します。

表5-1 DMS PhaseEventセンサーのメトリック

メトリック

説明

sensor_name.time

フェーズsensor_nameの処理にかかった合計時間を示します。

デフォルトのメトリック: timeは、PhaseEventセンサーのデフォルトのメトリックです。

sensor_name.completed

プロセスの開始以降にフェーズsensor_nameが完了した回数を示します。

オプションのメトリック

sensor_name.minTime

フェーズsensor_nameを完了させるたびにかかったすべての処理時間の中で、最短の時間を示します。

オプションのメトリック

sensor_name.maxTime

フェーズsensor_nameを完了させるたびにかかったすべての処理時間の中で、最長の時間を示します。

オプションのメトリック

sensor_name.avg

フェーズsensor_nameの平均処理時間を、(合計時間)/(フェーズが完了した回数)として計算します。

オプションのメトリック

sensor_name.active

DMS統計の収集時にフェーズsensor_nameにあったスレッドの数を示します(この値は時間の経過とともに変化します)。

オプションのメトリック

sensor_name.maxActive

プロセスの開始以降に、フェーズsensor_nameにあった同時スレッドの最大数を示します。

オプションのメトリック

5.1.1.1.2 DMSイベント・センサー

DMSイベント・センサーは、システム・イベントをカウントします。継続時間の短いシステム・イベントを追跡する場合や、イベントの継続時間よりもイベントの発生が重要な場合は、DMSイベント・センサーを使用します。

表5-2に、イベント・センサー関連のメトリックを示します。

表5-2 DMSイベント・センサーのメトリック

メトリック

説明

sensor_name.count

プロセスの開始以降にイベントが発生した回数を示します。sensor_nameは、DMSインスツルメンテーションAPIで指定されているEventセンサーの名前です。

デフォルト: countは、イベント・センサーのデフォルトのメトリックです。イベント・センサーでは、これ以外のメトリックは使用できません。

5.1.1.1.3 DMS状態センサー

DMS 状態センサーは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。サポートされている型は、integer、double、longおよびobjectです。システムのステータス情報を追跡する場合や、イベントに関係のないメトリックが必要な場合は、状態センサーを使用します。たとえば、状態センサーを使用して、キューの長さ、プール・サイズ、バッファ・サイズまたはホスト名を追跡します。状態センサーには、事前に計算された値を割り当てます。

表5-3に、状態センサーのメトリックを示します。状態センサーは、デフォルトのメトリックvalueおよびオプションのメトリックをサポートします。オプションのminValueメトリックおよびmaxValueメトリックは、状態センサーが(integer型、double型、long型などの)数値のJavaプリミティブを表す場合にのみ適用されます。

表5-3 DMS状態センサーのメトリック

メトリック

説明

sensor_name.value

sensor_nameの作成時に割り当てられた型を使用して、sensor_nameのメトリック値を示します。

デフォルト: valueは、Stateのデフォルトのメトリックです。

sensor_name.count

sensor_nameが更新された回数を示します。

オプションのメトリック

sensor_name.minValue

起動後のsensor_nameの最小値を示します。

オプションのメトリック

sensor_name.maxValue

起動後のこのsensor_nameの最大値を示します。

オプションのメトリック

5.1.1.1.4 センサーのネーミング規則

次のリストは、DMSセンサーのネーミング規則を示しています。

- センサー名は、簡潔で説明的なものにしてください。冗長になるのを避けるため、センサー名には、ナウン名の一部やナウン・タイプを含めないようにします。

- Sensor名には、個々のメトリックの値を含めないでください。

- センサーを説明するために複数の単語を組み合せる必要がある場合は、最初の単語は小文字で、以降の単語は大文字で始めます。たとえば、computeSeriesのようになります。

- 一般に、センサー名に「/」を使用することは避けてください。ただし、「/」を含む名前を使用することに意味がある場合もあります。ナウン名またはセンサー名に「/」を使用した場合は、そのセンサーをDMSメソッドの文字列で使用する際に、かわりのデリミタとして、パスにまったく存在しない「,」や「_」などを使用する必要があります。そうすることで、「/」はデリミタではなく、ナウン名またはセンサー名の一部であることが正しく認識されるようになります。
たとえば、次のような名前の子ナウンがあるとします。

examples/jsp/num/numguess.jsp

これは、次のような文字列を使用して検索できます。

,default,WEBs,defaultWebApp,JSPs,example/jsp/num/numguess.jsp,service

この場合のデリミタは「,」です。

- EventセンサーおよびPhaseEventセンサーの名前は、英単語を動詞+名詞という形式で組み合せて定義します。たとえば、activateInstanceやrunMethodのようになります。PhaseEventによって関数、メソッドまたはコード・ブロックを監視する場合は、実行されるタスクをできるだけ明確に反映した名前を使用します。

- 状態センサーの名前には名詞を使用します。場合によっては、この状態センサーで追跡する値の内容を説明する形容詞が前に付きます。たとえば、lastComputed、totalMemory、port、availableThreads、activeInstancesのようになります。

- 混乱を避けるため、.time、.value、.avgなどの文字列をセンサー名に使用しないでください。表5-1、表5-2および表5-3に示したとおり、これらはセンサー・メトリックの名前であるためです。

5.1.1.2 DMSナウン

DMSナウンはパフォーマンス・データを編成します。センサーは、関連付けられたメトリックとともに、ナウンに従って階層に編成されます。ナウンを使用すると、ファイル・システムのディレクトリ構造と同様の方法で、DMSメトリックを編成できます。たとえば、ナウンは、クラス、メソッド、オブジェクト、キュー、接続、アプリケーション、データベース、その他の測定の対象を表すことができます。

ナウン・タイプはナウンの種類を識別する属性です。エンティティと似たタイプを表すナウンは、一般に同じナウン・タイプを持ち、通常はそれらの各エンティティについて共通の測定セットを記録します。

5.1.1.2.1 一般的なDMSネーミング

ナウン名は、デリミタを含まない単純な文字列です。たとえば、BasicBinomialはナウン名です。ナウンのフルネームは、ナウン名にネームスペースとローカルパートを付けて構成されます。ナウン名の前に、その親のフルネームとデリミタが付きます。/dmsDemo/BasicBinomial/"{http://mynamespace/}JAXWSHelloService"はナウンのフルネームです。

センサー名は、「.」や派生を含まない単純な文字列です。たとえば、computeSeries、loopsおよびlastComputedはセンサー名です。

センサーのフルネームは、そのセンサーが関連付けられたナウンの名前、デリミタ、センサー名で構成されます。たとえば、/dmsDemo/BasicBinomial/computeSeries、/dmsDemo/BasicBinomial/loops、/dmsDemo/BasicBinomial/lastComputedなどです。

DMSメトリック名は、センサー名、「.」、メトリックで構成されます。たとえば、computeSeries.time、loops.countおよびlastComputed.valueは有効なDMSメトリック名です。

注意:

接尾辞.time、.countおよび.valueは変更できません。ただし、センサー名およびナウン名は必要に応じて変更可能です。

5.1.1.2.2 一般的なDMSネーミング規則とキャラクタ・セット

DMSの名前はできるだけ簡潔にしてください。また、ナウンやセンサーの名前を定義する場合は、特殊文字(空白、スラッシュ、ピリオド、カッコ、カンマ、制御文字など)を使用しないでください。

表5-4に、DMSの名前の中で特殊文字のかわりに使用する代替文字を示します。

表5-4 DMSの名前の中で特殊文字のかわりに使用する代替文字

文字

DMSの代替文字

空白文字

アンダースコア: _

ピリオド: .

アンダースコア: _

制御文字

アンダースコア: _

より小さい: <

開きカッコ: (

より大きい: >

閉じカッコ: )

アンパサンド: &

カレット: ^

二重引用符: "

バッククォート: '

一重引用符: '

バッククォート: '

注意:

Oracle Fusion Middlewareには、組込みメトリックがいくつか用意されています。Oracle Fusion Middlewareの組込みメトリックが、このDMSネーミング規則に常に従っているとはかぎりません。

5.1.1.2.3 ナウンおよびナウン・タイプのネーミング規則

ナウンおよびナウン・タイプのネーミングに次の規則が使用されます。

- ナウン名は一意である必要があります。

- ナウンには、特定のエンティティを識別する名前を付けてください。

- ナウン・タイプには、収集対象となるメトリックのセットを明確に表す名前を使用する必要があります。たとえば、Servletというナウン・タイプは、そのナウンで特定のサーブレットに固有のメトリックを収集することを示します。

- ナウン・タイプ名は、他のDMSの名前と区別するために大文字で始めてください。同じタイプのナウンはすべて、同じセンサーのセットを持ちます。

- ナウンのネーミング方式では階層のルートに「/」を使用し、各ナウンがルート、または親ナウンの下にあるコンテナとして機能します。

5.1.1.3 DMSトレースおよびイベント

概念的にはDMSはイベント・ストリームを生成し、その各イベントは、DMSと統合するコンポーネント(更新されるセンサーなど)によりDMS APIに対して実行された、いずれかのイベント作成アクションの応答です。このイベント・ストリームは完全に無視するか、またはなんらかの方法でイベントに応答できる宛先にルーティング(および、オプションでフィルタ)できます。

表5-5に、DMSトレースおよびイベントの用語のリストを示します。

表5-5 DMSトレースおよびイベントの用語

DMSの用語

定義

条件

条件は、条件フィルタのロジックです。条件で定義されたルールに基づいて、フィルタを通過するイベントを決定します。各条件フィルタにはゼロか1つのルート条件がありますが、ANDまたはOR引数を含めて複合条件を作成できます。単一のルート条件を使用して、比較的複雑なルールを示すことができます。

次の2つのタイプの条件が存在します。

- ナウン・タイプ条件 - センサーまたはナウン・イベントに関連するナウン・タイプの名前を操作します。

- コンテキスト条件 - 現在の実行コンテキスト内で現在設定されている値を操作します。

条件の使用の詳細は、第5.7項「DMSトレースおよびイベント」を参照してください。

宛先

宛先は、渡されるイベントに対応するメカニズムを実装します。たとえば、ファイルにイベントのログを記録できる宛先、Javaフライト・レコーダにイベントの変換されたコピーを送信できる宛先、MBeanのデータとして着信イベントから収集された情報をレンダリングする宛先などがあります。

イベント・ルート

イベント・ルートは、フィルタを宛先に接続します。イベント・ルートを有効または無効にできます。

フィルタ

イベント・トレース・フィルタは、すべての使用可能なDMSランタイム・イベントのサブセットを選択的に渡します。渡されるイベントとブロックされるイベントを決定するルールとともにフィルタを構成できます。

たとえば、次の目的でフィルタを定義できます。

- 実行コンテキストにキー値のペア「role」-「admin」がある場合に行われるセンサー更新のみ渡します。

- ナウン・タイプ「JDBC_Statement」からのセンサー更新のみ渡します。

フィルタの使用の詳細は、第5.7項「DMSトレースおよびイベント」を参照してください。

リスナー

DMSリスナーは、宛先とも呼ばれます。詳細は、第5.7.2項「宛先の構成」を参照してください。

5.2 DMSの可用性の理解

DMS機能をすべての認証されたJava EEサーバーで使用できます。これには、実行時機能およびサポートしているコマンドの両方が含まれます。また、DMSのいくつかの機能がJSEアプリケーションおよびスタンドアロンCアプリケーションで動作します。

動作保証されているサーバーの詳細は、Oracle Fusion Middlewareの動作保証マトリクスを参照してください。

5.3 DMSのアーキテクチャの理解

DMSは、次の機能で構成されます。

- DMSメトリック - DMSメトリック機能は、パフォーマンス測定および他の便利な状態メトリックでコードのインスツルメンテーションを行うためにOracle Fusion Middlewareコンポーネントで使用されるJavaおよびC APIを用意しています。

- 実行コンテキスト - 実行コンテキストは、Oracleスタック全体の特定のコンテキスト構造のメンテナンスおよび伝播をサポートします。伝播されたコンテキスト構造を利用することにより、Oracle FMWコンポーネントは同じまたは異なるサーバーおよびホスト上で実行される様々なコンポーネントや製品間で相関可能な診断情報(ログ・レコードなど)を記録できます。詳細は、第5.6項「DMS実行コンテキスト」を参照してください。

- イベントおよびトレース - イベント・トレースにより、再起動しないでライブ・トレースを構成できます。Oracle Fusion Middleware製品の使用中に更新されたDMSメトリックは、DMSイベント・トレース機能でトレースされる場合があります。システムは、トレースを容易にするだけではなくDMSアクティビティから起動する可能性がある他の機能もサポートするよう設計されています。

図5-1は、DMSのコンポーネントおよび他のOracle Fusion Middlewareコンポーネントとの対話方法を示しています。矢印は、コンポーネント間の情報フローの方向を示しています。

図5-1 Oracle Fusion MiddlewareコンポーネントとDMSの相互作用

5.4 DMSメトリックの表示

開発者、システム管理者およびサポート・アナリストがシステム・パフォーマンスの分析やシステム・ステータスの監視を実行できる情報を収集するため、Oracle Fusion Middlewareコンポーネントは、DMSメトリックでインスツルメンテーションを行います。Fusion Middleware Controlオンライン・ヘルプは、特定のメトリックごとの情報を示します。メトリック情報へのアクセスの詳細は、『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareのパフォーマンスの表示に関する項を参照してください。

Oracle Fusion Middlewareメトリックは、様々なソースおよび場所から発生します。これには、MBean属性およびDMSメトリックが含まれます。また、Oracle HTTP Serverなどの非Java EEサーバーからも発生します。

次の各項では、DMSメトリックを表示する様々なツールの使用方法について説明します。

- スパイ・サーブレットを使用したメトリックの表示

- WLDF (WebLogic診断フレームワーク)を使用したメトリックの表示

- WLST (Oracle WebLogic Server)を使用したメトリックの表示

- JConsoleを使用したメトリックの表示

- Oracle Enterprise Managerを使用したメトリックの表示

5.4.1 スパイ・サーブレットを使用したメトリックの表示

スパイ・サーブレットは、JRF拡張インストールでデフォルトでデプロイされるDMSアプリケーションの一部です。http://<host>:<port>/dms/Spyからスパイ・サーブレットが起動します。WebLogicのデフォルト・ポートは1521です。

DMSアプリケーションのWebアーカイブ・ファイルはdms.warで、dms.jar: oracle_common/modules/oracle.dms_12.1.2/dms.warと同じディレクトリにあります。

詳細は、第4.6項「DMSスパイ・サーブレット」を参照してください。

注意:

スパイ・サーブレットはWebアプリケーションのweb.xmlファイルの標準のJava EEの宣言型セキュリティで保護され、管理者グループのメンバーだけにスパイ・サーブレットのアクセス権限を付与します。

5.4.2 WLDF (WebLogic診断フレームワーク)を使用したメトリックの表示

WebLogic診断フレームワーク(WLDF)を使用して、DMSメトリックMBeanからDMSメトリックを収集できます。WLDFを使用して、MBeanの属性値の変更も監視できます。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使い方』のメトリック・コレクションのハーベスタの構成に関する項を参照してください。

5.4.3 WLST (Oracle WebLogic Server)を使用したメトリックの表示

DMSには、WLSTでメトリックを表示する次の3つのコマンドがあります。

使用するコマンド

操作

displayMetricTableNames()

使用できるメトリック表の名前を示します。

多数のDMSメトリック表がある場合は、displayMetricTableNames()でoutputfileパラメータを使用することを検討してください。これは、出力が大きくなることが予想される場合に有用です。displayMetricTableNames()にoutputfileパラメータがある場合は、スクリプトには出力全体のかわりにNULLが返されます。これによりコマンドのメモリー不足を回避します。

注意: 12cでは、displayMetricTableNames()のコマンド構文はシステム・コンポーネント(OHSなど)の場合、多少異なります。nmConnect()コマンドを使用してWLSTをノード・マネージャに接続した後で、サーバー名とサーバー・タイプの両方を明示的に指定する必要があります。

例:

displayMetricTableNames(servertype="OHS", servers="ohs1")

displayMetricTables()

DMSメトリック表の内容を示します。

多数のDMSメトリック表がある場合は、displayMetricTables()でoutputfileパラメータを使用することを検討してください。これは、出力が大きくなることが予想される場合に有用です。displayMetricTables()にoutputfileパラメータがある場合は、スクリプトには出力全体のかわりにNULLが返されます。これによりコマンドのメモリー不足を回避します。

注意: 12cでは、displayMetricTables()のコマンド構文はシステム・コンポーネント(OHSなど)の場合、多少異なります。nmConnect()コマンドを使用してWLSTをノード・マネージャに接続した後で、サーバー名とサーバー・タイプの両方を明示的に指定する必要があります。

例:

displayMetricTables(servertype="OHS", servers="ohs1")

dumpMetrics()

内部形式でメトリックを表示します。dumpMetricsコマンドの有効な形式には、RAW、XMLおよびPDMLがあります。

多数のDMSメトリック表がある場合は、dumpMetrics()でoutputfileパラメータを使用することを検討してください。これは、出力が大きくなることが予想される場合に有用です。dumpMetrics()にoutputfileパラメータがある場合は、スクリプトには出力全体のかわりにNULLが返されます。これによりコマンドのメモリー不足を回避します。

注意: 12cでは、dumpMetrics()のコマンド構文はシステム・コンポーネント(OHSなど)の場合、多少異なります。nmConnect()コマンドを使用してWLSTをノード・マネージャに接続した後で、サーバー名とサーバー・タイプの両方を明示的に指定する必要があります。

例:

dumpMetrics()(servertype="OHS", servers="ohs1")

これらのコマンドは、テキスト出力を表示して、スクリプトの処理に使用できる構造化オブジェクトまたは単一の値も戻します。

これらのコマンドの使用の詳細は、次の項を参照してください。

- 『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)使用の概要に関する項

- 『WebLogic Server WLSTコマンド・リファレンス』のDMSカスタムWLSTコマンドに関する項

5.4.4 JConsoleを使用したメトリックの表示

メトリックにアクセスする標準ベースの手段を提供するため、DMSはMBeanを通じてメトリックを公開します。ランタイムMBeanサーバーで入力された各ナウンにMBeanが作成および登録されます。ナウンに含まれるDMSセンサーがMBeanの属性として公開されます。MBeanとしてDMSメトリックを公開すると、管理者はJConsole (Java監視および管理コンソール)などのツールを使用でき、他のJava Management Extension (JMX)クライアントはDMSメトリックにアクセスできます。

第5.5項に示すとおり、MBeanはWLDF (WebLogic診断フレームワーク)などの他のOracle診断ソフトウェアと統合することもできます。ナウン名およびナウン・タイプは、メトリックMBeanオブジェクト名の名前およびタイプ・プロパティとして公開されます。MBeanドメイン名はoracle.dmsです。オブジェクト名はDMSナウン階層も反映します。

注意:

JConsoleを使用すると、DMSで生成されたMBeanをJava EEサーバーでローカルまたはリモートに表示できます。DMSは、有効なナウン・タイプを持つ各Java DMSナウンのMBeanを生成します。非Java EEコンポーネントのメトリックおよびナウン・タイプを持たないDMSナウンのMBeanは生成しません。ナウンに含まれる各DMSメトリックがメトリックMBeanの属性にマップされます。

5.4.5 Oracle Enterprise Managerを使用したメトリックの表示

Oracle Fusion Middlewareは、コンポーネントのパフォーマンス、状態および進行中の動作に関するデータを自動的および継続的に測定します。メトリックが自動的に有効になるので、オプションの設定やメトリックを収集する余分な構成の実行は必要ありません。詳細は、第4.2項「Oracle Enterprise Manager Fusion Middleware Control」を参照してください。

5.5 WLDFを使用したDMSメトリックのアクセス

WebLogic診断フレームワーク(WLDF)には、特定の条件でMBean属性を収集および監視できる診断機能が用意されています。これにより、条件がトリガーされた場合に環境のアクティビティの監視と電子メールおよびJMX通知の作成を事前に行う手段が提供されます。

次の手順は、WLDFを構成してWebLogic管理コンソールで電子メール通知を送信する方法を示しています。

1. 「診断」画面から既存の診断モジュールを選択するか、新しい診断モジュールを作成します。

2. 「監視と通知」タブをクリックします。

3. 「新規」をクリックします。

4. 監視名を入力して、「次へ」をクリックします。

5. 監視ルールのテキストを入力して、「次へ」をクリックします。

(${ServerRuntime//[NOUNTYPE]oracle.dms:name=/starWars/alliance,type=NounType//forceBalance_value} = 'BAD')

6. 「手動リセットのアラームを使用する」を選択して、「次へ」をクリックします。手動リセット・オプションは、電子メールがトリガーされた後にWebLogic管理コンソールを使用して監視をリセットする必要があることを意味します。

7. 電子メール通知タイプを選択して、「終了」をクリックします。

また、WLDFを構成して、オフラインの格納および分析のためにMBeanデータを収集できます。特定のMBean属性を収集するためにWLDF診断モジュールを構成してこれを実施し、WebLogic管理コンソールを使用して実行できます。

WLDFを使用したMBeanデータの収集および監視の詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

5.6 DMS実行コンテキスト

DMS実行コンテキストは、リクエスト(HTTPまたはRMIリクエストなど)を一意に識別してシステム内での動向を追跡できるメカニズムです。リクエストの遂行に含まれる連携しているFusion Middlewareコンポーネントの間でコンテキスト情報を通信できる手段も提供します。

5.6.1 DMS実行リクエストおよびサブタスク

リクエストまたはルート・タスクを完了するために調整されるサブタスクのツリーのルートが単一のリクエスト(またはタスク)で構成できることを考慮して、DMS実行コンテキストが開発されています。リクエストおよび関連するサブタスクの次の例を検討してください。

1. ブラウザから直接Oracle WebLogic Serverに送信されるHTTPリクエスト

- Oracle WebLogic Serverのルート・タスクのみ

2. リバース・プロキシとして動作するOracle HTTP ServerからOracle WebLogic Serverに送信されるHTTPリクエスト

- Oracle HTTP Serverのルート・タスク

- Oracle WebLogic Serverの単一のサブタスク

3. リバース・プロキシとして動作するOracle HTTP ServerからOracle WebLogic Serverに送信され、リクエストを遂行するためにOracle WebLogic Serverから2つのリモートWebサービスの呼出しが必要になるHTTPリクエスト

- Oracle HTTP Serverのルート・タスク

- Oracle WebLogic Serverの単一のサブタスク

- Webサービスごとの合計2つのサブタスク

DMS実行コンテキストは、次の内容で構成されます。

- 一意の識別子のECID
実行コンテキストID (ECID)は新しいルート・タスクごとに一意で、ルート・タスクに関連するタスクのツリーで共有されます。

- リレーションシップ識別子のRID
リレーションシップID (RID)は、タスクのツリーで各タスクの場所を示す順序付けされた数値の集合です。先頭の数値は通常ゼロです。先頭の数値の1は、全体のサブタスク・ツリー内でサブタスクの場所を追跡できないことを示します。

- グローバル関連データをOracle Fusion Middlewareコンポーネントで共有できる名前/値ペアのセット

次の3つのシナリオは、HTTPリクエストがリバース・プロキシとして動作するOracle HTTP ServerからOracle WebLogic Serverに送信され、Oracle WebLogic Serverから2つのリモートWebサービスの呼出しが必要になる場合のECIDおよびRIDの使用方法を示しています。

1. Oracle HTTP Serverのルート・タスク

- 新しいECID = B5C094FA...BE4AE8

- ルートRID = 0

2. Oracle WebLogic Serverの単一のサブタスク

- 同じECID = B5C094FA...BE4AE8

- サブタスクRID = 0:1

3. Webサービスごとの合計2つのサブタスク

- 起動される最初のWebサービス
同じECID = B5C094FA...BE4AE8

サブタスクRID = 0:1:1

- 起動される2番目のWebサービス
同じECID = B5C094FA...BE4AE8

サブタスクRID = 0:1:2

5.6.2 DMS実行コンテキストの使用

サーバー間のログ・メッセージを関連付けると、DMS実行コンテキストの最も直接的な利点がわかります。ロギングのOracle標準形式には、ECID専用フィールドが含まれます。エラー・レベルのログ・メッセージからの読込みなどでECIDを確認した後、そのECIDを含むメッセージのログ・ファイルを問い合せて、タスクに関連する他のすべてのログ・メッセージを検索できます。

コマンドを使用する非常に特殊なケースの例を次に示します。

displayLogs(ecid="B5C094FA...BE4AE8");

この例では、ECID B5C094FA...BE4AE8を含むメッセージのログ・ファイルが表示されます。

5.6.3 DMS実行コンテキストの通信

図5-2は、DMS実行コンテキストを相互に通信するために連携するコンポーネントを示しています。コンポーネントを参照する矢印は、受信コンテキスト情報を検証するプロトコルを示します。外側の矢印は、コンテキスト情報が追加されるプロトコルを示します。単一のコンポーネントが自身にリクエストを送信し、そのリクエストにコンテキスト情報を渡すことできます。

図5-2 DMS実行コンテキストの通信プロトコル

5.7 DMSトレースおよびイベント

DMSは次のものを選択的にトレースできます。

- DMSセンサー・ライフサイクル・イベント(状態センサー、イベント・センサーおよびフェーズ・センサーの作成、更新、削除)

- コンテキスト・イベント(開始、停止)

- HTTPイベント(開始、停止)

これらのタイプのイベントのトレースおよび処理方法を制御する構成がdms_config.xmlファイルに記録されます。DMSトレース構成は、次の3つに分類されます。

1. フィルタ構成
特定のイベントを選択するルールを定義します。

2. 宛先構成
イベントの使用方法を定義します。

3. イベント・ルート構成
使用するフィルタおよび接続する宛先を定義します。

フィルタを1つ以上の宛先に関連付けることができるので、管理者は一度フィルタ・ルールを定義して1つ以上の異なる宛先で処理されるすべての使用可能なイベントの結果サブセットを利用できます。

実行時にDMS構成MBeanまたはWLSTコマンドを使用して、構成を変更できます。このため、特定の期間に発生する問題の診断や特定の基準セットを使用した特定の時間の特定のデータの収集にDMSトレース機能が非常に役立ちます。

詳細は、『Oracle Fusion Middlewareの管理』のWLSTを使用した選択的トレースの構成に関する項を参照してください。

次のタイプのフィルタ・ルールがサポートされます。

- イベント・タイプ条件
イベントがPHASE_SENSORのSTARTまたはSTOPからトリガーされているかどうかを識別するために使用されます。

- コンテキスト・タイプ条件
コンテキストに値(「USER」など)が含まれる作業単位からイベントが生成されたかどうかを識別するために使用されます。

- ナウン・タイプ条件
ナウンが特定のタイプ(JDBC_CONNECTIONなど)のセンサーからイベントがトリガーされたかどうかを識別するために使用されます。

- 前述の条件の論理ANDおよびORの組合せ

5.7.1 DMSイベント・システムの構成

構成は、各サーバーのdms_config.xmlファイルに記録されます。コマンドライン・インタフェース(CLI)コマンドおよびイベント構成Mbeanを使用して、実行時にMBeanを更新できます。スレッド・セーフの非アトミックの方法で構成の更新が実行中のシステムに適用されます。

DMSイベント構成MBeanのオブジェクト名は、oracle.dms.event.config:name=DMSEventConfigMBean,type=JMXEventConfigです。

システムのDMSイベント構成の現在の状態を確認するには、次のコマンドを使用します。

listDMSEventConfiguration([server=<server>])

出力結果は次のようになります。

Event routes:
FILTER      :  auto662515911
DESTINATION :  destination1
ENABLED     :  true
FILTER      :  filter0
DESTINATION :  q
ENABLED     :  true
Filters with no event route:
Fred

Destinations with no event route:
des4

5.7.1.1 フィルタの追加および編集

フィルタは、トレースに検討するイベントを選択するルールを定義します。

次の例は、JDBC操作に関連するすべてのイベントを選択するフィルタの追加方法を示しています。

addDMSEventFilter(id='myJDBCFilter', props={'condition': 'NOUNTYPE sw JDBC_'})

または

addDMSEventFilter(id='myJDBCFilter', props={'condition': 'NOUNTYPE startsWith JDBC_'})

このフィルタは、JDBC操作に関連するすべてのDMSセンサーの更新が名前が「JDBC_」で始まるタイプのナウンに実行されると仮定します。

ルールを変更する必要がある場合、次の例のようにフィルタを更新できます。

updateDMSEventFilter(id="myJDBCFilter", props={'condition': 'NOUNTYPE startsWith JDBC_ OR NOUNTYPE startsWith MDS_'});

Oracle Fusion Middleware 11.1.1.6.0から、次の短縮された便利な演算子が追加されています。演算子は、短縮名または詳細名のいずれかを使用して指定できます。

アンダースコアが付いている演算子は非推奨になっているため、大文字と小文字の両方を使用するODL形式をお薦めします。たとえば、not_equalsはnotEqualsまたはneになります。古い形式でも機能しますが、推奨されていません。

ナウン・タイプ演算子

equals、eq

notEquals、ne

contains

in

startsWith、sw

コンテキスト演算子

equals、eq

notequals、ne

isnull

isnotnull

startswith、sw

contains

lt

gt

例:

addDMSEventFilter(id='mdsbruce', name='MyFilter', props={'condition':
'NOUNTYPE eq MDS_Connections AND CONTEXT user ne bruce'})

addDMSEventFilter(id='mdsbruce', name='MyFilter', props={'condition':
'NOUNTYPE equals MDS_Connections AND CONTEXT user notequals bruce'})

フィルタのルール(条件プロパティ)を示すために使用される構文の詳細は、WebLogic Scripting Toolコマンド・リファレンスまたはコマンド・ヘルプを参照してください。

5.7.1.2 宛先の追加および編集

宛先は、イベントに対応するロジックをカプセル化します。たとえば、基本の宛先でイベントのログを記録し、異なる宛先でイベントを変換して別のシステムに渡して追加処理を実行できます。

次の例は、イベントのログを記録する宛先の追加方法を示しています。

addDMSEventDestination(id="myLoggerDestination", class="oracle.dms.trace2.runtime.LoggerDestination", props={"loggerName":"myLogger"});

宛先の追加だけではイベントのログを記録できないので、イベント・ルートを使用してフィルタと宛先を関連付け、イベント・ルートを有効(デフォルト)にする必要があります。

使用できる宛先のタイプおよび構成オプションを第5.7.2項に示します。次の例は、既存の宛先の編集方法を示しています。

updateDMSEventDestination(id="myLoggerDestination", props={"loggerName":"myTraceLogger"});

5.7.1.3 イベント・ルートの追加および編集

次の例は、上記で作成されたフィルタおよび宛先の結合方法を示しています。

addDMSEventRoute(filterid='myJDBCFilter', destinationid='myLoggerDestination')

明示的なフィルタIDを使用しないでaddDMSEventRouteを起動できます。これらのシナリオでは、すべてのイベントがフィルタなしで宛先に渡されます。

フィルタまたは宛先を削除するには、フィルタまたは宛先に関連するイベント・ルートを無効になっていても最初に削除する必要があります。たとえば、myJDBCFilterを削除する場合、次の例に示すように、前の例で作成したイベント・ルートを最初に削除してからフィルタを削除する必要があります。

removeDMSEventRoute(filterid='myJDBCFilter', destinationid='myLoggerDestination')
removeDMSEventFilter(id='myJDBCFilter')

5.7.1.4 複合操作

第5.7.1.3項のように2つの個別のコマンドではなく単一のコマンドを使用して、フィルタおよびそのフィルタに基づくイベント・ルートを作成できます。ただし、イベント・ルートで使用される宛先が事前に定義されている必要があります。

enableDMSEventTrace (destinationid='myLoggerDestination', condition='NOUNTYPE starts_with JDBC_')

前述の例で、enableDMSEventTraceは、指定された条件でフィルタを自動的に作成し、新しいフィルタおよび指定された宛先を使用してイベント・ルートを作成および有効化できます。次に、出力例を示します。

Filter "auto605449842" using Destination "myLoggerDestination" added, and event-route enabled for server "AdminServer"

5.7.2 宛先の構成

DMSは、次のタイプの宛先を提供します。

- LoggerDestination

- MBean Creatorの宛先

- HTTPリクエスト・トラッカの宛先

- Javaフライト・レコーダの宛先

5.7.2.1 LoggerDestination

説明

LoggerDestinationは、各イベントを関連するロガーに書き込みます。

実装クラス

oracle.dms.trace2.runtime.LoggerDestination

プロパティ

loggerName

イベントが書き込まれるODLロガーの名前。

ロガー宛先のインスタンスは、イベントをFINERログ・レベルの名前が付いたロガーに書き込みます。

loggerNameプロパティにロガーの名前を指定しますが、必ずしもロガーをlogging.xmlに示す必要はありません。ロガー名がlogging.xmlで明示的に名前が付けられているロガーを示す場合、そのロガーは静的ロガーと呼ばれます(第5.7.2.1.1項を参照してください)。ロガー名がlogging.xmlで明示的に名前が付けられていないロガーを示す場合、そのロガーは動的ロガーと呼ばれます(第5.7.2.1.2項を参照してください)。

デフォルト構成の使用: デフォルト構成は、LoggerDestinationを確認してロガー宛先を定義します。この特定のインスタンスはイベント・ルートの一部を構成しないので、アクティブではありません。便宜上提供され、動的ロガーを使用します。

5.7.2.1.1 静的ロガーおよびハンドラ

ロガーは、ログの記録が示されるオブジェクトです。ログ・ハンドラは、ログの記録がログ・ファイルに書き込まれるオブジェクトです。

DMSトレース・データが書き込まれるログ・ファイルを完全に制御するには、logging.xmlのロガー宛先の名前のロガーを定義します。これを実行すると、ログ・ファイルの名前、最大サイズ、形式、ファイル・ローテーションおよびポリシーを明示的に定義できます。

次の例のようなコマンドを使用して構成を更新することをお薦めします。

setLogLevel(logger="myTraceLogger", level="FINER", addLogger=1);

configureLogHandler(name="my-trace-handler", addToLogger=["myTraceLogger"], path="/tmp/myTraceLogFiles/trace", maxFileSize="10m", maxLogSize="50m", handlerType="oracle.core.ojdl.logging.ODLHandlerFactory", addHandler=1, useParentHandlers=0);

configureLogHandler(name="my-trace-handler", propertyName="useSourceClassandMethod", propertyValue="false", addProperty=1);

ロギング構成の詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルおよび診断データの管理に関する項を参照してください。

オプションのプロパティuseSourceClassandMethodを使用してFALSEに設定すると、「SRC_CLASS」および「SRC_METHOD」が各メッセージに表示されなくなり、ファイルの出力時間が短縮されてパフォーマンスがわずかに改善します。

静的ロガーの場合、useParentHandlersパラメータをFALSEに設定することを検討してください。そうしない場合、重複したイベント・メッセージが[server]-diagnostics.logにログとして記録され、ログの問合せに表示されます。

ロガー出力の解釈の詳細は、第5.7.3項「ログ・メッセージのDMSイベント・フォーマットの理解」を参照してください。

5.7.2.1.2 動的ロガーおよびハンドラ

名前が付いたロガーにlogging.xmlに定義されたハンドラが関連付けられていない場合、サーバーのデフォルトのログ出力ディレクトリにあるファイルに書き込むハンドラ・オブジェクトがロガー宛先によって動的に作成されます。(ロガー宛先のインスタンスは、イベントをFINERログ・レベルの名前が付いたロガーに書き込みます。)ファイル名は、ロガー名の後に「-event.log」が付きます。たとえば、第5.7.2.1.1項の例では、DMSイベントは「myTraceLogger-event.log」に書き込まれます。

5.7.2.1.3 logging.xmlファイルのデフォルトの場所

logging.xmlファイルは、一般的に次のプラットフォームの場所のいずれかにあります。

プラットフォーム

サーバー

場所

Oracle WebLogic Server

AdminServer

ORACLE_HOME/WLS_Home/user_projects/domains/base_domain/config/fmwconfig/servers/AdminServer/logging.xml

5.7.2.1.4 CLIコマンドを使用したトレース・ログ・ファイルの問合せ

ロガー宛先のロガーおよびハンドラがlogging.xmlに定義されている場合、displayLogs()コマンドを利用して、手動で特定または検索することなくログに記録されたトレース・データに適切にアクセスできます。

例:

- myTraceLoggerのすべてのログ・メッセージを表示するには、次のコマンドを実行します。

displayLogs(query='MODULE equals myTraceLogger')

- ECIDが「0000HpmSpLWEkJQ6ub3FEH194kwB000004」のmyTraceLoggerのログ・メッセージのみを表示するには、次のコマンドを実行します。

displayLogs(query='MODULE equals myTraceLogger and ECID equals 0000HpmSpLWEkJQ6ub3FEH194kwB000004')

- 最後の10分のECIDが「0000HpmSpLWEkJQ6ub3FEH194kwB000004」のmyTraceLoggerのログ・メッセージのみを表示するには、次のコマンドを実行します。

displayLogs(query='MODULE equals myTraceLogger and ECID equals 0000HpmSpLWEkJQ6ub3FEH194kwB000004', last=10)

- 動的ロガーのすべてのログ・メッセージを表示するには、ログのファイル名を含める必要があります。

displayLogs(disconnected=1, log=DOMAIN_ROOT+"/servers/AdminServer/logs/myTraceLogger-event.log")

5.7.2.2 MBean Creatorの宛先

説明

MBean Creatorの宛先を使用すると、WLDF、JConsoleなどを使用したアクセスのためにナウンがMBeanとしてアクセス可能になり、属性としてそのメトリックを公開します。

実装クラス

oracle.dms.jmx.MetricMBeanFactory

デフォルト構成の使用: MBean Creatorの宛先のインスタンスが構成されてデフォルトでアクティブになり、サーバーに作成されたすべてのナウンのMBeanが作成されます。

この宛先タイプのインスタンスをナウン・タイプのルールに基づくフィルタに関連付けると、管理者が指定するナウン・タイプのみをMBeanとして公開できます。

実行時にMBean Creatorの宛先に関連付けられた構成を変更できますが、このタイプの宛先の再初期化プロセスがパフォーマンスに影響する可能性があることを理解する必要があります。そのため、頻繁な実行時の再構成は推奨されていません。

WebLogic診断フレームワーク(WLDF)を使用すると、MBean Creator宛先で公開されるDMSメトリックを収集できます。WLDFの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

5.7.2.2.1 メトリックMBeanのオブジェクト名

ナウン名およびナウン・タイプは、メトリックMBeanオブジェクト名の名前およびタイプ・プロパティとして公開されます。MBeanドメイン名はoracle.dmsです。オブジェクト名はDMSナウン階層も反映します。

たとえば、ナウンのフルパス名は次のとおりです。

/oracle/dfw/ofm/base_domain/AdminServer

ナウン・タイプはDFW_Incidentで、ナウンを表すMBeanのオブジェクト名は次のとおりです。

oracle.dms:Location=AdminServer,name=/oracle/dfw/ofm/base_domain/AdminServer,type=DFW_Incident

5.7.2.3 HTTPリクエスト・トラッカの宛先

説明

HTTPリクエスト・トラッカの宛先は、アクティブなHTTPリクエストのリストを保持し、リクエストを他の診断フレームワーク(DFW)コンポーネントでアクセス可能にします。

実装クラス

oracle.dms.event.HTTPRequestTrackerDestination

プロパティ

excludeHeaderNames

追跡から除外されるヘッダー名のカンマ区切りのリスト

デフォルト構成の使用: HTTPリクエスト・トラッカ宛先のインスタンスはデフォルトで有効です。生成されるDFWインシデントの場合、アクティブなHTTPリクエストのリストが自動的にダンプされるので、管理者は障害と特定のリクエストを相互に関連付けることができます。

HTTPリクエストごとに次の情報がダンプされます。

- Uniform Resource Identifier (URI)

- リクエストの開始時間

- 実行コンテキストID (ECID)

- 問合せ文字列

- HTTPヘッダー

HTTPリクエスト・トラッカが有効ではない場合、HTTPリクエスト・ダンプが次の内容を出力します。

HTTP Requests are not being tracked. To enable HTTP request tracking enable the DMS oracle.dms.event.HTTPRequestTrackerDestination in dms_config.xml

5.7.2.3.1 HTTPリクエスト・トラッカのダンプの実行

HTTPリクエスト・トラッカに保持される情報に手動でアクセスできます。HTTPリクエスト情報を報告するダンプを実行するには、サーバーの接続時に次のようにWLST executeDumpコマンドを使用できます。

> executeDump(name="http.requests")
Active Requests:

StartTime: 2009-12-14 02:24:41.870
ECID: 0000IMChyqEC8xT6uBf9EH1B9X9^000009,0
URI: /myApp/Welcome.jsp
QueryString:
Headers:
Host: myHost.myDomain.com:7001
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.249.30 Safari/532.5
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate
Cookie: ORA_MOS_LOCALE=en%7CGB; s_nr...
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

5.7.2.4Javaフライト・レコーダの宛先

Javaフライト・レコーダ(JFR)は、Java JVM.の実行時ステータスおよび動作に関する情報を記録します。JFRは、サード・パーティ・イベントを報告できるAPIも公開します。

DMSは独立してトレースし、JFRはサーバーで実行されているアクション全体の表示部分のみをトレースします。JFRとDMSの統合は、次に示すように管理者と開発者が使用できる診断情報を拡張します。

1. アプリケーション・レベル・イベントおよびJVMレベル・イベントを1つの手順として報告できるので、タイムスタンプだけに基づいて個別のログ・ファイルからこのようなイベントを結合する必要がなくなります(同時に作成されるイベントを正確に順序付けできるほど迅速に動作しない場合があります)。

2. 任意にJVMから遡及して最近のDMSアクティビティをダンプできます。

3. JVMを正常に終了させる致命的なエラーの場合、最近のDMSおよびJVMイベントをディスクにダンプできます。

4. DMS ECIDを使用すると、JFR記録期間に同じリクエストに関連するアクティビティ(作業単位)を相互に関連付けることができます。

5. DMS ECIDを使用すると、JFRで記録される単一および一連のイベントに関連するすべてのシステムの診断情報を収集できます。

5.7.2.4.1 動的に導出されたJFRイベント・タイプ - 名前、値および説明

DMSナウン・タイプは、JFR InstantEventイベント・タイプに関連付けられます。

- ナウン・タイプのJFRイベント・タイプの名前は、接尾辞「state」の付いたナウン・タイプの名前になります。

- ナウン・タイプのJFRイベント・タイプのパスは、「dms/」、プロデューサ名、イベント・タイプ名の順に付けられます。

- イベント・センサーは、値をナウン・タイプのJFRイベント・タイプに提供しません。

- ナウン・タイプのJFRイベントの値を表5-6に示します。

表5-6 ナウン・タイプのJFRイベントの値

値の名前

説明

リレーショナル

注意

ECID

アクションに関連付けられた実行コンテキストID (ECID)。

はい

RID

アクションに関連付けられたRID。

はい

<ナウン・タイプ>名

ナウンのフルパス。

このフィールドは、ナウンのフルパスに移入されます。フィールドの名前は、noun_typeを使用してそのタイプのナウンで測定されているすべてのオブジェクトが適切に分類されていると仮定します。

<state-sensor-name>

状態センサーの値。

いいえ

ナウンに属する各状態センサーは、これらの値のいずれかを即時イベントに提供します。各ナウンに複数の値が存在する場合があります。

イベント名

更新されたイベント・センサーの名前(それ以外の場合はnull)。

いいえ

DMSイベント・センサーが更新された回数を記録するには、イベント名フィールドが必要です(イベント・センサーは値をイベント・タイプに提供しません)。

DMSフェーズ・センサーは、JFR DurationEventイベント・タイプに関連付けられます。

- 特定のナウン・タイプのナウンに属しているフェーズ・センサーのJFRイベント・タイプの名前は、後にフェーズ・センサーの名前が付けられるナウン・タイプの名前になります。

- ナウン・タイプのJFRイベントのパスは、「dms/」、プロデューサ名、イベント・タイプ名の順に付けられます。

- 期間イベントの値は前述のようになります(sensorName値を除きます)。たとえば、フェーズ・イベントの「停止」がフェーズ・イベントの親ナウンの状態情報を含むJFRに報告されるJFR期間イベントになります。

いくつかのDMSオブジェクトにより、インテグレータで説明を追加できます。DMSオブジェクトの説明は、次のように使用されます。

- ナウン・タイプの説明は、JFRイベント・タイプの作成に使用されます。

- 状態およびイベント・センサーの説明は適用されず、適用される場所はありません。

- フェーズ・センサーの説明がJFRイベント・タイプに適用されます。

5.7.2.4.2 動的に導出されたプロデューサおよびイベントの例

表5-7は、第5.7.2.4.1項で説明されているルールの例を示しています。

表5-7 動的に導出されたプロデューサおよびイベントの例

DMS

Javaフライト・レコーダ(JFR)

ナウン・タイプ:

JDBC_Connection

ナウン・パス:

/JDBC/Driver/CONNECTION_7

センサー:

CreateStatement (P)

CreateNewStatement (P)

DBWaitTime (P)

JDBC_Connection_Url (S)

JDBC_Connection_Username (S)

各値の説明は次のとおりです。

P: フェーズ・センサー

S : 状態センサー

E : イベント・センサー

プロデューサ名: JDBC

プロデューサ名は、ナウン・パスの先頭のコンポーネントに基づいています。

イベント・タイプ1

イベント・タイプ名: JDBC_Connection State

<ナウン・タイプ> State

イベント・タイプ・パス: dms/JDBC/JDBC_Connection_State

dms/<ナウン・パスの先頭のコンポーネント>/<ナウン・タイプ>/_State

フィールド:

- ECID

- RID

- JDBC_Connection名
値は、ナウンのフルパスになります。

- JDBC_Connection_Url
値は、イベントの実行時のこの名前の状態センサーの値になります。

- JDBC_Connection_Username
値は、イベントの実行時のこの名前の状態センサーの値になります。

- イベント名
値は次のいずれかになります。

- アクティブ化によってこのJFRイベント・インスタンスを発生させるDMSイベント・センサーの名前

- 状態センサーの更新にこのJFRイベント・インスタンスが作成された場合はnull

プロデューサ名: JDBC

イベント・タイプ2

イベント・タイプ名: JDBC_Connection CreateStatement

イベント・タイプ・パス:

dms/JDBC/JDBC_Connection_CreateStatement

フィールド:

- ECID

- RID

- JDBC_Connection名

- JDBC_Connection_Url

- JDBC_Connection_Username

プロデューサ名: JDBC

イベント・タイプ3

イベント・タイプ名: JDBC_Connection CreateNewStatement

イベント・タイプ・パス:

dms/JDBC/JDBC_Connection_CreateNewStatement

フィールド:

- ECID

- RID

- JDBC_Connection名

- JDBC_Connection_Url

- JDBC_Connection_Username

プロデューサ名: JDBC

イベント・タイプ4

イベント・タイプ名: JDBC_Connection DBWaitTime

イベント・タイプ・パス:

dms/JDBC/JDBC_Connection_DBWaitTime

フィールド:

- ECID

- RID

- JDBC_Connection名

- JDBC_Connection_Url

- JDBC_Connection_Username

5.7.3 ログ・メッセージのDMSイベント・フォーマットの理解

表5-8は、DMSイベントを構成するフィールドを示しています。フィールド要素は「:」で区切られますが、いくつかの例外があります。実際のイベント文字列のフィールドの位置を示すため、サンプルのイベントが用意されています。

表5-8 イベント・フォーマットの説明

アプリケーション・イベント

フィールド番号

名前

説明

すべて

1

バージョン番号

イベント形式のバージョン番号

例:

v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp

すべて

2

イベント時間

イベントが発生した時間

例:

v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp

すべて

3

ソース・オブジェクト・タイプ

次の項目を含むイベントを生成するためにアクションが実行されたオブジェクトのタイプ

- NOUN

- EVENT_SENSOR

- STATE_SENSOR

- PHASE_SENSOR

- EXECUTION_CONTEXT

- HTTP_REQUEST

例:

v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp

すべて

4

アクション・タイプ

このイベントを生成したアクションのタイプ。特定のソース・オブジェクト・タイプは、次の各アクション・タイプのイベントを必ずしも生成しません。

- CREATE

- UPDATE

- DELETE

- START

- STOP

- ABORT

例:

v1:1280737384058:HTTP_REQUEST:STOP:/MyWebApp/emp

ナウン

5

ナウン・タイプ

ナウン・タイプの名前

例:

v1:1281344803506:NOUN:CREATE:JDBC_Connection:/JDBC/JDBC Data Source-0/CONNECTION_1

6

ナウン・パス

センサーが属するナウンを識別するフルパス

例:

v1:1281344803506:NOUN:CREATE:JDBC_Connection:/JDBC/JDBC Data Source-0/CONNECTION_1

すべてのセンサー・タイプ

5

ナウン・タイプ

このセンサーが属するナウン・タイプの名前

例:

v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086

6

センサー名

センサーの名前

例:

v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069

7

ナウン・パス

センサーが属するナウンを識別するフルパス

例:

v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069

フェーズ・センサー・タイプ

8

開始トークン

フェーズの開始トークン。

例:

v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069

9

停止トークン

フェーズの終了トークン。

例:

v1:1280737383069:PHASE_SENSOR:STOP:JDBC_Connection:DBWaitTime:/JDBC/JDBC Data Source-0/CONNECTION_1:1280737382950:1280737383069

状態センサー・タイプ

8

状態値タイプ

次の項目を含む状態センサーで保持される値のタイプ

- State.DOUBLE

- State.INTEGER

- State.LONG

- State.OBJECT

- State.ANY

例:

v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086

9

状態値

文字列形式で表される状態の値。

例:

v1:1280503318973:STATE_SENSOR:UPDATE:JDBC_Connection:LogicalConnection:/JDBC/JDBC Data Source-0/CONNECTION_1:State.ANY:LogicalConnection@13bed086

HTTPリクエスト

5

URI

Uniform Resource Identifier (URI)は、リクエストを適用するリソースを識別します。

例:

v1:1280737382889:HTTP_REQUEST:START:/myWebApp/showEmployees

v1:1280737384058:HTTP_REQUEST:STOP:/myWebApp/showEmployees

実行コンテキスト

5

ECID、RID

カンマで区切られたECIDおよびRIDで構成されるコンテキスト識別子。

実行コンテキスト・イベントでは、4番目のイベント・フィールド・セパレータ(「:」)の後の最初の文字から始まる完全な部分文字列にECIDおよびRID識別子を記録します。コンテキスト識別子に「:」が含まれる可能性があるので、イベント・フィールド・セパレータとして解釈しないようにしてください。

例:

v1:1280737384058:EXECUTION_CONTEXT:STOP:bc4fd0668f79d507:367c127f:12a23f2013c:-8000-0000000000000f73,0

5.7.4 DMSイベント・アクションの理解

表5-9は、ソース・オブジェクト・タイプで実行できるアクション・タイプを示しています。

表5-9 ソース・オブジェクト・タイプで実行されるアクション

作成

更新

削除

開始

停止

中断

ナウン

はい

-

はい

-

-

-

イベント・センサー

はい

はい

はい

-

-

-

フェーズ・センサー

はい

-

はい

はい

はい

はい

状態センサー

はい

はい

はい

-

-

-

実行コンテキスト

-

-

-

はい

はい

-

HTTPリクエスト

-

-

-

はい

はい

-

5.8 DMSのベスト・プラクティス

DMSメトリックを使用すると、アプリケーションのパフォーマンスに影響を与える可能性があります。メトリックを追加する場合、次の内容を検討してください。

- 高分解能クロックを使用したDMSの精度の向上
デフォルトでは、DMSはPhaseEvent中に時間間隔を測定する際、システム・クロックを使用します。デフォルト・クロックのレポート精度は、ApacheなどのCプロセスではマイクロ秒、Javaプロセスではミリ秒です。パフォーマンス測定の精度向上のために、DMSはオプションで高分解能クロックをサポートしており、時間間隔をレポートする際の値をユーザーが選択できます。デフォルト・クロックを使用する場合よりも正確にPhaseEventの時間を測定する必要があるとき、またはシステムのデフォルト・クロックが分解能の要件に満たないときは、高分解能クロックを使用してください。

システム・クロックは、必ずしも精度が示すほど正確である必要はありません。たとえば、ミリ秒で時間を報告するシステム・クロックは、ミリ秒単位で動作(変化)しない場合があります。かわりに、次の例のように最大15ミリ秒要する場合があります。

表5-10 デフォルトのシステム・クロック時間と実際の時間(ミリ秒)

実際の時間

システム時間

12:00:00.000

12:00:00.000

12:00:00.001

12:00:00.000

12:00:00.002

12:00:00.000

[...]

12:00:00.014

12:00:00.000

12:00:00.015

12:00:00.015

12:00:00.016

12:00:00.015

表5-10は、実際の時間12:00:00.002から12:00:00.014に実行される12ミリ秒の期間のフェーズがゼロのシステム時間で計算されることを示しています。同様に、12:00:00.014から12:00:00.016に実行される2ミリ秒の期間のフェーズは、15ミリ秒の期間のシステム時間で報告されます。

注意:

これらの動作は、一部のオペレーティング・システムでより明白になります。システム・クロックの動作期間より短い個々の期間の分析に注意してください。DMSを構成して高分解能クロックを使用すると、DMSに高分解能のフェーズ・センサーのアクティブ化が記録されますが、正確性は基盤システムによって制限されます。

- Javaの時間を報告するDMSクロックの構成
高分解能クロックを選択すると、クロックを変更したサーバーで実行されているすべてのアプリケーションに対してクロックが変更されます。プロセスの起動オプションを制御するoracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを使用して、DMSクロックおよびレポートの値をグローバルに設定します。

たとえば、デフォルトの値で高分解能クロックを使用するには、Javaコマンドラインで次のプロパティを設定します。

-Doracle.dms.clock=highres

注意:

高分解能クロックを使用する場合、デフォルトの値はFusion Middleware Controlが予期している値(ミリ秒)と異なります。高分解能クロックを使用しているときに、Fusion Middleware Controlを正しく表示する必要がある場合は、単位のプロパティを次のように設定します。

-Doracle.dms.clock.units=msecs

表5-11に、oracle.dms.clockプロパティでサポートされる値を示します。

表5-12に、oracle.dms.unitsプロパティでサポートされる値を示します。

表5-11 oracle.dms.clockプロパティの値

値

説明

DEFAULT

デフォルト・クロックを使用することを指定します。デフォルト・クロックの場合、DMSはJavaコールjava.lang.System.currentTimeMillisを使用してPhaseEventの時間を取得します。

デフォルト・クロックの単位のデフォルト値は、MSECSです。

HIGHRES

Java HighresクロックはSystem.nanoTime()を使用します(JNIは不要です)。

表5-12 oracle.dms.clock.unitsプロパティの値

値

説明

MSECS

時間がミリ秒に変換され、msecsとしてレポートされることを指定します。ミリ秒は10-3秒です。

注意: これはデフォルト・クロックのデフォルト値です。

USECS

時間がマイクロ秒に変換され、usecsとしてレポートされることを指定します。マイクロ秒は10-6秒です。

NSECS

時間がナノ秒に変換され、nsecsとしてレポートされることを指定します。ナノ秒は10-9秒です。

注意: これは高分解能クロックのデフォルト値です。

高分解能のDMSクロックを使用するときは、次の点に注意してください。

- oracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを設定する際には、大文字と小文字を自由に組み合せて、選択した値を指定することができます(大/小文字の区別はありません)。たとえば、高分解能クロックを選択する場合、highres、HIGHRES、HighResのどれも有効です。

- DMSは、起動時にプロパティ値をチェックします。表5-11に示されていない値でクロック・プロパティを設定すると、デフォルト・クロックが使用されます。oracle.dms.clockプロパティを設定していない場合も、デフォルト・クロックが使用されます。

- クロック単位のプロパティが表5-12に示されていない値に設定されている場合、指定したクロックのデフォルトの単位が使用されます。

第II部

コア・コンポーネント

この部では、パフォーマンスの向上を目的とするコア・コンポーネントの構成について説明します。次の章で構成されています。

- 第5章「Oracle Dynamic Monitoring Serviceの使用」

- 第6章「Oracle HTTP Serverのパフォーマンス・チューニング」

- 第7章「Oracle Metadata Service (MDS)のパフォーマンス・チューニング」

注意:

Oracle WebLogic Serverのパフォーマンス・チューニングの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。

6 Oracle HTTP Serverのパフォーマンス・チューニング

この章では、Oracle HTTP Serverのパフォーマンスを最適化する手法について説明します。この章の内容は次のとおりです。

- 第6.1項「Oracle HTTP Serverについて」

- 第6.2項「Oracle HTTP Serverのパフォーマンスの監視」

- 第6.3項「チューニングに関する基本的な考慮事項」

- 第6.4項「チューニングに関する高度な考慮事項」

注意:

この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

6.1 Oracle HTTP Serverについて

Oracle HTTP Server (OHS)は、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。Oracle WebLogic Serverのリスナーと静的ページ、動的ページおよびWeb上のアプリケーションのホスティングのフレームワークを提供します。Oracle HTTP ServerはApache 2.2.xインフラストラクチャをベースとし、オラクル社が開発したモジュールを含んでいます。シングル・サインオン、クラスタ化されたデプロイおよび高可用性の機能がOracle HTTP Serverの動作を強化しています。

詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverの概要に関する項を参照してください。

オープンソースのApacheソフトウェア・インフラストラクチャの詳細は、Apache Software FoundationのWebサイト(http://www.apache.org/)を参照してください。

6.2 Oracle HTTP Serverのパフォーマンスの監視

Oracle Fusion Middlewareでは、Oracle HTTP Serverの実行時のパフォーマンスが絶えず自動的に測定されます。パフォーマンス・メトリックは自動的に有効になります。パフォーマンス・メトリックを収集するためにオプションを設定したり、追加構成を行ったりする必要はありません。アプリケーションの実行に時間がかかる、アプリケーションがハングしている、などの問題が発生した場合は、特定のメトリックを参照して、問題の詳細を確認できます。

注意:

Fusion Middleware Controlにはリアルタイム・データが表示されます。Fusion Middleware Controlを使用してHTTP Serverのパフォーマンス・メトリックを確認する方法の詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverプロセスの管理に関する項を参照してください。

監視の場合、Oracle HTTP Serverはあらゆる機能部分のメトリックを収集するDynamic Monitoring Service (DMS)を使用します。これらのメトリックを必要に応じて確認することで、特定の時点におけるシステムの動作を把握できます。Oracle HTTP Serverのすべてのレイヤーについて、メモリー、CPU情報、ならびにリクエスト処理の最小時間、最大時間および平均時間が表示されます。さらに、実際の使用状況に基づいてシステムをチューニングする際に役立つ負荷レベル、スレッド数、アクティブ接続数などの詳細も表示されます。

これらのDMSメトリックの使用法の詳細は、第5.4.3項「WLST (Oracle WebLogic Server)を使用したメトリックの表示」を参照してください。

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

次のチューニング構成により、Oracle HTTP Serverのパフォーマンスを改善できる場合があります。必ず各自のユースケースを検討して、これらの設定をデプロイメントに適用できるかどうかを判断してください。

- Oracle HTTP Serverディレクティブのチューニング

- 永続的な接続によるhttpdプロセスの可用性の低下

- Oracle HTTP Serverのロギング・オプション

6.3.1 Oracle HTTP Serverディレクティブのチューニング

Oracle HTTP Serverでは、httpd.confのディレクティブが使用されます。この構成ファイルには、同時に処理可能なHTTPリクエストの最大数、ロギング詳細、ならびに特定の制限およびタイムアウトが指定されています。

Oracle HTTP Serverの構成の詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverの管理ツールに関する項を参照してください。

Oracle HTTP Serverは、デフォルトで、3種類のMulti-Processing Module (MPM)をサポートしています。サポートされているMPMは次のとおりです。

- Worker: これは、マルチプロセス-マルチスレッド・モデルを採用しており、Microsoft Windowsプラットフォームを除くすべてのプラットフォームのデフォルトMPMです。マルチスレッド・サポートによってシステム・リソースの使用量が減少するため、スケーラビリティが向上し、マルチプロセス・サポートによって安定性が向上します。

- WinNT: このMPMはWindowsプラットフォーム専用です。親プロセスと子プロセスで構成されています。親プロセスは制御プロセスであり、子プロセスはリクエストを処理するスレッドを作成します。

- Prefork: これは、Apache 1.3.x方式に準拠しており、スレッドのかわりにプロセスを使用します。最も効率性の低いMPMとみなされています。

各MPMタイプのディレクティブは、ORACLE_INSTANCE/config/OHSComponent/<ohsname>/httpd.confファイルにあります。デフォルトのMPMタイプはWorker MPMです。別のMPM (Prefork MPMなど)を使用する場合は、/ohs/bin/apachectlファイルを編集してください。

注意:

この章の内容は、Worker MPMおよびWinNT MPM(どちらもスレッドを使用)の使用を前提としています。次に示すディレクティブは、Prefork MPMを使用する場合は適用されない可能性があります。Apache 1.3.xまたはApache 2.2ベースのOracle HTTP ServerをPrefork MPMとともに使用する場合は、Oracle Application Server 10g リリース3のドキュメント(http://www.oracle.com/technology/documentation/appserver10132.html)を参照してください。

表6-1 Oracle HTTP Serverの構成プロパティ

ディレクティブ

説明

ListenBackLog

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「キューの長さ: 最大」フィールドにマップされます。

保留中の接続のキューの最大長を指定します。通常、チューニングは不要です。一部のオペレーティング・システムでは、バックログとして指定した数値そのものが使用されるのではなく、設定値に基づいた数値(通常は設定値より大きい数値)が使用されることに注意してください。

デフォルト値: 511

MaxClients

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「最大リクエスト数」フィールドにマップされます。

このパラメータは、mod_winnt (Microsoft Windows)では使用できませんので注意してください。winntはシングル・プロセスのマルチスレッド・モデルを採用しており、ThreadLimitディレクティブによって制御されます。

稼働しているサーバーの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、ListenBackLogディレクティブで指定した制限に達するまでTCP/IPシステムのキューに入れられます(保留中の接続のキューが満杯になった後は、スレッドが使用可能になるまで、新しいリクエストが発生するたびに接続エラーが生成されます)。

MaxClientsディレクティブはhttpd.confファイルで構成でき、最大値は8000 (8K) (デフォルト値は150)です。システム・リソースが飽和状態でなく、HTTP/スレッドの同時接続ユーザー数が150を超えている場合は、MaxClientsを大きくしてサーバーの同時実行性を高めると、パフォーマンスが向上します。システムの利用状況がフル(目安は85%)になるまで、MaxClientsを大きくします。

これとは逆に、システム・リソースが飽和状態のときにMaxClientsを大きくしても、パフォーマンスは向上しません。この場合は、サーバーへの同時リクエスト数に対するスロットルとして、MaxClientsの値を小さくします。

サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドルな接続の両方を処理するために十分な数の同時httpd/スレッド・サーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxClientsを指定するとき、アイドル状態の永続的なhttpd接続もhttpd/スレッド・プロセスを消費することを考慮に入れる必要があります。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。永続的(KeepAlive)なHTTP接続は、接続リクエストの処理中でなくても、接続期間中はhttpd子プロセス(スレッド)を消費します。

十分なキャパシティがある場合は、KeepAliveを有効にしてください。永続的な接続を使用することで、パフォーマンスが向上し、HTTP接続の再確立によるCPUリソースの浪費が回避されます。通常、KeepAliveパラメータは変更しません。

MaxClientsの最大値は8192 (8K)です。

デフォルト値: 150

StartServers

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「初期子サーバー・プロセス」フィールドにマップされます。

起動時に作成される子サーバー・プロセスの数を指定します。再起動後に急激な負荷が予想される場合は、必要な子サーバーの数に基づいてこの値を設定してください。

次のパラメータは相関関係にあり、UNIXプラットフォーム(worker_mpm)にのみ適用されることに注意してください。

- MaxClients

- MaxSpareThreadsとMinSpareThreads

- ServerLimitとStartServers

Windowsプラットフォーム(mpm_winnt)では、UNIXプラットフォームの場合と同様に、次のパラメータをチューニングすることが重要です。

- ThreadLimit

- ThreadsPerChild

各子プロセスには、実際にリクエストを処理する子スレッドが定義されていることに注意してください。このディレクティブと関連してThreadsPerChildを使用します。

ThreadLimit、ServerLimitおよびMaxClientsは、この値に間接的に影響を与えます。それぞれの注意を読んだうえで、このディレクティブとともに使用してください。

デフォルト値: 2

ServerLimit

このパラメータは、mod_winnt (Microsoft Windows)では使用できませんので注意してください。winntはシングル・プロセスのマルチスレッド・モデルを採用しています。

作成可能なサーバー(子)・プロセスの数の上限を指定します。StartServersの値がServerLimitの値より大きい場合は、ServerLimitの値が優先します。これは、作成可能なサーバー・プロセスの最大数を制御する目的で使用されます。

デフォルト値: 16

ThreadLimit

サーバー(子)・プロセスの下に作成可能なスレッドの数の上限を指定します。ThreadsPerChildの値がThreadLimitの値より大きい場合は、ThreadLimitの値が優先します。これは、プロセスごとに作成されるスレッドの最大数を制御し、競合や問題の発生を防ぐ目的で使用されます。

デフォルト値:

- Windowsマルチプロセス・モジュール(mpm_winnt): 1920

- その他すべて: 64

ThreadsPerChild

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1子サーバー・プロセス当たりのスレッド数」フィールドにマップされます。

起動時に各サーバー(子)・プロセスで作成されるスレッドの数を設定します。

デフォルト値: mpm_winntを使用する場合は64、Worker MPMを使用する場合は25です。

ThreadsPerChildディレクティブは、他のディレクティブと次のように連携します。

起動時に、Oracle HTTP Serverが親プロセスを作成します。親プロセスは、StartServersディレクティブで定義された数の子(サーバー)プロセスを作成します。各サーバー・プロセスは、ThreadsPerChildに指定された数のスレッド(サーバー/ワーカー)と、リスナー・スレッドを作成します。リスナー・スレッドは、リクエストをリスニングし、ワーカー/サーバー・スレッドに制御を渡します。

起動後は、負荷の状態に応じて、システムのサーバー・プロセス数とサーバー・スレッド(サーバー・プロセスの子)数がMinSpareThreads(システムのアイドル・スレッドの最小数)とMaxSpareThreads(システムのアイドル・スレッドの最大数)によって制御されます。システムのアイドル・スレッド数がMaxSpareThreadsを超えている場合、Oracle HTTP Serverは、プロセスの子スレッドがなければ、スレッドとプロセスを終了します。アイドル・スレッド数がMinSpareThreadsを下回っている場合、実行中のプロセスですでにThreadsPerChildの値に達していれば、新しいスレッドとプロセスを作成します。

次のディレクティブは、前述のディレクティブに対する制限を制御します。次のディレクティブを有効にするには、前述のディレクティブより先に定義する必要がありますので注意してください。

- ServerLimit: 作成可能なサーバーの数の上限を定義します。これは、MaxClientsとStartServersに影響を与えます。

- ThreadLimit: ThreadsPerChildの上限を定義します。ThreadsPerChildがThreadLimitより大きい場合、ThreadsPerChildは自動的にThreadLimitの値まで減らされます。

- MaxClients: リクエストを同時に処理可能なサーバー・スレッドの数の上限を定義します。この値は、作成可能な同時接続の数と一致させる必要があります。この値は、ThreadsPerChildの倍数になるようにしてください。MaxClientsがServerLimitにThreadsPerChildを掛けた値より大きい場合、MaxClientsは自動的に、ServerLimitにThreadsPerChildを掛けた値まで減らされます。

MaxRequestsPerChild

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1子サーバー・プロセス当たりの最大リクエスト数」フィールドにマップされます。

各子プロセスが終了するまでに処理可能なリクエストの数を指定します。子プロセスは、長期間使用するうちにApache(およびApacheが使用するその他のライブラリ)でメモリーまたはその他のリソースのリークが発生して問題が生じることのないよう、自動的に終了します。ほとんどのシステムでは、これは不要ですが、UNIXシステムの中には、ライブラリで著しいリークが発生するものがあります。このようなプラットフォームについては、MaxRequestsPerChildを10000に設定してください。0に設定すると、リクエストは制限されません。

この値には、各接続の初期リクエストに続くKeepAliveリクエストは含まれません。たとえば、子プロセスが初期リクエストとそれに続く10個のキープ・アライブ・リクエストを処理した場合、この制限の対象となるリクエストは1個とカウントされます。

デフォルト値: 0

注意: Windowsシステムでは、サーバー・プロセスが1つしかないため、MaxRequestsPerChildは常に0(無制限)に設定してください。

MaxSpareThreads

MinSpareThreads

これらのディレクティブは、「パフォーマンス・ディレクティブ」画面の「最大アイドル・スレッド」フィールドおよび「最小アイドル・スレッド」フィールドにマップされます。

これらのパラメータは、mod_winnt (Windowsプラットフォーム)では使用できませんので注意してください。

サーバープールのサイズを制御します。Oracle HTTP Serverは、必要なサーバー・スレッドの数を予測するかわりに、実際の負荷に動的に適応します。サーバーは、現在の負荷を処理するのに十分なサーバー・スレッドに加え、一時的な負荷の増大(単一のブラウザから複数のリクエストを同時に受信した場合など)に備えて、予備のサーバー・スレッドもいくつか保持しておこうとします。

そのために、サーバーはリクエストを待っているサーバー・スレッドの数を定期的にチェックします。それがMinSpareThreadsより少ない場合は、新しい予備のスレッドを作成します。MaxSpareThreadsより多い場合は、予備のスレッドの一部を削除します。

デフォルト値:

MaxSpareThreads: 75

MinSpareThreads: 25

Timeout

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「リクエスト・タイムアウト」フィールドにマップされます。

受信および送信がタイムアウトするまでの時間(秒)。

デフォルト値: 300

KeepAlive

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1接続当たりの複数リクエスト」フィールドにマップされます。

永続的な接続(1接続当たり複数のリクエスト)を許可するかどうか。Offに設定すると、無効になります。

デフォルト値: On

MaxKeepAliveRequests

永続的な接続の間に許可するリクエストの最大数。0に設定すると、無制限に許可されます。

長時間にわたるクライアント・セッションがある場合は、この値を大きくすることを検討してください。

デフォルト値: 100

KeepAliveTimeout

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1接続当たりの複数リクエスト」フィールドの下にある「接続タイムアウト(秒)を許可」フィールドにマップされます。

1つの接続において同じクライアントからの次のリクエストを待つ時間(秒)。

デフォルト値: 5秒

limit

ulimit

オープン・ファイルまたはオープン・ネットワーク・ソケットに対して読取りまたは書込みを行うためにプログラムで使用するオブジェクトの数。使用可能なファイル・ディスクリプタの不足は、オペレーティング・システムのパフォーマンスに影響を与える可能性があります。

ファイル・ディスクリプタ制限をチューニングするには、OHSを起動するシェル・スクリプトで強い制限(ulimit)を構成します。強い制限が設定されると、OHSは弱い制限(limit)を一致するように調整します。

ファイル・ディスクリプタ制限の構成は、プラットフォーム固有であることに注意してください。詳細は、オペレーティング・システムのドキュメントを参照してください。

6.3.2 永続的な接続によるhttpdプロセスの可用性の低下

ブラウザが永続的な接続をサポートしている場合、Oracle HTTP ServerのKeepAliveディレクティブを使用すれば、サーバーでも永続的な接続をサポートできます。永続的な接続を使用すると、サーバーのワークロードが減少するため、パフォーマンスが向上します。永続的な接続を有効にした場合、サーバーでは、クライアントへの接続を設定する作業を繰り返す必要がなくなります。

KeepAliveディレクティブのデフォルト設定は次のとおりです。

KeepAlive on
MaxKeepAliveRequests 100
KeepAliveTimeOut 5

これらの設定では、永続的な接続のメリットを享受しながら、デメリットを最小限に抑えることができるように、1接続当たりのリクエスト数とリクエストの間隔が設定されています。これらの値を設定する際には、ご使用のシステムのユーザー数とユーザーの取る行動を考慮する必要があります。たとえば、ユーザー数は多いが、ユーザーからのリクエストが小さく、頻度も低い場合は、KeepAliveディレクティブのデフォルト設定を小さくするか、KeepAliveをoffに設定します。ユーザー数が少なく、サイトのアクセス頻度が高い場合は、設定を大きくします。

KeepAliveオプションは、MaxClientsディレクティブとともに慎重に使用してください。KeepAliveオプションは、タイムアウトするか、リクエスト数がMaxKeepAliveRequestsで指定した制限に達するまで、確立済の接続にワーカー・スレッドを結び付けます。つまり、ListenBacklogキュー内の接続またはユーザーは、キープ・アライブ・ユーザーがワーカーを解放するまで、ワーカーが不足した状態になります。リソースの不足は、ユーザー数がMaxClientsに指定した数より常に多いようなKeepAliveユーザー負荷に対して発生します。

注意:

MaxclientsプロパティはUNIXプラットフォームにのみ適用されます。Windowsでは、ThreadLimitパラメータおよびThreadsPerChildパラメータで同じ機能が実現されます。

MaxClientsを大きくした場合、パフォーマンスに次のような影響が出ます。

- MaxClientsの数値が大きいと、システム・リソースに過負荷がかかり、パフォーマンスの低下につながる可能性があります。

- ユーザー数が多く、リクエストが少ない場合は、リソース不足が起きないように、MaxClientsを大きくしてKeepAlive接続をサポートすることを検討してください。この場合、ユーザーの同時実行性が向上すると、全体的なパフォーマンスに影響が出る可能性がありますので注意してください。システム・パフォーマンスが同時実行性向上の影響を受け、システム障害を引き起こすことがあります。

MaxClientsは常に、システムが安定し、最適なパフォーマンスが得られる(CPU使用率が最大85%)ような値に設定してください。

一般に、ユーザー数が多く、リクエストの頻度が低い場合は、リソース不足が起きないように、KeepAliveオプションをoffにするか、ごく小さい値まで減らすことを検討してください。

KeepAlive接続を無効にした場合、パフォーマンスに次のような影響が出ます。

- リクエストごとに接続を確立するため、コストがかかります。

- 接続を作成してクローズする頻度が高くなると、システム・リソースがある程度使用されます。TCP接続では、ソケット接続およびオープン・ファイル・ディスクリプタをクローズするまでのtime_wait間隔が接続ごとに設定されています。time_waitのデフォルト値は60秒です。つまり、サーバーが接続を解放した後も、各接続をクローズするまでに60秒かかる可能性があります。

警告:

パフォーマンスの問題が発生するのを避けるために、パラメータの値は、必ずワークロードの性質およびシステムのキャパシティを考慮したうえで設定してください。

6.3.3 Oracle HTTP Serverのロギング・オプション

この項では、ロギングのタイプ、ログ・レベル、およびロギングを使用した場合のパフォーマンスへの影響について説明します。

6.3.3.1 アクセス・ロギング

一般に、アクセス・ログは誰が何にアクセスしたかを追跡する目的で有効にします。ORACLE_INSTANCE/diagnostics/logs/OHS/ohsnameディレクトリにあるaccess_logファイルには、処理されたリクエストごとにエントリが1つ含まれています。このファイルは次第に大きくなるため、ディスク領域を消費する可能性があります。ワークロードの性質によっては、access_logはパフォーマンスにほとんど影響を与えません。パフォーマンスが問題になっていることに気づいた場合、他のプロキシまたはロード・バランサが使用されていて、同じ情報が得られるのであれば、access_logファイルを無効にしてもかまいません。

6.3.3.2 HostNameLookupsディレクティブの構成

デフォルトでは、HostNameLookupsディレクティブはOffに設定されています。サーバーは、受信リクエストのIPアドレスをログ・ファイルに書き込みます。HostNameLookupsがOnに設定されている場合、サーバーはインターネット上のDNSシステムに問い合せて、各リクエストのIPアドレスに関連付けられているホスト名を特定し、そのホスト名をログに書き込みます。サーバーの負荷およびDNSサーバーへのネットワーク接続によっては、DNS HostNameLookupがパフォーマンスに与える影響が大きくなります。可能であれば、IPアドレスのみをログに記録することを検討してください。UNIXシステムでは、/Apache/Apache/bin/ディレクトリにあるlogresolveユーティリティを使用して、オフラインの状態でIPアドレスをホスト名に解決できます。

6.3.3.3 エラー・ロギング

サーバーは、異常なアクティビティをエラー・ログに記録します。ORACLE_INSTANCE/diagnostics/logs/OHS/ohsnameディレクトリにあるohsname.logファイルには、エラー、警告、システム情報および通知(ログレベル設定による)が含まれています。

httpd.confファイルには、OHSのエラー・ログ構成が含まれています。ロギング・モードはOraLogModeディレクティブで定義されます。デフォルトはodl-textです。この場合、Oracle診断ロギング・フォーマットがテキスト・ファイルに生成されます。これをodl-xmlに変更すると、Oracle診断ロギング・フォーマットがXMLファイルに生成されます。

Oracle診断形式のロギングの場合、OraLogSeverityディレクティブを使用してログ・レベルを設定します。

Apache形式のロギングの場合、ErrorLogディレクティブとLogLevelディレクティブを使用して、ログ・ファイル、および記録されるメッセージの詳細度を指定します。デフォルトのデバッグ・レベルはWarnです。

過度のロギングを行うと、パフォーマンス・コストが発生し、ディスク領域も占有してしまう可能性があります。ログ・レベルの制御は、必要に応じて使用してください。動的リソースを使用するリクエスト(たとえば、mod_ossoまたはmod_plsqlを使用するリクエスト)の場合、debugレベルなど高いデバッグ・レベルを設定すると、それに伴ってパフォーマンス・コストが発生します。

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

この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってご使用のHTTP Serverのパフォーマンスが改善されるかどうかを判断してください。

- Oracle HTTP Serverのチューニング

- Oracle HTTP Serverにおけるセキュリティのチューニング

6.4.1 Oracle HTTP Serverのチューニング

次のヒントを利用すると、Oracle HTTP Serverのパフォーマンスに関する問題の回避やデバッグが可能になります。

- 「静的リクエストと動的リクエストの比較分析」

- 「PL/SQLリクエストの管理」

- 「有効モジュール数の制限」

- Oracle HTTP Serverのパフォーマンスの監視

6.4.1.1 静的リクエストと動的リクエストの比較分析

問題の主な原因となっている箇所を集中的にチューニングできるよう、サーバーがどこでリソースを消費しているかを把握することが重要です。システムを構成する際には、受信リクエストの何パーセントが静的なもので何パーセントが動的なものかを知っておくと役立つ場合があります。

一般に、動的なページは生成のコストが余計にかかるため、動的なページのチューニングに時間をかけてください。また、アプリケーションの監視およびチューニングを行うことで、カタログ・データなどの動的に生成されたコンテンツの多くがキャッシュ可能であり、リソースの使用量を大幅に節減できることも明らかになります。

6.4.1.2 PL/SQLリクエストの管理

データに外れ値があると、状態を正確に反映していない結果が生成されます。このような状況は、起動時に起こることがあります。簡単な例をシミュレーションしてみましょう。PL/SQLのHello, Worldアプリケーションを約30秒間実行したとします。結果を調べてみると、処理はすべてmod_plsql.c内で次のように行われていました。

/ohs_server/ohs_module/mod_plsql.c
handle.maxTime:     859330
handle.minTime:      17099
handle.avg:          19531
handle.active:           0
handle.time:      24023499
handle.completed:     1230

ここで、このモジュールのhandle.maxTimeがhandle.avgよりはるかに大きい点に注意してください。これはおそらく、最初のリクエストを受信したときに、データベース接続をオープンする必要があるためです。その後のリクエストは、すでに確立された接続を利用できます。この場合、PL/SQLモジュールの平均サービス時間をより正確に推定するには、handle.maxTime値を増加させていたデータベース接続のオープンにかかる時間を除外して、次のように平均を計算しなおします。

(time - maxTime)/(completed -1)

例:

(24023499 - 859330)/(1230 - 1) = 18847.98

6.4.1.3 有効モジュール数の制限

Apache 2.2をベースとする現行のOracle HTTP Serverは、Apache 1.3をベースとしていた旧リリースのOracle HTTP Serverと比べて、リクエストの処理方法の点でアーキテクチャがわずかに異なっています。

新しいアーキテクチャでは、Oracle HTTP Serverは各モジュールのロード済のサービス関数を(httpd.confファイルで定義されている順に)リクエストが処理されるまで呼び出します。つまり、各モジュールのサービス関数を呼び出す際には、サービスが承認されたか却下されたかを認識するためのコストが発生することになります。

アーキテクチャがこのように変更されたため、httpd.confファイルの中では、最も使用頻度の高いモジュールを他のモジュールより前に配置することを検討してください。

Oracle HTTP Serverに直接デプロイされ、デフォルト・ハンドラによって処理される静的ページのリクエストは、デフォルト・ハンドラが呼び出されるまでに、すべてのモジュールを通過する必要があります。このプロセスはリクエストのパフォーマンスに影響を与える可能性があるため、デプロイ済のアプリケーションで必要とされるモジュールのみを有効にすることを検討してください。たとえば、デプロイ済のアプリケーションでmod_plsqlが使用されない場合は、パフォーマンスを確保するためにmod_plsqlを無効にします。

また、URLの変換段階でなんらかの処理を行うためにフックを登録するモジュールがいくつかあります。これも、リクエスト処理時間のコストが増加する原因となります。たとえば、specwebベンチマークによると、mod_securityを有効にした場合、1トランザクションにつきCPUコストが約10%増加します。この場合も、デプロイ済のアプリケーションで必要とされるモジュールのみを有効にして、CPU時間を節約してください。

6.4.1.4 ファイル・ディスクリプタ制限のチューニング

使用可能なファイル・ディスクリプタの不足は、必ずしも簡単にオペレーティング・システムのファイル・ディスクリプタ制限まで遡れない様々な症状の原因になる可能性があります。ファイル・ディスクリプタ制限をチューニングするには、OHSを起動するユーザーに対してオペレーティング・システムの強い制限を構成します。構成すると、OHSはオペレーティング・システムの制限と一致するように弱い制限を調整します。

ファイル・ディスクリプタ制限の構成は、プラットフォーム固有です。詳細は、オペレーティング・システムのドキュメントを参照してください。次のコード例は、Linuxのコマンドを示しています。

APACHECTL_ULIMIT=ulimit -S -n `ulimit -H -n`

この制限は、パッチ・セットの適用後に再構成する必要があります。

6.4.2 Oracle HTTP Serverにおけるセキュリティのチューニング

この項の内容は次のとおりです。

- Oracle HTTP ServerにおけるSecure Sockets Layer (SSL)のチューニング

- Oracle HTTP Serverにおけるポート・トンネリングのチューニング

6.4.2.1 Oracle HTTP ServerにおけるSecure Sockets Layer (SSL)のチューニング

Secure Sockets Layer (SSL)は、Netscape社によって開発されたプロトコルで、インターネット上での認証および暗号化通信を可能にします。概念的には、SSLはプロトコル・スタックのアプリケーション層とトランスポート層の中間に存在します。SSLは、技術的にはアプリケーションに依存しないプロトコルですが、HTTP経由のセキュリティを提供するための標準となり、すべての主要なWebブラウザでサポートされています。

SSLは、Webベースのアプリケーションのレスポンス能力とスケーラビリティの両方でボトルネックとなる可能性があります。SSLが必要な場合は、プロトコルのパフォーマンスに関する問題を慎重に考慮してください。一般に、SSLプロトコルを使用するうえで最もパフォーマンス・コストがかかるのは、特にセッションの作成や初期化などのセッション管理です。

この項には、SSLのパフォーマンスに関連した次の情報が含まれています。

- 第6.4.2.1.1項「Oracle HTTP ServerのSSLキャッシュ」

- 第6.4.2.1.2項「SSLのアプリケーション・レベルのデータ暗号化の使用」

- 第6.4.2.1.3項「SSLのパフォーマンス・チューニング」

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護

6.4.2.1.1 Oracle HTTP ServerのSSLキャッシュ

SSL接続が初期化されると、クライアントとサーバーの間でセッションベースのハンドシェイクが発生します。これには、暗号スイートのネゴシエーション、データ暗号化用の秘密鍵の交換、ならびにデジタル署名証明書を介したサーバーおよびクライアント(オプション)の認証が含まれます。

SSLのセッション状態がクライアントとサーバーの間で開始されれば、そのセッション状態を保存して再利用できるので、その後のSSLリクエストでセッション作成のためのハンドシェイクを行う必要はなくなります。Oracle HTTP Serverは、デフォルトでクライアントのSSLセッション情報をキャッシュします。セッション・キャッシュを使用すると、待機時間が長いのはサーバーへの最初の接続時のみになります。

ssl.confのSSLSessionCacheTimeoutディレクティブにより、保存されたSSLセッションをサーバーが保持する期間を指定します(デフォルトは300秒です)。セッション状態は、指定の時間が経過しても使用されない場合は破棄されます。その後のSSLリクエストでは、新しいSSLセッションを確立し、もう一度ハンドシェイクを開始する必要があります。SSLSessionCacheディレクティブでは、SSLセッション情報の保存場所を指定します(デフォルトの場所は次のディレクトリです)。

$ORACLE_INSTANCE/diagnostics/logs/$COMPONENT_ TYPE/$COMPONENT_NAME

保存されたセッション・キャッシュ・ファイルは、複数のOracle HTTP Serverプロセスで使用できることに注意してください。

SSLのセッション状態を保存すると、SSLを使用したアプリケーションのパフォーマンスが大幅に向上します。たとえば、SSL対応のサーバーで接続と切断の簡単なテストを行ったところ、SSLセッション・キャッシュを使用しない場合、5回の接続に要した時間は11.4秒でした。SSLセッション・キャッシュを使用可能にした場合、5回のラウンドトリップに要した時間は1.9秒でした。

保存されたSSLのセッション状態を再利用する場合は、いくつかのパフォーマンス・コストが発生します。SSLのセッション状態をディスクに保存した場合、保存されたセッション状態を再利用するには、通常ディスクから関連するセッション状態を検出し、取得する必要があります。永続的なHTTP接続を使用すれば、このパフォーマンス・コストを削減できます。永続的なHTTP接続がクライアント側でサポートされている場合、Oracle HTTP Serverはこの接続をデフォルトで使用します。Oracle HTTP Serverによって実装されるSSLを使用したHTTP接続では、SSLのセッション状態は、関連するHTTP接続が維持されている間メモリーに保存されます。このプロセスにより、SSLセッションの再利用に伴うパフォーマンスへの影響が実質的に排除されます(概念的には、SSL接続はHTTP接続とともに維持されます)。詳細は、第6.3.2項「永続的な接続によるhttpdプロセスの可用性の低下」を参照してください。

6.4.2.1.2 SSLのアプリケーション・レベルのデータ暗号化の使用

SSLを使用するほとんどのアプリケーションでは、データ暗号化のコストは、SSLセッション管理のコストと比べればわずかです。著しい暗号化コストが発生するのは、暗号化されたデータのボリュームが大きい場合です。そのような場合、SSLセッションに対して選択したデータ暗号化アルゴリズムおよび鍵のサイズはきわめて大きくなります。通常、セキュリティ・レベルとパフォーマンスの間にはトレードオフが発生します。

Oracle HTTP Serverは、ssl.confで指定されているSSLCipherSuite属性に基づき、クライアントと暗号スイートをネゴシエートします。OHS 11gでは、デフォルトで128ビットの暗号化アルゴリズムが使用されており、それより低いレベルの暗号化はサポートを終了しました。Windowsの場合、旧リリース[10.1.3x]では64ビットの暗号化が使用されていました。UNIXの場合、10.xリリースでは128ビットの暗号化が使用されていました。

関連項目:

サポートされている暗号スイートの使用の詳細は、『Oracle HTTP Serverの管理』を参照してください。

6.4.2.1.3 SSLパフォーマンスのチューニング

次の推奨事項は、Oracle HTTP ServerをSSLとともに使用する場合のパフォーマンス要件を決定する際に役立ちます。

1. SSLハンドシェイクは、CPU使用率とレスポンス時間のどちらから見ても、本質的にリソース消費量の多いプロセスです。したがって、SSLは必要な場合にのみ使用しください。アプリケーションの中でセキュリティを必要とする部分と要求されるセキュリティ・レベルを見極め、この部分のみを必要なセキュリティ・レベルで保護します。SSLの使用を控え、可能なかぎりセッション状態を再利用して、SSLハンドシェイクの必要性を最小限に抑えます。たとえば、ページ上に少量の機密データと多量の機密ではないグラフィック画像がある場合、機密データの転送にのみSSLを使用し、画像の転送には通常のHTTPを使用します。アプリケーションでサーバー認証のみが必要とされている場合、クライアント認証は使用しません。アプリケーションのパフォーマンス目標がこの方法のみでは実現できなければ、追加のハードウェアが必要になる場合もあります。

2. SSLを効果的に使用できるようにアプリケーションを設計します。セキュアな操作をグループ化して、SSLセッションおよびSSL接続を再利用します。

3. 可能な場合は永続的な接続を使用して、SSLセッションの再利用のコストを最小限に抑えます。

4. セッション・キャッシュのタイムアウト値をチューニングします(ssl.confのSSLSessionCacheTimeoutディレクティブ)。SSLセッション・キャッシュを維持するコストと、新しいSSLセッションを確立するコストの間には、トレードオフが存在します。一般に、保護されたビジネス・プロセス、つまり概念的にグループ化されたSSL交換は、セッション作成を複数回行わずに完了させる必要があります。SSLSessionCacheTimeout属性のデフォルト値は300秒です。アプリケーションの使い勝手をテストして、この設定のチューニングに役立ててください。

5. 大量のデータがSSLで保護されている場合、使用されている暗号スイートに細心の注意を払ってください。暗号スイートは、ssl.confで指定されているSSLCipherSuiteディレクティブによって制御します。低いレベルのセキュリティでも許容される場合は、小さいサイズの鍵を使用する、暗号強度の低いプロトコルを使用します(これによってパフォーマンスが大幅に向上します)。目的のセキュリティ・レベルを確保するために使用可能な暗号スイートをそれぞれ使用してアプリケーションをテストし、最適な暗号スイートを見つけます。

6. 前述の考慮事項に配慮しても、SSLが引き続きアプリケーションのパフォーマンスおよびスケーラビリティのボトルネックとなる場合は、ハードウェア・クラスタに複数のOracle HTTP Serverインスタンスをデプロイするか、SSLアクセラレータ・カードを使用することを検討してください。

6.4.2.2 Oracle HTTP Serverにおけるポート・トンネリングのチューニング

OracleASポート・トンネリングが構成されている場合、リクエストはすべてOracleASポート・トンネリング・インフラストラクチャを経由して処理されます。したがって、OracleASポート・トンネリングは、Oracle HTTP Serverによるリクエスト処理のパフォーマンスおよびスケーラビリティ全体に大きく影響します。

実行されるOracleASポート・トンネリング・プロセスの数を除き、OracleASポート・トンネリングのパフォーマンスは自動的にチューニングされます。唯一可能なパフォーマンス制御は、より多くのOracleASポート・トンネリング・プロセスを開始することです。これにより、使用可能な接続の数が増え、システムのスケーラビリティが向上します。

OracleASポート・トンネリング・プロセスの数は、必要とされる可用性の度合いや期待される接続数に基づきます。プロセスを追加するたびに、DMZとイントラネットの間のファイアウォールを介して新しいポートをオープンする必要があるため、この数を自動的に決定することはできません。オープンしたポートより多くのプロセスは開始できません。また、オープンしたポートより少ないプロセスも好ましくありません。この場合、プロセスの割り当てられないポートが存在することになります。

OracleASポート・トンネリングのパフォーマンスを測定するには、OracleASポート・トンネリング・インフラストラクチャを経由するサーブレット・リクエストのリクエスト時間を調べます。OracleASポート・トンネリングを使用した場合と使用しない場合のレスポンス時間を比較して、OracleASポート・トンネリングによってパフォーマンス要件が満たされているかどうかを確認する必要があります。

関連項目:

OracleASポート・トンネリングの構成の詳細は、『Oracle HTTP Serverの管理』を参照してください。

7 Oracle Metadata Service (MDS)のパフォーマンス・チューニング

この章では、Oracle Metadata Service (MDS)のチューニングのヒントを示します。

- 第7.1項「Oracle Metadata Services (MDS)について」

- 第7.2項「Oracle Metadata Serviceのパフォーマンスの監視」

- 第7.3項「チューニングに関する基本的な考慮事項」

- 第7.4項「チューニングに関する高度な考慮事項」

7.1 Oracle Metadata Services (MDS)について

Oracle Metadata Services (MDS)はアプリケーション・サーバーであるとともに、ClassPath、ServletContext、データベース・リポジトリおよび場合によってはファイル・システムなどの領域にメタデータが保存されているOracleリレーショナル・データベースでもあります。MDSの主な用途の1つは、Oracleアプリケーションのカスタマイズおよび永続的なパーソナライズの内容を格納することです。MDSは、Oracle Application Development Framework (ADF)などのコンポーネントによって、メタデータの管理に使用されます。MDSが管理するメタデータ・オブジェクトには、JSPページおよびページ・フラグメント、ADFページ定義およびタスク・フロー、これらのオブジェクトのカスタマイズ版などがあります。

注意:

Oracle Metadata Service構成パラメータのほとんどは固定であり、特に指定のないかぎり実行時には変更できません。

7.2 Oracle Metadata Serviceのパフォーマンスの監視

MDSは、DMSセンサーを使用して、Enterprise Managerで参照可能なチューニングおよび診断の情報を提供しています。この情報は、MDSキャッシュのサイズが十分かどうかを確認する場合などに便利です。

DMSメトリックの情報は、Fusion Middleware Control Consoleコンソールで確認できます。ページ上部の「ヘルプ」をクリックすると、詳しい情報が表示されます。ほとんどの場合、ヘルプ・ウィンドウには現在のページに関するヘルプ・トピックが表示されます。ヘルプ・ウィンドウの「目次」をクリックして、ヘルプ・トピックのリストを参照するか、「検索」をクリックして特定の語句を検索します。

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

チューニングは、パフォーマンスを向上させるためのパラメータの調整です。MDSのデフォルト構成は、ほとんどすべてのデプロイメントでチューニングを必要とします。この項に記載されている要件および推奨事項を十分に確認してください。

7.3.1 データベース・リポジトリのチューニング

MDS APIのパフォーマンスを最適化するために、MDSリポジトリのデータベース・スキーマはデータベース管理者が監視およびチューニングを行う必要があります。この項では、データベース・リポジトリをチューニングする際の推奨措置を示します。

- 「スキーマ統計の収集」

- 「REDOログ・サイズの拡大」

- 「ディスク領域の解放」

- 「データベース・パフォーマンスの監視」

データベース・チューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のインスタンスのパフォーマンスの最適化に関する項を参照してください。

7.3.1.1 スキーマ統計の収集

MDSはデータベース索引を提供しますが、スキーマ統計が不足しているために、データベース索引が予想どおり使用されないことがあります。データベース・リポジトリのメタデータに対するアクセスや更新などのMDS操作でパフォーマンスが問題になっている場合、データベース管理者は、統計が利用でき、かつ最新であることを確認する必要があります。

次の例は、Oracleデータベースのスキーマ統計の収集方法を示しています。

execute dbms_stats.gather_schema_stats(ownname => '<username>',
estimate_percent => dbms_stats.auto_sample_size, method_opt=> 'for all
columns size auto', cascade=>true);

統計の収集後にパフォーマンスが向上しない場合は、次のコマンドを使用してデータベース共有プールをフラッシュし、既存のSQL計画を消去してください。

alter system flush shared_pool;

一般に、データベースは自動統計再収集を指定して構成します。統計収集の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』の自動パフォーマンス統計に関する項を参照してください。

7.3.1.2 REDOログ・サイズの拡大

REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下する可能性があります。

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のREDOログ・ファイルのサイズ指定に関する項を参照してください。

7.3.1.3 ディスク領域の解放

手動および自動のパージ操作を行うとメタデータの内容がリポジトリから削除されますが、表や索引が保持している領域をデータベースがただちに解放しない場合があります。その結果、MDSスキーマが消費するディスク領域は増大していきます。データベース管理者は、手動で索引を再作成して表を小さくすることで、パフォーマンスを改善するとともにディスク領域を解放できます。

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』の未使用領域の解放に関する項を参照してください。

7.3.1.4 データベース・パフォーマンスの監視

データベース管理者は、(Oracleデータベースの自動ワークロード・リポジトリ(AWR)・レポートを生成するなどの方法で)データベースを監視してロックの競合やI/O使用率を観察し、問題解決のための適切な措置を取る必要があります。

詳細は、次のドキュメントを参照してください。

- 『Oracle Databaseパフォーマンス・チューニング・ガイド』の自動ワークロード・リポジトリ・レポートの生成に関する項

- 『Oracle Database管理者ガイド』のパフォーマンスの監視に関する項

7.3.2 キャッシュ構成のチューニング

MDSでは、キャッシュを使用してメタデータ・オブジェクトおよび関連オブジェクト(XMLコンテンツなど)をメモリーに格納しています。MDSキャッシュは、(同じJVM上の)アプリケーションのすべてのユーザーがアクセスできる共有キャッシュです。メタデータ・オブジェクトが同じカスタマイズ内容で繰り返し要求される場合、そのオブジェクトはキャッシュからすばやく取得されます(ウォーム読取り)。メタデータ・オブジェクトがキャッシュ内に見つからない場合(コールド読取り)、そのオブジェクトは、それ以降の読取り操作が容易になるように、キャッシュ構成、メタデータ・オブジェクトのタイプおよびアクセス頻度に応じてキャッシュに入れられます。

キャッシュは、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのMaximumCacheSize属性にマップされます。詳細は、『Oracle Fusion Middlewareの管理』のデプロイしたアプリケーションのMDS構成属性の変更に関する項を参照してください。

注意:

Enterprise Managerで参照できるMDSメトリックは、MDSキャッシュをチューニングする際に便利です。特に、「MOコンテンツ取得当たりのIO」または「メタデータ・オブジェクト取得当たりのIO」に1より小さい値を指定する必要があります。指定しない場合は、MDSキャッシュのサイズを大きくすることを検討してください。DMSメトリックに関する情報の表示の詳細は、第7.2項「Oracle Metadata Serviceのパフォーマンスの監視」を参照してください。

正しいサイズのキャッシュがあれば、メタデータ・オブジェクトを繰り返し読み取る際のスループットを大幅に改善できます。最適なキャッシュ・サイズは、使用されるメタデータ・オブジェクトの数および個々のサイズによって異なります。Enterprise ARchive (EAR)ファイルをパッケージングする前に、adf-config.xmlのcache-configを手動で更新できます。そのためには、次のエントリを追加します。

<mds-config>
<cache-config>
<max-size-kb>200000</max-size-kb>
</cache-config>
</mds-config>

注意:

MDSキャッシュのサイズは、メタデータ・オブジェクトがアクセスされるにつれて、max-size-kbに達するまで増大していきます。max-size-kbに達すると、必要に応じてオブジェクトがキャッシュから削除されます。この処理は、新しいオブジェクトを格納できるだけの余裕を持たせるために、最低使用頻度(LRU)に基づいて行われます。

7.3.2.1 ドキュメント・キャッシュの有効化

MDSでは、メインのMDSキャッシュに加え、ドキュメント・キャッシュを各メタデータ・ストアとともに使用して、メタデータ・ドキュメント(基本ドキュメントおよびカスタマイズ・ドキュメント)のサムネイル情報をメモリーに格納します。各ドキュメントのエントリは小さく(100バイト未満)、ドキュメント・エントリ数によるキャッシュ・サイズ制限が指定されています。MDSでは、ドキュメント・キャッシュの適切なデフォルト・サイズ制限を、構成済のMDSキャッシュの最大サイズに基づいて次のように計算します。

- MDSキャッシュが無効になっている場合、デフォルトではドキュメント・キャッシュを使用しません。

- MDSキャッシュが有効になっている場合、デフォルトのドキュメント・キャッシュ・サイズは、構成済のドキュメント・キャッシュ1KB当たり1ドキュメント・エントリです。

- cache-configが指定されていない場合、デフォルトは10000ドキュメント・エントリです。

- MDSキャッシュが非常に小さい値に設定されている場合、ドキュメント・キャッシュの最小サイズとして500が使用されます。

一般に、ほとんどの場合はデフォルトで十分です。ただし、ドキュメント・キャッシュ・サイズが不足していると、パフォーマンスに影響が出ることがあります。Enterprise ARchive (EAR)ファイルをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、ドキュメント・キャッシュ・サイズを明示的に設定できます。

<metadata-store-usage id="db1">
<metadata-store …>
<property name = …/>
</metadata-store>
<document-cache max-entries="10000"/>
</metadata-store-usage>

注意:

ドキュメント・キャッシュは、document-cache max-entries値を超えるとクリアされます。パフォーマンスの問題を回避するため、次のような通知を受信した場合はドキュメント・キャッシュ・サイズを大きくすることを検討してください。

通知: ドキュメント・キャッシュDBMetadataStore : MDS Repository connection = <>で最大エントリ数<NNNN>を超えたため、キャッシュがクリアされます。

DMSメトリック「ドキュメント取得当たりのIO」(Enterprise Managerで参照可能。第7.2項を参照)に1より小さい値を指定する必要があります。指定しない場合は、ドキュメント・キャッシュ・サイズを大きくすることを検討してください。

7.3.3 ドキュメント・バージョン履歴のパージ

MDSは、データベースのメタデータ・ストアにドキュメント・バージョン履歴を保持しています。バージョン履歴が蓄積するにつれて、必要なディスク領域が増え、読取り/書込みのパフォーマンスが低下します。ドキュメント・バージョンがアクティブ・ラベルの一部でない場合は、次の2つの方法でバージョン履歴をパージできます。

- 自動パージ

- 手動パージ

注意:

バージョン履歴を手動でパージする場合、最後のパージ以降に行われたメタデータ更新の回数によっては、パフォーマンスに影響が出ることがあります。

7.3.3.1 自動パージ

自動パージ間隔は、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのAutoPurgeTimeToLive属性にマップされます。アプリケーションでMDSのデータベース・ストアが使用されている場合は、EARをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、自動パージを設定できます。

<persistence-config>
<auto-purge seconds-to-live="T"/>
</persistence-config>

上の例では、自動パージはT秒ごとに実行され、指定した時間T(秒)より古いバージョンが削除されます。詳細は、『Oracle Fusion Middlewareの管理』のデプロイしたアプリケーションのMDS構成属性の変更に関する項を参照してください。

7.3.3.2 手動パージ

データベース領域の不足やパフォーマンスの低下が疑われるときは、WLSTコマンドまたはOracle Enterprise Managerを使用して、既存のバージョン履歴を手動でパージできます。手動でのパージはパフォーマンスに影響を与えることがあるため、メンテナンス期間内やシステムの利用率が低いときにパージを行う計画を立ててください。

バージョン履歴の手動パージの詳細は、『Oracle Fusion Middlewareの管理』のメタデータ・バージョン履歴のパージに関する項を参照してください。

7.3.4 データベース・ポーリング間隔を使用した変更の検出

MDSでは、データベースに対して問合せを行い、MDSメモリー内キャッシュのデータとデータベースのデータの同期が外れているかどうかを判断する、ポーリング・スレッドを採用しています。この処理は、他のJVMでメタデータが更新されたときに発生します。同期が外れている場合、MDSは、その後の操作で最新バージョンのメタデータが参照されるように、古いキャッシュ・データをクリアします。また、MDSキャッシュだけでなくドキュメント・キャッシュも無効にするため、その後の操作では最新バージョンのメタデータが使用されます。

ポーリング間隔は、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのExternalChangeDetection属性およびExternalChangeDetectionInterval属性にマップされます。Enterprise ARchive (EAR)ファイルをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、ポーリング間隔を構成できます。

<mds-config>
<persistence-config>
<external-change-detection enabled="true" polling-interval-secs="T"/>
</persistence-config>
</mds-config>

上の例では、Tは秒単位のポーリング間隔を示しています。最小値は1です。小さい値を指定すると、他のJVMで行われたメタデータの更新がすぐに参照されます。ただし、小さい値を指定した場合は問合せが頻繁に実行されるため、中間層およびデータベースのCPU消費量が増加することに注意してください。デフォルトでは、ポーリングは有効(true)になっており、デフォルト値の30秒で大半の目的に対応できます。詳細は、『Oracle Fusion Middlewareの管理』のデプロイしたアプリケーションのMDS構成属性の変更に関する項を参照してください。

注意:

ポーリング間隔を設定する際には、次の点を考慮してください。ポーリングの頻度が高すぎると、データベースに問い合せたときに古いバージョンが取得されてしまいます。頻度が低すぎると、古いバージョンがたまっていき、ポーリングの処理に長時間かかることがあります。

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

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

7.4.1 カスタマイズがパフォーマンスに与える影響の分析

MDSをカスタマイズすると、実行時のパフォーマンスに影響が出ることがあります。カスタマイズの影響は、次のような多くの要因によって変わります。

- 作成したカスタマイズのタイプ(共有か、ユーザー・レベルか)

- システム内でメタデータ・オブジェクトがカスタマイズされている割合。この割合が低ければ、カスタマイズの影響は小さくなります。

- 構成されているカスタマイズ・レイヤーの数とカスタマイズの効率。

カスタマイズは主に2つのタイプに分けられます。

- 共有のカスタマイズ: getCacheHintメソッドがALL_USERSまたはMULTI_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、すべてまたは複数のユーザーに適用されます。共有のカスタマイズは、(共有の)MDSキャッシュにキャッシュされます。

- ユーザー・レベルのカスタマイズ(パーソナライズとも呼びます): getCacheHintメソッドがSINGLE_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、1人のユーザーのみに適用されます。ユーザーによるカスタマイズは一般に、ユーザーがログアウトするまで、そのユーザーのセッション(HttpSession)にキャッシュされます。

カスタマイズの概念とカスタマイズ・クラスの記述および構成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のMDSによるアプリケーションのカスタマイズに関する項を参照してください。

第III部

Oracle Fusion Middlewareサーバー・コンポーネント

この部では、パフォーマンスの向上を目的とするOracle Fusion Middlewareサーバー・コンポーネントの構成について説明します。次の章で構成されています。

- 第8章「Oracle Application Development Frameworkのパフォーマンス・チューニング」

- 第9章「Oracle TopLink (EclipseLink) JPAのパフォーマンス・チューニング」

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

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

- 第8.1項「Oracle ADFについて」

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

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

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

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- ADF FacesによるWebユーザー・インタフェースの開発

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 Application Development FrameworkによるFusion Webアプリケーションの開発』のOracle ADFの概要に関する項を参照してください。

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

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

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

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

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

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

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

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

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

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

ページ状態を圧縮するかどうかを制御します。データのサイズが圧縮されると、待機時間を減らすことができます。このパラメータは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です。

クライアント側ログ・レベルoracle.adf.view.rich.LOGGER_LEVEL

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

アサーション処理

oracle.adf.view.rich.ASSERT_ENABLED

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

注意:

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の使用を検討してください。

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

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

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

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

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

ページ・テンプレートとは、開発者がデータ・バインドされた再利用可能なテンプレートを作成して、これを任意のページのシェルとして使用できる機能です。開発者は、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の見栄えはよくなりますが、コストが発生します。影響が出るのはクライアント側です。これは、ブラウザがコンポーネントのサイズを変更するのに時間がかかるためです。デフォルトでジオメトリ管理の対象となるコンポーネントは次のとおりです。

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アプリケーションの開発』を参照してください。

ページに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に設定してください。

カスタム・スタイルをページ先頭で定義します。

開発者が共通して行う作業の1つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスを改善するには、スタイルをページ先頭で定義し、可能であればADFグループ・タグの内側に入れます。

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 Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

カスタム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ファイルでプロファイラを無効にします。

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

リソース・デバッグ・モードを有効にすると、ブラウザはリソース(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ライブラリですが、開発ビルド用に曖昧化されていないものも提供されます。曖昧化を行うと、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フェーズで処理されます。immediateをTRUEに設定すると、パフォーマンスが向上する場合があります。

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

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

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

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

これは高度な機能であることに注意してください。パフォーマンス向上効果のほとんどは、af:subformコンポーネントを使用すれば得られます。af:subformの詳細は、『Oracle ADF Facesによる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 ADF FacesによるWebユーザー・インタフェースの開発』のクライアント側コンポーネントに関する項を参照してください。

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

childCreationをdeferredに設定すると、コンテンツが配信されるまで、ポップアップでのコンポーネントの構成が延期されます。したがって、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 ADF FacesによるWebユーザー・インタフェースの開発』の表およびツリーの使用に関する項を参照してください。

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

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

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

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

invokeOnComponentのかわりにvisitTreeの使用を検討します。

visitTreeを使用した部分的な訪問は常に、少なくともinvokeOnComponentと同じ速さです。さらに、訪問を制御するコンポーネントの場合、invokeOnComponentおよびvisitTreeの両方の実装を提供することはエラーの原因となります。invokeOnComponentは非推奨として扱われるため、かわりにvisitTreeの使用を検討してください。

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

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

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

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

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

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

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

遅延配信(デフォルト)

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

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

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

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

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

即時配信

即時配信(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)が含まれます。サーバー・コンポーネントは自由に構成できますが、重要なのは、指定したアプリケーション・パフォーマンスおよび機能を備える使用可能リソースに最適な構成の組合せを選択することです。

注意:

ADFmを使用するときには、パフォーマンスを維持するために遅延実行の使用を検討し、リフレッシュ状態を監視してください。

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 ADF FacesによるWebユーザー・インタフェースの開発』は、ビュー・オブジェクトのチューニングに関する詳細情報を提供しています。ここでは、ビュー・オブジェクトのパフォーマンスに関するヒントをいくつか示します。

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 「ビュー・オブジェクト」ダイアログ

フェッチ・オプション

説明

フェッチ・モード

デフォルトのフェッチ・オプションは「すべての行」オプションです。この場合、必要に応じて取得(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ファイルを直接変更して、バッチ・サイズを指定したパラメータBatchThresholdをEntity属性に追加します。

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}"

注意:

パフォーマンスの影響を制限するには、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.minavailablesizeとjbo.ampool.maxavailablesize

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

jbo.ampool.timetolive

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

jbo.ampool.maxinactiveage

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

jbo.ampool.monitorsleepinterval

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

8.3.1.7 ADFc: リージョンの使用

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

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

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

注意:

領域とタスク・フローの場合、現在のviewIdを評価するためにかかる時間とフローへの入力パラメータを計算するためにかかる時間が、全体のパフォーマンスに影響することがあります。設計フェーズではこれを検討してください。

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 Application Development FrameworkによるFusion Webアプリケーションの開発』の共有アプリケーション・モジュール・ビュー・インスタンスに関する項を参照してください。

8.3.1.12 条件付き検証

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

9 Oracle TopLink (EclipseLink) JPAのパフォーマンス・チューニング

この章では、EclipseLinkに対して使用可能なパフォーマンス・チューニング機能について説明します。EclipseLinkは、Oracle TopLinkとともに使用するオープンソースの永続性フレームワークです。この章の内容は次のとおりです。

- 第9.1項「Oracle TopLinkおよびEclipseLinkについて」

- 第9.2項「チューニングに関する基本的な考慮事項」

- 第9.3項「チューニングに関する高度な考慮事項」

注意:

これらの分野におけるパフォーマンス・チューニングの詳細は、次のドキュメントを参照してください。

- 「EclipseLink Performance Tuning」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance)

- 「Performance Monitoring and Profiling」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance/Performance_Profiling)

- 「Introduction to Optimization」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance#Identifying_General_Performance_Optimization)

9.1 Oracle TopLinkおよびEclipseLinkについて

Oracle TopLinkには、オープンソースのEclipseLinkがJava Persistence API (JPA)実装として含まれています。Oracle TopLinkは、Oracle Application Serverへの高度な統合によってEclipseLinkを拡張します。

Java Persistence APIは、Java EEアプリケーションおよびJava SEアプリケーションの永続性に関する仕様です。JPAでは、永続クラスをエンティティと呼びます。エンティティとは、データベースにマップされ、アノテーションまたは永続性XML、あるいはその両方を使用してJPA経由で使用するよう構成されたPlain Old Java Object (POJO)クラスです。この章では、EJB3.0およびJava EE環境に則したJPAのチューニングに焦点を当てます。

この章の内容は、読者がEclipseLinkの基本的な機能を熟知しているものと想定して書かれています。チューニングを始める前に、次の概論に目を通すことを検討してください。

- 『EclipseLink JPA User's Guide』(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA)

- 「Considering JPA Entity Architecture」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Introduction/Architecture)

- 「Introduction to EclipseLink Queries」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying)

- 「Introduction to Cache」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)

- 「Introduction to Mapping and Configuration」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping)

Oracle TopLinkの詳細は、OTNのTopLinkページ(http://www.oracle.com/technology/products/ias/toplink/index.html)を参照してください。[Oracle TopLinkリリース11gで、旧Toplink APIは非推奨となりました。詳細は、TopLinkのリリース・ノート(http://www.oracle.com/technology/products/ias/toplink/doc/11110/relnotes/toplink-relnotes.html#CHDGAEDJ)を参照してください。]

注意:

この章は、Java EE環境に則したJPAのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。この章では、パフォーマンス・チューニングに関する一般的な考慮事項と関連のドキュメント・リソースを示しますが、チューニングが必要な分野をすべて網羅してはいません。

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

チューニングに関する次の推奨事項は、ほとんどのデプロイメントに適用できます。これらのうち、いずれの構成を実装する場合でも、その前に各自のユースケース・シナリオを検討してください。

- 効率的なSQL文およびSQL問合せの作成

- キャッシュ構成のチューニング

- マッピングおよびディスクリプタの構成のチューニング

- データのパーティション化の使用

9.2.1 効率的なSQL文およびSQL問合せの作成

この項では、効率的なSQL文およびSQL問合せの使用について説明します。表9-1と表9-2に、SQL文およびSQL問合せに関連したチューニング・パラメータとパフォーマンス上の推奨事項を示します。

表9-1 EJB/JPAでの効率的なSQL文およびSQL問合せの使用

チューニング・パラメータ

説明

パフォーマンス上の注意点

パラメータ使用のSQLのバインディング

パラメータ使用のSQLおよびプリコンパイル文のキャッシュを使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。EclipseLinkでは、パラメータ使用のSQLがデフォルトで有効になります。ただし、データベースやJDBCドライバの中には、このオプションをサポートしないものもあります。Oracle Application ServerにバンドルされているOracle JDBCドライバは、このオプションをサポートしていませんので注意してください。これを構成するには、persistence.xmlの永続性プロパティeclipselink.jdbc.bind-parametersを使用します。

関連項目: 「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)および「Querying」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying)

デフォルト値: PERSISTENCE_UNIT_DEFAULT(デフォルトでtrue)

選択したデータベースやJDBCドライバが前述のオプションをサポートしている場合は、パラメータ使用のSQLのバインディングを有効のままにしてください。

JDBC文キャッシュ

文キャッシュは、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を軽減するために使用します。文キャッシュによって、データベースを使用するアプリケーションのパフォーマンスが向上します。

注意: Java EEアプリケーションには、データ・ソースの文キャッシュを使用します(EJB3.0/JPAのEclipseLink文キャッシュは使用しません。例: "eclipselink.jdbc.cache-statements"="true")。

Oracle Weblogicデータ・ソースでこのオプションを設定するには、構成オプション「文キャッシュ・タイプ」および「文キャッシュ・サイズ」を設定します。

『Oracle WebLogic Server JDBCデータ・ソースの管理』の文キャッシュによるパフォーマンスの向上に関する項も参照してください。

デフォルト値: Oracle Weblogic Serverデータ・ソースのデフォルトの文キャッシュ・サイズは、1接続当たり文10個です。

ご使用のJDBCドライバがこのオプションをサポートしている場合は、文キャッシュを必ず有効にしてください。Oracle JDBCドライバは、このオプションをサポートしています。

フェッチ・サイズ

JDBCフェッチ・サイズは、JDBCドライバにとって、追加の行が必要な場合にデータベースからフェッチする行数のヒントとなります。

多数のオブジェクトを返す大規模な問合せに対しては、問合せで使用される行フェッチ・サイズを構成すると、選択条件を満たすのに必要なデータベース・ヒット数が少なくて済み、パフォーマンスが向上します。

ほとんどのJDBCドライバは、デフォルトのフェッチ・サイズとして10を使用します。1000個のオブジェクトを読み取る場合、フェッチ・サイズを256に増やすと、問合せ結果のフェッチに要する時間が大幅に短縮されます。

注意: デフォルト値の場合、JDBCドライバのデフォルト値が使用されます。Oracle JDBCドライバでは、通常10行です。

これを構成するには、問合せヒントeclipselink.jdbc.fetch-sizeを使用します。

デフォルト値: 0

最適なフェッチ・サイズが常に明白であるとはかぎりません。通常は、予想される総結果サイズの半分または4分の1がフェッチ・サイズとして最適です。結果セットのサイズが不確かな場合に、誤ってフェッチ・サイズの設定を大きく、または小さくしすぎると、パフォーマンスが低下する可能性がありますので、注意してください。

バッチ書込み

バッチ書込みでは、INSERT文、UPDATE文およびDELETE文をデータベースへ個別に送るのではなく、まとめて1回のトランザクションで送ることができ、データベースのパフォーマンスが向上します。

これを構成するには、persistence.xmlの永続性プロパティ"eclipselink.jdbc.batch-writing"="JDBC"を使用します。

デフォルト値: Off

永続性ユニットに対して有効にします。

変更追跡

これは、EclipseLinkによるエンティティ変更の検出方法をチューニングするための最適化機能です。

デフォルト値: ウィービングを使用する場合はAttributeLevel (Java EEのデフォルト)、それ以外の場合はDeferredです。

最適なパフォーマンスを得るには、デフォルトのAttributeLevelのままにします。

ウィービング

persistence.xmlのプロパティeclipselink.weavingを使用して無効にできます。

デフォルト値: On

最適なパフォーマンスを得るには、Onのままにします。

読取り専用

EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、EclipseLinkが作業ユニットのパフォーマンスを最適化できるようになります。

問合せヒントeclipselink.read-onlyを使用して設定します。

@ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定することもできます。

デフォルト値: False

最適なパフォーマンスを得るために、結果オブジェクトが変更されない問合せには読取り専用を使用します。

firstResultとmaxRows

これらは、大規模な問合せのページングに使用するJPA問合せプロパティです。通常、これらのプロパティは、多数の行を返す問合せの結果セット全体が必要ではない場合に使用できます。たとえば、ユーザーが特定の結果を求めて結果セットを(一度に1ページずつ)スキャンし、レコードが見つかってしまえば残りのデータは破棄するような場合です。

大きな結果セットが得られるが、オブジェクトのサブセットのみが必要になるような問合せに対して使用します。

順序番号の事前割当て

順序番号の事前割当てを行うと、一連のIDをデータベースに対して同時に問い合せることができ、挿入のたびにデータベースにアクセスしてIDを取得する必要がなくなります。

デフォルト値: 50

常に順序番号の事前割当てを使用すると、挿入のパフォーマンスが最適化されます。最適なパフォーマンスを得るには、事前割当てが行えないIDENTITY順序付けではなく、SEQUENCE順序付けまたはTABLE順序付けを使用してください。

9.2.1.1 エンティティ・リレーションシップ問合せパラメータのチューニング

表9-2に、パフォーマンス・チューニング用のエンティティ・リレーションシップ問合せパラメータを示します。

表9-2 EJB3.0エンティティ・リレーションシップ問合せのパフォーマンス・オプション

チューニング・パラメータ

説明

パフォーマンス上の注意点

バッチ・フェッチ

eclipselink.batchヒントは、EclipseLinkにバッチ処理情報を提供します。これにより、関連オブジェクトに対する後続の問合せがバッチ内で最適化されるため、オブジェクトを1つずつ取得したり、大規模な1つの結合読取りで取得したりすることを回避できます。

バッチ・フェッチにはJOIN、EXISTSおよびINの3つのタイプがあります。タイプは、問合せヒントeclipselink.batch.typeを使用して設定します。

バッチ処理は、SELECT句にオブジェクトが1つしかない問合せに対してのみ実行できます。これを構成するための問合せヒントはeclipselink.batchです。バッチ・フェッチは、@BatchFetchアノテーションを使用して設定することもできます。

デフォルト値: Off

必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。

バッチ・フェッチは、重複したデータの読取りを回避できるため、結合より効率的です。したがって、バッチ・フェッチがサポートされている問合せのパフォーマンスを最適化するには、結合読取りではなくバッチ・フェッチを使用することを検討してください。

結合フェッチ

結合フェッチとは、あるクラスの1回の問合せで、そのクラスと関連オブジェクトのインスタンス作成に必要なデータが返されるようにする、問合せ最適化機能です。

この機能は、データベース・アクセスを減らして問合せのパフォーマンスを改善するために使用します。デフォルトでは、リレーションシップに対して結合読取りは行われません。遅延ロードを使用している場合は、各リレーションシップがアクセス時に別々にフェッチされ、遅延ロードを使用していない場合は、別々のデータベース問合せとしてフェッチされます。

結合の使用は、JPQL (JOIN FETCH)で指定するか、問合せヒントeclipselink.join-fetchの中で複数のレベルで設定します。マッピング・アノテーション@JoinFetchで設定することもできます。

結合はJPA仕様の一部ですが、バッチ・フェッチは違います。また、結合の対象となるのは、バッチ・フェッチが行えない問合せです。たとえば、結合は、SELECT句に複数のオブジェクトを含む問合せ、単一の結果を返す問合せ、カーソルおよび最初/最大の結果に対して機能しますが、バッチ・フェッチは機能しません。

関連項目: 「Join Fetch」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying/Query_Hints#Join_Fetch)

デフォルト値: 使用しない

必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。SELECTのパフォーマンスを最適化するために、バッチ・フェッチがサポートされていない場合は結合を使用することをお薦めします。

遅延ロード

遅延ロードをOnにしていない場合、EclipseLinkは、永続オブジェクトを取得する際に、それが参照する従属オブジェクトをすべて取得します。リレーションシップ・マッピングによってマップされた属性に対して遅延読取り(インダイレクション、遅延ロード、ジャストインタイム読取りとも呼びます)を構成すると、EclipseLinkは被参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトを使用します。

その属性にアクセスするまで、従属オブジェクトの読取りはEclipseLinkによって遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。

関連項目: 「Lazy Loading」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Basic_Mappings/Lazy_Basics)

デフォルト値: コレクション・マッピングの場合はOn (ToManyマッピング、@OneToMany、@ManyToMany)

デフォルト値: 参照の場合はOff (ToOneマッピング、@OneToOne、@ManyToOne)

(@OneToOneおよび@ManyToOneに対して遅延ロードをOnに設定するには、ウィービングが必要です。Java EEの場合、ウィービングはデフォルトでOnになっています。)

すべてのマッピングに対して遅延ロードを使用します。遅延ロードを使用し、バッチ・フェッチまたは結合を使用して被参照オブジェクトを問い合せるほうが、即時ロードより効率的です。

リレーションシップのインスタンス化を問合せで強制できるようにするLoadGroupsとともに最適化されたロードを使用することも検討できます。

9.2.2 キャッシュ構成のチューニング

この項では、EclipseLinkに付属しているデフォルト内部キャッシュのチューニングについて説明します。Oracle Toplink/EclipseLinkは、Oracle Coherenceとも統合できます。Oracle Coherenceを使用したEclipseLinkエンティティ・キャッシュの構成およびチューニングの詳細は、第9.3.1項「Oracle Coherenceとの統合」を参照してください。

EclipseLink永続性マネージャおよびキャッシュとともに使用するEJB3.0/JPAのデフォルト設定は、ロックなし、キャッシュ・リフレッシュなしで、キャッシュの使用方法はDoNotCheckCacheです。(排他的アクセス権限がない場合に)アプリケーションでキャッシュを使用し、失効したデータをキャッシュから読み取らないようにするには、これらの設定に加えて、その他の分離関連の設定を適切に構成する必要があります。表9-3に、キャッシュ構成オプションを示します。

キャッシュ構成の詳細は、「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)を参照してください。

注意:

デフォルトでは、アプリケーションが使用データへの排他的アクセス権限を持つ(つまり、EclipseLink以外の外部アプリケーションがデータを変更することはない)ものと想定されます。アプリケーションがデータへの排他的アクセス権限を持たない場合は、表9-3に示すデフォルト値を一部変更する必要があります。

表9-3 EJB3.0 JPAエンティティとキャッシュ構成オプション

チューニング・パラメータ

説明

パフォーマンス上の注意点

オブジェクト・キャッシュ

EclipseLinkセッションには、オブジェクト・キャッシュが用意されています。EclipseLink永続性マネージャを使用するEJB3.0 JPAアプリケーションでは、このキャッシュをデフォルトで使用するEclipseLinkセッションが作成されます。セッション・キャッシュと呼ばれるこのキャッシュには、データベースとの間で読み書きされたオブジェクトの情報が格納されます。セッション・キャッシュは、EclipseLinkアプリケーションのパフォーマンスを改善するための重要な要素の1つです。

通常、サーバー・セッションのオブジェクト・キャッシュは、そのセッションから取得されたすべてのクライアント・セッションで共有されます。分離セッションは、共有オブジェクト・キャッシュから分離された固有のセッション・キャッシュを備えています。

アノテーション・タイプ@Cacheableは、エンティティをキャッシュするかどうかを指定します。persistence.xmlのキャッシュ要素の値がENABLE_SELECTIVEまたはDISABLE_SELECTIVEの場合、キャッシュは有効です。Cacheableアノテーションの値は、サブクラスによって継承されます。つまり、Cacheableをサブクラスで指定すると上書きできます。

Cacheable(false)は、プロバイダがエンティティとその状態をキャッシュする必要がないことを意味します。

デフォルト値: 有効(sharedがTrue)

一般に、キャッシュは有効にしておくことをお薦めします。常にデータベースから読み取られるオブジェクト(ペシミスティック・ロックの対象となるオブジェクトなど)がある場合は、そのエンティティのキャッシュを無効にしてください。また、アクセス頻度の低いエンティティのキャッシュを無効にすることも検討してください。

問合せ結果セット・キャッシュ

EclipseLinkでは、オブジェクト・キャッシュに加えて、問合せキャッシュもサポートされています。

- オブジェクト・キャッシュでは、主キーによってオブジェクトが索引付けされるため、主キー問合せでキャッシュ・ヒットを取得できます。オブジェクト・キャッシュを使用すれば、オブジェクトがすでに存在する場合に、データ・ソースにアクセスする問合せでオブジェクトとそのリレーションシップを構築するコストが発生しません。

- 問合せキャッシュは、オブジェクト・キャッシュと異なります。問合せキャッシュの索引は、オブジェクトの主キーではなく、問合せおよび問合せパラメータによって作成されます。そのため、同じパラメータで実行したどの問合せでも、問合せキャッシュ・ヒットを取得し、同じ結果セットを返すことができます。

問合せキャッシュの問合せヒントには次のものがあります。

eclipselink.query-cache

eclipselink.query-cache.size

eclipselink.query-cache.invalidation

関連項目: 「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)および「EclipseLink JPA Query Hints」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying/Query_Hints)

デフォルト値: 使用しない

主キー以外のキーで頻繁に実行される問合せのうち、結果セットがあまり変わらないものに使用します。キャッシュ無効化タイムアウトとともに使用すると、必要に応じてリフレッシュができます。

キャッシュ・サイズ

キャッシュ・サイズは、次の永続性プロパティを使用して構成します。eclipselink.cache.size.<entity>

"eclipselink.cache.size.default"

eclipselink.cache.type.default

関連項目: 「Configuring Persistence Units Using persistence.xml」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Configuration/JPA/persistence.xml)および「Class PersistenceUnitProperties」(http://www.eclipse.org/eclipselink/api/2.3/org/eclipse/persistence/config/PersistenceUnitProperties.html)

デフォルト値: タイプSoftWeak、サイズ100 (1エンティティ当たり)。

使用可能なメモリーの量、使用するクラスのインスタンス数、エンティティのアクセス頻度、および失効したデータの許容度に基づいたキャッシュの必要量を基準に、キャッシュ・サイズを設定します。

アクセス頻度の高いインスタンスが多いエンティティや、失効したデータが大した問題にはならないエンティティについては、サイズの大きなキャッシュを作成することを検討してください。

更新頻度が高く、常に最新のデータが必要とされるエンティティや、アクセス頻度の低いエンティティには、小さなキャッシュ・サイズを使用するか、キャッシュをまったく使用しないことを検討してください。

ロック

Oracleでは、表9-4に示すロック・ポリシー(ロックなし、オプティミスティック、ペシミスティック、読取り専用)をサポートしています。

ロックは、JPAの@Versionアノテーションeclipselink.read-onlyを使用して設定します。

「How to Use EclipseLink Locking」(http://wiki.eclipse.org/EclipseLink/Examples/JPA/Locking)

デフォルト値: ロックなし

同時に更新可能なエンティティには、ユーザーが他のユーザーの変更を上書きできないようなロック・ポリシーを使用することを検討してください。読取り専用エンティティのパフォーマンスを最適化するには、エンティティを読取り専用として定義するか、読取り専用の問合せヒントを使用することを検討してください。

キャッシュの使用方法

デフォルトでは、どのタイプの問合せも、まずデータベースを検索してからキャッシュと同期を取ります。問合せにリフレッシュが設定されている場合を除き、キャッシュされたオブジェクトはデータベースからリフレッシュされずに返されます。特定の問合せを、メモリー内キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。

すでにキャッシュにあるオブジェクトがデータベースで検索されるのを防いでパフォーマンスを向上させるには、検索の際に必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみデータ・ソース内を検索するよう構成します。主キーに基づいて単一オブジェクトを検索する問合せについては、問合せヒントeclipselink.cache-usageをCheckCacheByExactPrimaryKeyに設定します。

デフォルト値: DoNotCheckCache

通常はデータがキャッシュにあり、リフレッシュ処理をそれほど必要としない場合に、主キー問合せのパフォーマンスを高速化するには、まず主キー問合せでキャッシュをチェックすることをお薦めします(CheckCacheByExactPrimaryKeyを使用)。

これにより、まずデータベースからオブジェクトを取得した後、すでにキャッシュにあるオブジェクトを検索し、キャッシュされた値(問合せにリフレッシュが設定されている場合を除き、データベース・アクセスによって更新されていない)を返すというデフォルト動作を回避できます。

分離

EclipseLinkを使用するJPAアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。

一般的なEJB3.0 JPAアプリケーションでは、データベース・トランザクションの分離レベルが適用されるタイミング、および特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響を与えます。

- ロック・モード

- セッション・キャッシュの使用

- 外部アプリケーション

- データベース・ログイン・メソッドsetTransactionIsolation

関連項目: 「Shared and Isolated Cache」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Shared_and_Isolated)

キャッシュのリフレッシュ

デフォルトでは、EclipseLinkはデータ・ソースから読み取ったオブジェクトをキャッシュします。このオブジェクトに対する後続の問合せではキャッシュへのアクセスが行われるため、データ・ソースへのアクセスが減るとともに、オブジェクトとそのリレーションシップを再構築するコストも発生せず、パフォーマンスが向上します。問合せでデータ・ソースにアクセスする場合でも、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、EclipseLinkはキャッシュされたオブジェクトを使用します。このデフォルトのキャッシュ・ポリシーは、失効したデータがアプリケーション内に生じる原因となります。

リフレッシュは、エンティティ・レベル(alwaysRefreshまたはrefreshOnlyIfNewerとexpiry)および問合せレベル(eclipselink.refresh問合せヒントを使用)で有効にできます。また、disableHitsを使用して、問合せが必ずデータベースに送られるようにすることも可能です。失効したデータや競合するデータがデータベースにコミットされないようにするには、適切なロック・ポリシーを使用するしかありません。

詳細は、第9.2.2.1項「キャッシュ・リフレッシュのシナリオ」を参照してください。

関連項目: 「Caching Overview」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Caching_Overview)

デフォルト値: キャッシュのリフレッシュなし

エンティティ・レベルでのキャッシュのリフレッシュはできるかぎり避け、かわりに次の構成を検討してください。

- 問合せごとのキャッシュのリフレッシュ

- キャッシュの有効期限

- 分離キャッシュ

9.2.2.1 キャッシュ・リフレッシュのシナリオ

キャッシュでのデータのリフレッシュに関して、考慮すべきシナリオがいくつかあります。これらのシナリオはいずれも、パフォーマンスに影響を与えます。

- キャッシュされたデータではなく、最新のデータが常に必要な場合は、分離キャッシュ(Shared=False)を使用することを検討してください。これに当てはまるのは、アプリケーション内の特定のデータが頻繁に変更されるため、競合が検出されたときにのみデータをリフレッシュするのではなく、常にデータをリフレッシュすることが望ましいような場合です。

- 失効したデータは使用したくないが、失効したデータを取得することになっても大した問題ではないという場合は、解決策としてキャッシュ失効ポリシーを使用することをお薦めします。この場合は、ロック・エラー発生時に失効したオブジェクトを自動的にリフレッシュする、オプティミスティック・ロックも使用してください。オプティミスティック・ロックを使用する場合は、エンティティの@Cache属性であるalwaysRefreshおよびrefreshOnlyIfNewerをさらに有効にすると、データベースにアクセスする問合せで、返された失効オブジェクトをリフレッシュできるとともに、無効なオブジェクトが変更されていない場合はリフレッシュしないようにできます。また、リフレッシュされたデータが必要であることがわかっている場合に、特定の問合せ操作に対してリフレッシュを有効にしたり、クライアントから取得したデータをリフレッシュするオプション(リフレッシュ問合せをコールするもの)を提供したりすることもできます。

- データが失効していても問題ない場合は、オプティミスティック・ロックを使用してください。そうすると、ロック・エラーの際にキャッシュ内の失効したオブジェクトが自動的にリフレッシュされます。

9.2.2.2 ロック・モード・ポリシーのチューニング

表9-4に示すロック・モードを、EclipseLinkのキャッシュ使用方法および問合せリフレッシュのオプションとともに使用すると、JPAを使用するEJBエンティティのデータ一貫性が保証されます。どの組合せも機能とパフォーマンスの両面に影響を与えますが、これらのオプションの設定は、たとえパフォーマンスのコストが発生したとしても、データを最新で一貫した状態に保つための機能上の要件を優先して決めるのが一般的です。

詳細は、「Locking」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking)を参照してください。

表9-4 ロック・モード・ポリシー

ロック・オプション

説明

パフォーマンス上の注意点

ロックなし

ユーザーが別のユーザーの変更内容を上書きできます。これはデフォルトのロック・モードです。エンティティが同時に更新されることがない場合や、read-committedセマンティクスによる同じ行の同時読取りおよび更新で十分な場合は、このモードを使用します。

デフォルト値: ロックなし

通常はロックなしのほうが高速ですが、データ一貫性のニーズには対応できない場合があります。

オプティミスティック

すべてのユーザーがデータへの読取りアクセス権限を持ちます。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。

関連項目: 「Optimistic Locking」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking/Optimistic_Locking)

同じ行に対する同時更新を頻繁には実行しないと予想される場合、オプティミスティック・ロックを使用すれば、最適なパフォーマンスを得ながら、データの一貫性も保証することができます。

ペシミスティック

更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。

同じ行に対して頻繁に同時更新を実行することが予想される場合、同時アクセスの例外および再試行が多数発生するオプティミスティック・ロックより、ペシミスティック・ロックのほうが高速になることがあります。

エンティティ・レベルでペシミスティック・ロックを使用する場合は、最適なパフォーマンスを得るために、分離キャッシュ(Shared=False)を併用することをお薦めします。

読取り専用

EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、EclipseLinkが作業ユニットのパフォーマンスを最適化できるようになります。

@ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定します。問合せヒントeclipselink.read-onlyを使用して、問合せレベルで設定することもできます。

エンティティを読取り専用として定義すると、読取り専用として定義されていないが、挿入、更新または削除を行わないエンティティよりも、パフォーマンスが向上します。これは、EclipseLinkによる作業ユニットのパフォーマンスの最適化が可能になるためです。すべての読取り専用操作に対して、常に読取り専用を使用してください。

9.2.3 マッピングおよびディスクリプタの構成のチューニング

EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びます。マッピングは、EclipseLinkプロジェクトの中核をなしています。

マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。

マッピングの詳細は、「Configuring Mappings」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping)を参照してください。

9.2.4 データのパーティション化の使用

EclipseLinkでは、@Partitionedアノテーションを使用してデータのパーティション化を構成できます。パーティション化すると、アプリケーションはクラスタ・データベースなどの複数のデータベース間で情報を増減できます。@Partionedおよびその他のパーティション・ポリシー・アノテーションの使用方法の詳細は、「Data Partitioning」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Data_Partitioning)を参照してください。

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

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

- Oracle Coherenceとの統合

- EclipseLink JPAエンティティのパフォーマンス分析

9.3.1 Oracle Coherenceとの統合

Oracle Toplinkは、Oracle Coherenceと統合できます。この統合は、Oracle TopLink Grid機能によって実現されます。TopLink Gridを使用したEclipseLink JPAとの統合には、いくつかの種類があります。

例:

- EclipseLinkのデフォルトL2キャッシュをCoherenceに置き換えます。こうすることで、クラスタ・ノード全体をカバーする非常に大きなL2キャッシュがサポートされます。EclipseLinkのデフォルトL2キャッシュは、Java EEでホストされたマルチスレッド・アプリケーションが単一のJVMで稼働する場合のパフォーマンスを高めます。これをクラスタ全体で使用する場合は、特殊なキャッシュ調整機能を構成する必要があります。

- データベースではなく、Coherenceのデータ・グリッド内で問合せを実行するよう、エンティティを構成します。こうすると、クラスタ化されたアプリケーション・デプロイメントを、データベースがボトルネックとなるような操作を越えて拡張できます。

EclipseLink JPAとCoherenceキャッシュの併用の詳細は、グリッド上のJPA手法に関する項(http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/tlgug003.htm)を参照してください。

Oracle ToplinkとOracle Coherenceとの統合の詳細は、Oracle TopLinkとCoherenceグリッドとの統合ガイド(http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/toc.htm)を参照してください。

9.3.2 EclipseLink JPAエンティティのパフォーマンス分析

この項では、JPAアプリケーションのパフォーマンス分析に役立つEclipseLinkの機能をいくつか示します。

- パフォーマンスの監視の詳細は、『EclipseLink User's Guide』の「Performance Monitoring」を参照してください。このツールは、マルチスレッド化されたサーバー環境の情報をプロファイルおよび監視することを目的としています。

- パフォーマンスのプロファイリングについては、『EclipseLink User's Guide』の「Measuring EclipseLink Performance with the EclipseLink Profiler」を参照してください。このツールは、シングルスレッドの限定的なユースケースでの使用を想定しています。

- パフォーマンスの問題のデバッグおよびテストを行う場合、EclipseLinkから生成されたSQLを確認できます。SQLを確認するには、ロギング用のEclipseLink JPA拡張機能を使用して、ロギング・レベルをFINEに上げます。
最適なパフォーマンスを得るために、プロファイリングまたはデバッグが終了したら、必ずロギング・レベルをデフォルト・レベルに戻してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。