Oracle® Fusion Middleware

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

12c (12.1.3)

E56213-03(原本部品番号:E42117-03)

2015年1月

Oracle Fusion Middleware環境において、パフォーマンスのモニターと最適化、最適なパフォーマンスを得るためのコンポーネントの構成を行う方法について説明します。

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

E56213-03

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

原本著者: Hannah Cheng

原本協力著者: Peter Laquerre、Lisa Jamen、Jayaram Kasi

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

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

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

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)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

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

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、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 データベース・ファイルのチューニング

- 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 リクエスト・トラッカの宛先

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

- 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 Serverディレクティブのチューニング

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

- 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のチューニング

- 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 カスタマイズがパフォーマンスに与える影響の分析

8 Oracle Fusion Middlewareのセキュリティ・パフォーマンスのチューニング

- 8.1 セキュリティ・サービスについて

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

- 8.3 Oracle Platform Security Servicesのチューニング

- 8.3.1 JVMチューニング・パラメータ

- 8.3.2 JDKチューニング・パラメータ

- 8.3.3 認証チューニング・パラメータ

- 8.3.4 認可チューニング・プロパティ

- 8.3.5 OPSS PDPサービス・チューニング・パラメータ

- 8.4 Oracle Web Services Securityのチューニング

- 8.4.1 適切なポリシーの選択

- 8.4.2 ポリシー・マネージャ

- 8.4.3 SOAPメッセージを記録するためのログ・アサーションの構成

- 8.4.4 接続プーリングの構成

- 8.4.5 Webサービスのパフォーマンスのモニタリング

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

9 Oracle Application Development Framework (ADF)のチューニング

- 9.1 Oracle ADFについて

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 9.3.1.3 バッチ処理

- 9.3.1.4 RangeSizeチューニング

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

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

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

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

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

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

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

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

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

- 9.3.1.11 静的データの再利用

- 9.3.1.12 条件付き検証

10 Oracle TopLinkのチューニング

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

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

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

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

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

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

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

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

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

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

- 10.3.1 Oracle Coherenceとの統合

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

第IV部 SOA Suiteコンポーネント

11 SOAインフラストラクチャのチューニング

- 11.1 SOAインフラストラクチャについて

- 11.2 SOAワーク・マネージャのチューニング

- 11.2.1 SOADataSourceプロパティでのデータベース接続の構成

- 11.2.2 SOAMaxThreadsConfig属性でのワーク・マネージャの構成

- 11.3 SOAインフラストラクチャのパラメータのチューニング

- 11.4 高度なチューニング・オプションの使用

- 11.4.1 コンポジットの遅延ロード機能の有効化

- 11.4.1.1 ドメイン・レベルでのコンポジット遅延ロードの構成

- 11.4.1.2 コンポーネント・レベルでのコンポジット遅延ロードの構成

- 11.4.2 モジュール性のプロファイルの変更

- 11.4.3 SOAプロセスのデータベースのチューニング

- 11.4.3.1 オプティマイザ統計の収集

- 11.4.3.1.1 自動統計収集

- 11.4.3.1.2 手動統計収集

- 11.4.3.1.3 統計によるMDSデータベース・リポジトリの最適化

- 11.4.3.2 SOAの一時表領域のチューニング

- 11.4.3.3 SOAデータベース競合の最小化

- 11.4.3.3.1 log file sync

- 11.4.3.3.2 enq:HW contention

- 11.4.3.3.3 enq:TX-indexcontention

- 11.4.3.4 パージ

- 11.4.3.5 領域の再利用

- 11.4.4 イベント配信ネットワーク・パラメータのチューニング

- 11.4.4.1 マッピングによるJMSトピックの追加

- 11.4.5 WebLogic Serverのチューニング

- 11.5 ワーク・マネージャの高度なチューニング

- 11.5.1 SOAワーク・マネージャ用のフェア・シェア・リクエスト・クラスの構成

- 11.5.2 新しいワーク・マネージャの制約の作成

12 Oracle BPEL Process Managerのチューニング

- 12.1 BPEL Process Managerについて

- 12.2 BPELパラメータのチューニング

- 12.2.1 BPELエンジンのチューニング

- 12.2.1.1 BPELエンジンのパラメータのチューニング

- 12.2.2 コンポジットでのBPELのチューニング

- 12.3 その他のチューニング戦略の使用

- 12.3.1 インスタンス・データ増大の影響を受ける表の識別

- 12.3.2 コンポジット・インスタンスの表示中の頻繁なトランザクション・タイムアウトのトラブルシューティング

13 Oracle Mediatorのチューニング

- 13.1 Oracle Mediatorについて

- 13.2 Mediatorのパラメータのチューニング

- 13.2.1 メッセージに対するリシーケンサの使用

14 Oracle Managed File Transferのチューニング

- 14.1 Managed File Transferについて

- 14.2 MFTパラメータのチューニング

- 14.2.1 リモートFTP / SFTP/ FILE タイプのソースのチューニング

- 14.2.2 MDSラベルの最小化

- 14.2.3 マテリアライズド・ビューのリフレッシュ間隔の調整

15 Oracle Business Rulesのチューニング

- 15.1 Oracle Business Rulesについて

- 15.2 Oracle Business Rulesのチューニング

16 Oracle Business Process Managementのチューニング

- 16.1 Oracle Business Process Managementについて

- 16.2 Business Process Managementのパラメータのチューニング

- 16.3 その他のチューニング戦略の使用

- 16.3.1 Oracleワークスペース・アプリケーションのチューニング

- 16.3.2 プロセス測定

17 Oracle Human Workflowのチューニング

- 17.1 Oracle Human Workflowについて

- 17.2 ヒューマン・ワークフローのチューニング

- 17.3 その他のチューニング戦略の使用

- 17.3.1 サーバーのパフォーマンスの向上

- 17.3.2 ワークフロー完了の迅速化

- 17.3.3 アイデンティティ・プロバイダのチューニング

- 17.3.4 データベースのチューニング

18 Oracle Business Activity Monitoringのチューニング

- 18.1 Oracle Business Activity Monitoringについて

- 18.2 BAMサーバーのパラメータのチューニング

- 18.3 その他のチューニング戦略

- 18.3.1 索引列の作成

- 18.3.2 ロガーのチューニング

- 18.3.3 連続した問合せサービスのチューニング

19 Oracle Service Busのチューニング

- 19.1 Oracle Service Busについて

- 19.2 OSBパラメータのチューニング

- 19.2.1 ワーク・マネージャを使用したOracle Service Busのチューニング

- 19.2.2 OSB操作設定のチューニング

- 19.3 その他のチューニング戦略の使用

- 19.3.1 OSBのリシーケンサのチューニング

- 19.3.2 プロキシ・アプリケーションの設計時の考慮事項

- 19.3.3 XQueryのチューニング

- 19.3.4 ポーラーベースのトランスポートのチューニング

- 19.3.4.1 ポーリング間隔

- 19.3.4.2 読取り制限

20 Oracle Enterprise Scheduler Serviceのチューニング

- 20.1 エンタープライズ・スケジューラ・サービスについて

- 20.2 エンタープライズ・スケジューラ・サービスのパラメータのチューニング

はじめに

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

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

- 対象読者

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

- 表記規則

対象読者

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

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

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

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のチューニング」では、Oracle Metadata Service (MDS)のチューニングのヒントを示します。MDSは、Oracle Application Development Frameworkにより、メタデータの管理に使用されます。

- 第8項「Oracle Fusion Middlewareのセキュリティ・パフォーマンスのチューニング」では、Oracle Platform Security for Javaを取り上げます。Oracle Platform Security for Javaは、Java Authentication and Authorization Service (JAAS)やJava EEセキュリティなどのJava機能に対応したOracle Fusion Middlewareセキュリティ実装です。この章では、最適なパフォーマンスを得るための構成方法について説明します。

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

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

- 第11章「SOAインフラストラクチャのチューニング」では、Oracle Service-Oriented Architecture (SOA) Suiteコンポーネントを構成してパフォーマンスを改善するための一般的なSOAインフラストラクチャ・チューニング・パラメータについて説明します。Oracle SOA Suiteは、SOAコンポジット・アプリケーションの設計、デプロイおよび管理を目的とするサービス・インフラストラクチャ・コンポーネント一式を備えています。Oracle SOA Suiteでは、サービスを作成して管理し、SOAコンポジット・アプリケーションに組み込むことが可能です。コンポジットを使用すれば、複数のテクノロジ・コンポーネントを組み合せて1つのSOAコンポジット・アプリケーションを簡単に作成できます。

- 第12章「Oracle BPEL Process Managerのチューニング」では、プロセス・レベル、ドメイン・レベルおよびアプリケーション・サーバー・レベルでパフォーマンスを最適化するために構成できるいくつかのBPELプロパティ設定を取り上げます。この章では、各プロパティ設定について説明し、プロパティ設定の使用方法に関する推奨事項を示します。

- 第13章「Oracle Mediatorのチューニング」では、Oracle SOAサービス・インフラストラクチャ内のサービス・エンジンであるOracle Mediatorをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle Mediatorは、サービスおよびイベントの各種プロバイダとコンシューマを仲介するフレームワークを提供します。メディエータ・サービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーションと連携して動作します。

- 第14章「Oracle Managed File Transferの監視」では、12c (12.1.3)の新しい製品であるOracle Managed File Transferのチューニング方法について説明します。Oracle Managed File Transfer (MFT)は、パフォーマンスが高く、標準ベースのエンドツーエンド管理対象ファイル・ゲートウェイです。これは、ファイル暗号化、スケジュール、埋込みFTPおよびsFTPサーバーを含む軽量のWebベース設計時コンソールを使用した設計、デプロイメントおよびファイル転送のモニタリングを特徴とします。

- 第15章「Oracle Business Rulesのチューニング」では、ビジネス・ルールを自動化できるテクノロジについて説明し、JavaコードやBPELプロセスといった手続き型ロジックからのビジネス・ルールの抽出についても触れます。

- 第16章「Oracle Business Process Managementのチューニング」では、Oracle Business Process Management (BPM)のチューニング方法について説明し、Oracle Business Process Management (BPM)は、設計時および実装からランタイムおよびアプリケーション管理まで、アプリケーション開発ライフサイクルの全ステージのシームレスな統合を提供します。

- 第17章「Oracle Human Workflowのチューニング」では、Oracle Human Workflowをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャ内で稼働するサービス・エンジンです。これを使用すると、対話型の人的プロセスを実行できます。ヒューマン・ワークフローは、プロセスの内部または外部で行われる承認処理、却下処理、再割当て処理といった人間のやり取りに対応しています。Human Workflowサービスは、ビジネス・プロセスと人間とのやり取りの様々な側面を処理する多くのサービスからなります。

- 第18章「Oracle Business Activity Monitoringのチューニング」では、Oracle Business Activity Monitoringダッシュボード・アプリケーションをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle Business Activity Monitoring (BAM)は、企業のビジネス・サービスおよびプロセスをモニタリングするためのツールを備えています。

- 第19章「Oracle Service Busのチューニング」では、接続性、ルーティング、仲介、管理および一部のプロセス編成機能を提供するOracle Service Busのチューニング方法を説明します。これは、2つ以上のアプリケーション(サーバー)の中間機能の役割を果たす大規模なシステムの一部です。

- 第20章「Oracle Enterprise Scheduler Serviceのチューニング」では、Oracle Enterprise Scheduler Serviceのチューニング方法について説明しますが、Oracle Enterprise Scheduler Serviceは、作業割当てを作成するルールを使用して、特定の時間枠または作業シフト内でジョブをスケジュールおよび実行できるようにします。

1.3 関連ドキュメント

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

- 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のデータベース・チューニング情報のサブセットです。また、データベース・パフォーマンス・チューニング・ガイドを参照したことも確認してください。

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

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

- データベース・ファイルのチューニング

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

注意:
必ず、ご使用のデータベースのベンダー・ドキュメントでチューニングに関するガイドラインを確認してください。

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

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

SOA用に使用されるデータベースは、提案値で構成されます。データベースのチューニングでは、データベースにおける負荷と使用可能なリソースに基づいて、サイズ設定パラメータの調整が必要です。

表2-2のsga_target、pga_aggregate_targetおよびprocessesのパラメータは、SGAとPGAのアドバイザに基づいてチューニングし、開いているプロセスの数をピーク負荷時に調べる必要があるそのようなパラメータの例です。

表2-2 重要なOracle 12cデータベース・チューニング・パラメータ

パラメータ

説明

チューニングに関する推奨事項

audit_trail

デフォルト: DB

このパラメータは、データベース監査を有効または無効にします。

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

plsql_code_type

デフォルト: INTERPRETED

PLSQL_CODE_TYPEには、PL/SQLライブラリ・ユニットのコンパイル・モードを指定します。可能なモードは次のとおりです。

- INTERPRETED: PL/SQLライブラリ単位は、PL/SQLバイトコード形式にコンパイルされます。この形式のモジュールは、PL/SQLインタプリタ・エンジンによって実行されます。

- NATIVE: PL/SQLライブラリ単位は、ネイティブ(マシン)・コードにコンパイルされます。この形式のモジュールはネイティブに実行されるため、インタプリタの影響を受けません。

このパラメータをNATIVEに設定します。

nls_sort

デフォルト: NLS_LANGUAGEから導出

NLS_SORTには、ORDER BY問合せの照合順序を指定します。

- 値が名前付き言語ソートの場合、照合順序は定義されている言語ソートの順序に基づきます。NLS_LANGUAGEパラメータでサポートされるほとんどの言語は、同名の言語ソートもサポートします。

- 値がBINARYに設定されている場合、照合順序は文字の数値に基づきます。これにより、必要とするシステム・リソースは少なくてすみます。

このパラメータをBINARYに設定します。

open_cursors

デフォルト: 50

このパラメータは、セッションで一度に保持できるオープン・カーソルの最大数を指定します。オープン・カーソルは、プライベートSQL領域へのハンドルです。

OPEN_CURSORS値には、アプリケーションでオープン・カーソルが不足しないように十分な値を設定してください。

このパラメータを500に大きくします。

session_cached_cursors

デフォルト: 50

このパラメータには、キャッシュするセッション・カーソルの数を指定します。同じSQL文の解析コールを繰り返すと、その文のセッション・カーソルがセッション・カーソル・キャッシュに移動されます。その後の解析コールではキャッシュ内のカーソルが使用され、カーソルは再オープンされません。Oracleでは、最低使用頻度アルゴリズムを使用してセッション・カーソル・キャッシュ内のエントリを削除し、必要なときに新規エントリのために領域を空けます。

このパラメータは、文が再実行されたときに再解析を行わなくてもよいようにPL/SQLで使用される、PL/SQLカーソル・キャッシュのサイズも制限します。

このパラメータを500に大きくします。

_b_tree_bitmap_plans

デフォルト: TRUE

このパラメータにより、Bツリー索引のビットマップ・アクセス・パスの使用を有効化または無効化します。

このパラメータをFALSEに設定します。

processes

デフォルト: 100

このパラメータはOracleに同時に接続可能なオペレーティング・システム・プロセスの最大数を設定します。このパラメータの値には、Oracleバックグラウンド・プロセスの数を含める必要があります。

SESSIONSパラメータはこの値から導出されます。

大半のシステムでは、このパラメータ値を1500に大きくすることで十分です。

ユーザー数が多いデータベースなど、大規模のシステムでは、推奨値は5000です。

Memory_target

MEMORY_TARGETには、Oracleシステム全体で使用可能なメモリーを指定します。データベースでは、SGAおよびPGAを必要に応じて縮小または拡大して、メモリーをMEMORY_TARGETの値にチューニングします。

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

sga_target

デフォルト: 0

このパラメータをゼロ以外の値に設定すると、自動共有メモリー管理が有効になります。これにより構成を単純にでき、パフォーマンスを向上できます。

小規模のシステムでは、最小値の2GBを使用します。

大規模のシステムでは、これを18GBに設定します。

pga_aggregate_target

デフォルト: 0

インスタンスにアタッチしたすべてのサーバー・プロセスで使用可能なターゲット集計PGAメモリーをこのパラメータにより指定します。

小規模のシステムでは、最小値の1GBを使用します。

大規模のシステムでは、これを8GBに設定します。

Disk_asynch_io

デフォルト: TRUE

データ・ファイル、制御ファイルおよびログ・ファイルのI/Oが非同期であるかどうかをDISK_ASYNCH_IOにより制御します。表スキャン中にI/OリクエストをCPU処理と同時実行可能なパラレル・サーバー・プロセスを決定します。

ご使用のプラットフォームが非同期I/Oをサポートしている場合、このパラメータをデフォルト値のTRUEのままにします。

それ以外の場合は、FALSEに設定します。

Filesystemio_options

デフォルト: なし

FILESYSTEMIO_OPTIONSには、ファイル・システム・ファイルに対する特定のI/O操作を指定します。

このパラメータをSETALLに設定します。

Secure_Files

デフォルト: PERMITTED

このパラメータにより、表からLOBオブジェクトを格納する方法を指定します。

このパラメータをALWAYSに設定します。

parallel_max_servers

デフォルト: PARALLEL_THREADS_PER_CPU*CPU_COUNT*concurrent_parallel_users*5

このパラメータは、インスタンスのパラレル実行プロセスおよびパラレル・リカバリ・プロセスの最大数を指定します。

需要が増加するにつれて、Oracle Databaseではインスタンスの起動時に作成された数からこの値までプロセス数が増加します。

このパラメータを12に設定します。

job_queue_processe

be
デフォルト: 1000

DBMS_JOBジョブおよびOracle Scheduler(DBMS_SCHEDULER)ジョブの実行用に作成可能な、インスタンスごとのジョブ・スレーブの最大数を指定します。

このパラメータを12に設定します。

shared_servers

デフォルト: 0(または)1

インスタンスの起動時に作成するサーバー・プロセスの数を指定します。

このパラメータを0に設定します。

さらに、SHARED_POOL_SIZEとDB_CACHE_SIZEの最小値を設定して、頻繁にサイズ変更することを最小限にすることを検討する場合があります。

2.6.2 データベース・ファイルのチューニング

データベース・パラメータのチューニングに加えて、データベース管理者は、REDOログ、UNDO表領域およびTEMP表領域を適切に構成し、発生したり検出したデータベース・ワークロードの需要を満たす必要があります。これは、経験に基づく作業です。この項の推奨事項は、これらの領域における初期ガイドを示すことを意図しています。

データベース・ファイルの場所をI/Oパフォーマンスと増大のために最適化する必要があります。セグメント・アドバイザを利用して、セグメント領域の使用を最適化し、パフォーマンス低下が発生しないようにする必要があります。また、セグメントのこれまでの増加傾向を提示でき、プロアクティブな成長計画に使用できます。詳細は、『Oracle Database管理者ガイド』のセグメント・アドバイザの使用に関する項を参照してください。

REDOログ

負荷の高いワークロードの状況では、REDOログ・ファイルのサイズがパフォーマンスに影響することがあります。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。サイズが小さいログ・ファイルにより、チェックポイント・アクティビティとログ・ファイル切替えが増加し、パフォーマンスが低下します。Enterprise Managerの「REDOログ・グループ」ページでサイズ設定のアドバイスを入手できます。

記憶域の構成とパフォーマンスの特徴によっては、REDOログを再分散して、I/Oパフォーマンスを最適化する必要が発生する場合があります。I/Oパフォーマンスを向上させるには、REDOログ・ファイルをデータ・ファイルとは別のディスク上に配置してください。

詳細は、『Oracle Database管理者ガイド』のREDOログの管理に関する項を参照してください。

UNDO表領域

UNDO表領域の最小提案サイズは、自動拡張が有効な状態で6GBです。自動UNDO管理のデフォルト・モードを利用して、パフォーマンスと効率を最大化することをお薦めします。

Oracle Enterprise Managerの自動UNDO管理アドバイザを利用して、UNDO表領域と保存設定の構成詳細を設定する必要があります。また、このアドバイザによりUNDOアドバイザにアクセスして新しいUNDO保存設定の影響が評価され、アドバイスが提示されます。アドバイザの使用方法の詳細は、『Oracle Database管理者ガイド』のUNDOアドバイザPL/SQLインタフェースに関する項を参照してください。

TEMP表領域

UNIFORMエクステントがありデフォルト・サイズが1MBのローカル管理一時表領域を使用することをお薦めします。

SOA用TEMP表領域のチューニングの詳細は、第11.4.3.2項を参照してください。

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には、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フェーズで要した最短の時間を示します。

オプションのメトリック

sensor_name.maxTime

sensor_nameフェーズが完了するのにかかったすべての時間の中で、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サーバーなどの非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)の使用のスタート・ガイド

- 『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のDMSメトリック・コマンドに関する項

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

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

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

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

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

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

- Oracle Serverのルート・タスク

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

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

- Oracle Serverのルート・タスク

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

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

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

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

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

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

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

1. Oracle 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センサー・ライフサイクル・イベント(状態センサー、イベント・センサーおよびフェーズ・センサーの作成、更新、削除)

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

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

これらのタイプのイベントのトレースおよび処理方法を制御する構成が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の宛先

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

- 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 リクエスト・トラッカの宛先

説明

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

実装クラス

oracle.dms.event.RequestTrackerDestination

プロパティ

excludeHeaderNames

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

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

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

- Uniform Resource Identifier (URI)

- リクエストの開始時間

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

- 問合せ文字列

- ヘッダー

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

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

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

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

> executeDump(name=".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:_REQUEST:STOP:/MyWebApp/emp

すべて

2

イベント時間

イベントが発生した時間

例:

v1:1280737384058:_REQUEST:STOP:/MyWebApp/emp

すべて

3

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

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

- NOUN

- EVENT_SENSOR

- STATE_SENSOR

- PHASE_SENSOR

- EXECUTION_CONTEXT

- _REQUEST

例:

v1:1280737384058:_REQUEST:STOP:/MyWebApp/emp

すべて

4

アクション・タイプ

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

- CREATE

- UPDATE

- DELETE

- START

- STOP

- ABORT

例:

v1:1280737384058:_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

リクエスト

5

URI

Uniform Resource Identifier (URI)は、リクエストを適用するリソースを識別します。

例:

v1:1280737382889:_REQUEST:START:/myWebApp/showEmployees

v1:1280737384058:_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 ソース・オブジェクト・タイプで実行されるアクション

作成

更新

削除

開始

停止

中断

ナウン

はい

-

はい

-

-

-

イベント・センサー

はい

はい

はい

-

-

-

フェーズ・センサー

はい

-

はい

はい

はい

はい

状態センサー

はい

はい

はい

-

-

-

実行コンテキスト

-

-

-

はい

はい

-

リクエスト

-

-

-

はい

はい

-

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

DMSメトリックを使用すると、アプリケーションのパフォーマンスに影響を与える可能性があります。メトリックを追加する場合、次の内容を検討してください。

- 高分解能クロックを使用したDMSの精度の向上
デフォルトでは、DMSはPhaseEvent中に時間間隔を測定する際、システム・クロックを使用します。デフォルト・クロックのレポート精度は、ApacheなどのCプロセスではマイクロ秒、Javaプロセスではミリ秒です。パフォーマンス測定の精度向上のために、DMSはオプションで高分解能クロックをサポートしており、時間間隔をレポートする際の値をユーザーが選択できます。デフォルト・クロックを使用する場合よりも正確にフェーズ・イベントの時間を測定する必要があるとき、またはシステムのデフォルト・クロックが分解能の要件に満たないときは、高分解能クロックを使用してください。

システム・クロックは、必ずしも精度が示すほど正確である必要はありません。たとえば、ミリ秒で時間を報告するシステム・クロックは、ミリ秒単位で動作(変化)しない場合があります。かわりに、次の例のように最大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のチューニング」

注意:
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 ServerはApache 2.2.xインフラストラクチャをベースとし、オラクル社が開発したモジュールを含んでいます。シングル・サインオン、クラスタ化されたデプロイおよび高可用性の機能がOracle Serverの動作を強化しています。

詳細は、『Oracle HTTP Serverの管理』のOracle 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を使用してサーバーのパフォーマンス・メトリックを確認する方法の詳細は、『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 Serverディレクティブのチューニング

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

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

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

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

Oracle Serverの構成の詳細は、『Oracle HTTP Serverの管理』のOracle 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 (Prefork MPMなど)を使用する場合は、ORACLE_HOME/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)です。システム・リソースが飽和状態でなく、/スレッドの同時接続ユーザー数が150を超えている場合は、MaxClientsを大きくしてサーバーの同時実行性を高めると、パフォーマンスが向上します。システムの利用状況がフル(目安は85%)になるまで、MaxClientsを大きくします。

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

サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドル状態の接続の両方を処理するために十分な数の同時d/スレッド・サーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxClientsを指定するとき、アイドル状態の永続的なd接続もd/スレッド・プロセスを消費することを考慮に入れる必要があります。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。永続的(KeepAlive)な接続は、接続リクエストの処理中でなくても、接続期間中はd子プロセス(スレッド)を消費します。

十分なキャパシティがある場合は、KeepAliveを有効にしてください。永続的な接続を使用することで、パフォーマンスが向上し、接続の再確立による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はシングル・プロセスのマルチスレッド・モデルを採用しています。

作成可能なサーバー(子)・プロセスの数の上限を指定します。この値は、その値がServerLimitの値より大きい場合、StartServersの値をオーバーライドします。これは、作成可能なサーバー・プロセスの最大数を制御する目的で使用されます。

デフォルト値: 16

ThreadLimit

サーバー(子)・プロセスの下に作成可能なスレッドの数の上限を指定します。この値は、その値がThreadLimitの値より大きい場合、ThreadsPerChildの値をオーバーライドします。これは、プロセスごとに作成されるスレッドの最大数を制御し、競合や問題の発生を防ぐ目的で使用されます。

デフォルト値:

- Windowsマルチプロセス・モジュール(mpm_winnt): 1920

- その他すべて: 64

ThreadsPerChild

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1子サーバー・プロセス当たりのスレッド数」フィールドにマップされます。

起動時に各サーバー(子)・プロセスで作成されるスレッドの数を設定します。

デフォルト値: mpm_winntを使用する場合は150、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 永続的な接続によるプロセスの可用性の低下

ブラウザが永続的な接続をサポートしている場合、Oracle 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はパフォーマンスにほとんど影響を与えません。パフォーマンスが問題になっていることに気づいた場合、他のプロキシまたはロード・バランサが使用されていて、同じ情報が得られるのであれば、そのファイルを無効にしてもかまいません。

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 チューニングに関する高度な考慮事項

この項では、使用環境に適用できる可能性がある、チューニングに関する高度な推奨事項について説明します。次の推奨事項を確認し、それらの変更によってご使用のサーバーのパフォーマンスが改善されるかどうかを判断してください。

- 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は、技術的にはアプリケーションに依存しないプロトコルですが、セキュリティを提供するための標準となり、すべての主要な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のセッション状態をディスクに保存した場合、保存されたセッション状態を再利用するには、通常ディスクから関連するセッション状態を検出し、取得する必要があります。永続的な接続を使用すれば、このパフォーマンス・コストを削減できます。永続的な接続がクライアント側でサポートされている場合、Oracle HTTP Serverはこの接続をデフォルトで使用します。Oracle HTTP Serverによって実装されるSSLを使用した接続では、SSLのセッション状態は、関連する接続が維持されている間メモリーに保存されます。このプロセスにより、SSLセッションの再利用に伴うパフォーマンスへの影響が実質的に排除されます(概念的には、SSL接続は接続とともに維持されます)。詳細は、第6.3.2項「永続的な接続によるプロセスの可用性の低下」を参照してください。

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

SSLを使用するほとんどのアプリケーションでは、データ暗号化のコストは、SSLセッション管理のコストと比べればわずかです。著しい暗号化コストが発生するのは、暗号化されたデータのボリュームが大きい場合です。そのような場合、SSLセッションに対して選択したデータ暗号化アルゴリズムおよび鍵のサイズはきわめて大きくなります。通常、セキュリティ・レベルとパフォーマンスの間にはトレードオフが発生します。

Oracle 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を使用し、画像の転送には通常のプロトコルを使用します。アプリケーションでサーバー認証のみが必要とされている場合、クライアント認証は使用しません。アプリケーションのパフォーマンス目標がこの方法のみでは実現できなければ、追加のハードウェアが必要になる場合もあります。

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のチューニング

この章では、Oracle Metadata Services (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 Services構成パラメータのほとんどは固定であり、特に指定のないかぎり実行時には変更できません。

Oracle B2Bおよびその他のOracle製品をチューニングする前にMDS表領域およびキャッシュ・サイズをチューニングすることは非常に重要です。Oracle B2Bのユーザーズ・ガイドを使用してB2Bをチューニングする場合、最初にこの章のチューニングを完了していることを確認してください。

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上の)アプリケーションのすべてのユーザーがアクセスできる共有キャッシュです。メタデータ・オブジェクトが同じカスタマイズ内容で繰り返し要求される場合、そのオブジェクトはキャッシュからすばやく取得されます(「ウォーム」読取り)。メタデータ・オブジェクトがキャッシュ内に見つからない場合(「コールド」読取り)、そのオブジェクトは、それ以降の読取り操作が容易になるように、キャッシュ構成、メタデータ・オブジェクトのタイプおよびアクセス頻度に応じてMDSによりキャッシュに入れられます。

キャッシュは、デプロイ後に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人のユーザーのみに適用されます。ユーザーによるカスタマイズは一般に、ユーザーがログアウトするまで、そのユーザーのセッション(Session)にキャッシュされます。

カスタマイズの概念とカスタマイズ・クラスの記述および構成の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のMDSによるアプリケーションのカスタマイズに関する項を参照してください。

8 Oracle Fusion Middlewareのセキュリティ・パフォーマンスのチューニング

Oracle Fusion Middlewareセキュリティ・サービスを使用すると、重要なアプリケーションや機密データを保護できます。この章では、セキュリティ・サービスを構成して最適なパフォーマンスを得る方法について説明します。

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

- 第8.1項「セキュリティ・サービスについて」

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

- 第8.3項「Oracle Platform Security Servicesのチューニング」

- 第8.4項「Oracle Webサービス・セキュリティのチューニング」

8.1 セキュリティ・サービスについて

Oracle Fusion Middlewareは、Oracle Platform Security Services (OPSS)およびOracle Web Servicesを通じてセキュリティ・サービスを提供します。

- Oracle Platform Security Services
Oracle Platform Servicesは、Oracle Fusion Middlewareの主要コンポーネントです。セキュリティ・サービスの統合スイートであり、Javaセキュリティ・モデルを使用するJava SEアプリケーションやJava EEアプリケーションと簡単に統合できます。セキュリティ・サービスには、開発者がアプリケーション環境に組み込むことのできるユーザー認証、認可および委任のサービスを実装する機能が含まれています。こうしたサービスの開発にリソースをつぎ込むかわりに、アプリケーション開発者はアプリケーションの表現やビジネス・ロジックに集中することができます。

Oracle Platform Security for Javaを使用すると、アプリケーションのリソース・ユーザーに対してきめ細かなアクセス制御を実施できます。そのための主なステップは次の3つです。

- 適宜ログイン・モジュールを構成して呼び出します。付属のログイン・モジュールを使用することも、カスタム・ログイン・モジュールを使用することもできます。

- ログインしようとするユーザーを認証します。これはアイデンティティ・ストア・サービスの役割です。

- ユーザーが属するロールの権限を、そのユーザーが実行しようとしている操作に対してチェックすることで、ユーザーを認可します。これはポリシー・ストア・サービスの役割です。

- Oracle Web Services Security
Oracle Web Services Securityは、XMLベースのメッセージを使用してWebサービスとやり取りするための認可および認証のフレームワークを提供します。

注意:
この章の内容は、読者がOracle Fusion Middlewareセキュリティ・サービスの概念および管理についての情報に目を通し、理解しているものと想定して書かれています。セキュリティ・パラメータをチューニングする前に、Webサービスの管理を参照してください。

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

この項では、パフォーマンス・ボトルネックの特定方法、およびパフォーマンス・ボトルネックなどの問題の解決方法に関して、一般的なガイドラインを示します。

パフォーマンス・ボトルネックを発見するには、まずWebサービスのデプロイメント全体で予想されるトラフィック負荷に対応できていることを確認します。CPU使用率が100%に達しているシステムがクリティカル・パスにある場合は、1台以上のコンピュータをクラスタに追加する必要があります。

デプロイメントにボトルネックが存在する場合、その発生箇所はおそらく次のいずれかです。

- エージェントとの低速な接続を介したトラフィック

- JMSのようなサード・パーティのキューイング・システムへの接続待機時間

どちらの問題についても、次の原因を確認します。

- 外部リソース(特に次のタイプ)への接続を含むポリシー・アサーションの問題

- データベース・リポジトリ

- LDAPリポジトリ

- セキュア・リソース

- 独自のセキュリティ・システム

- データベース・パフォーマンスの問題

これらのいずれかがボトルネックの原因であると判明した場合は、データベースまたはLDAP接続の管理方法、あるいはリソースの保護方法を変更する必要があります。

8.3 Oracle Platform Security Servicesのチューニング

この項では、Oracle Platform Security Services (OPSS)における次の基本的なチューニング構成について説明します。

- JVMチューニング・パラメータ

- 認証チューニング・パラメータ

- 認可チューニング・プロパティ

- OPSS PDPサービス・チューニング・パラメータ

8.3.1 JVMチューニング・パラメータ

JVMパラメータをチューニングすると、パフォーマンスが大幅に向上します。たとえば、JVMヒープ・サイズはストア内のロールおよび権限の数に応じてチューニングする必要があります。実行時には、ロールおよび権限はすべてインメモリー・キャッシュに格納されます。JVMチューニングの詳細は、第2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。

8.3.2 JDKチューニング・パラメータ

Java Development Kit 7 (JDK 7)から、現在のデフォルトのキーストア・サイズは2048ビットです。JDK 6以前ではデフォルト・サイズが1024ビットでした。

Javaキーツールを使用してキーストアを生成する際には、-keysizeパラメータをキーストア・サイズの制御に使用できます。キーストアが大きいほど、セキュリティのパフォーマンスの低下という犠牲を払うことになりますが、セキュリティはより強固になります。使用環境のユースケース・シナリオを検討して、キーストアの増加がセキュリティまたはパフォーマンスのしきい値に悪影響を与えないか判断してください。

詳細は、JDK 7のリリース・ノート(http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html)を参照してください。

8.3.3 認証チューニング・パラメータ

OPSS認証チューニングの詳細は、Oracle Technology Networkに掲載されているOracle Fusion Middleware Oracle WebLogic Serverの保護ガイドの、WebLogicおよびLDAP認証プロバイダのパフォーマンスの向上に関する項(http://download.oracle.com/docs/cd/E12840_01/wls/docs103/secmanage/atn.html#wp1199087)を参照してください。

8.3.4 認可チューニング・プロパティ

次のJavaシステム・プロパティを使用して、認可を最適化できます。

表8-1 認可プロパティ

Javaシステム・プロパティ

デフォルト値

有効な値

注意

-Djps.subject.cache.key

4

3

4

5

JPSは、サブジェクト・リゾルバを使用して、プラットフォーム・サブジェクトをユーザー/エンタープライズ・ロール情報およびApplicationRole情報を含むJpsSubjectに変換します。この情報は、サブジェクトではプリンシパルとして表されます。

特にサブジェクトのプリンシパル・セットが大規模な場合、この変換はCPUへの負荷が高いです。パフォーマンスを向上するために、JPSコードはプラットフォーム・サブジェクトとJpsSubject間の変換をキャッシュします。2つのサブジェクトは、コンテンツが同じなのにプリンシパルの名前の大/小文字が異なる場合に、混同される可能性があることに注意してください。

次の設定を使用して、キャッシュ・キーを構成できます。

- 3: プラットフォーム・サブジェクトをキーとして直接使用します。注意: WLSでprincipalEqualCaseinsensitiveフラグが有効になっている場合、2つのサブジェクトは、コンテンツが同じなのにプリンシパルの大/小文字が異なる場合に、混同される可能性があります。

- 4: この設定は「3」に似ていますが、大/小文字の区別の問題を解決しています。これは初期状態の設定です。

- 5: サブジェクト全体をキーとして使用するかわりに、この設定は、サブジェクト内のプリンシパル・セットの一部をキーとして使用します(実際にはWLSUSerImplタイプのプリンシパルを使用します)。
この設定により、サブジェクトに多数のプリンシパル・セットがある場合、キャッシュ取得操作が高速になります。WLS以外のプラットフォーム(WASやJBOSSなど)では、これは「4」の場合に戻るため、この設定はWLS専用です。この場合、後述のキャッシュが有効な期間を制御する存続時間(TTL)設定フラグもあります。

-Djps.subject.cache.ttl

60000ms

「5」の場合(前述)のキャッシュの存続時間(TTL)。このシステム・プロパティは、キャッシュが有効な期間を制御します。有効期限が切れると、キャッシュされた値はダンプされます。設定は、フラグ-Djps.subject.cache.ttl=xxxxによって制御できます。xxxは、ミリ秒単位の期間です。

このTTL設定の期間を、WLS LDAPオーセンティケータでグループおよびユーザー・キャッシュTTLに使用される値と同じ値に設定することを検討してください。

-Djps.combiner.optimize=true

True

True

False

このシステム・プロパティを使用して、特定のサブジェクトの保護ドメインをキャッシュします。-Djps.combiner.optimize=trueを設定すると、Java認可パフォーマンスを改善できます。

-Djps.combiner.optimize.lazyeval=true

True

True

False

このシステム・プロパティを使用して、checkPermissionが発生する場合のサブジェクトの保護ドメインを評価します。-Djps.combiner.optimize.lazyeval=trueを設定すると、Java認可パフォーマンスを改善できます。

-Djps.policystore.hybrid.mode=true

True

True

False

このハイブリッド・モード・プロパティを使用して、SUN java.security.PolicyからOPSS Javaポリシー・プロバイダへの遷移を促進します。

OPSS Javaポリシー・プロバイダは、java.policyとsystem-jazn-data.xmlの両方を読み取ります。ハイブリッド・モードを無効にするには、WebLogic Serverの起動時にシステム・プロパティjps.policystore.hybrid.modeをfalseに設定します。-Djps.policystore.hybrid.mode=falseを設定すると、実行時のオーバーヘッドを削減できます。

-Djps.authz=ACC

ACC

ACC

SM

コールをJDK APIのAccessController.checkPermissionに委任します。こうすると、実行時またはデバッグ中のパフォーマンスへの影響を軽減できます。

ACC: AccessController.checkPermissionに委任します。

SM: SecurityManagerが設定されている場合、SecurityManagerに委任します。

8.3.5 OPSS PDPサービス・チューニング・パラメータ

表8-2に、ポリシー・ストアのOPSSチューニング・パラメータを示します。

表8-2 OPSS PDPサービス・チューニング・パラメータ

パラメータ

デフォルト値

有効な値

注意

oracle.security.jps.policystore.rolemember.cache.type

STATIC

STATIC、SOFT、WEAK

このパラメータには、ロール・メンバーのキャッシュ・タイプを指定します。Java EEアプリケーションでのみ有効です。

有効な値:

- STATIC: キャッシュ・オブジェクトは静的にキャッシュされ、FIFOなど、適用されたキャッシュ戦略に応じてのみ明示的にクリーンアップされます。ガベージ・コレクタでは、このタイプのキャッシュはクリーンアップされません。

- SOFT: メモリーが不足している場合、このタイプのキャッシュのクリーンアップはガベージ・コレクタに依存します。

- WEAK: このタイプのキャッシュの動作は、タイプSOFTのキャッシュとよく似ていますが、ガベージ・コレクタによってより頻繁にクリーンアップされます。

最適なパフォーマンスを確保するために、デフォルト値のままにすることを検討してください。

oracle.security.jps.policystore.rolemember.cache.strategy

FIFO

FIFO

NONE

ロール・メンバーのキャッシュで使用する戦略のタイプ。Java EEアプリケーションでのみ有効です。

有効な値:

- FIFO: キャッシュでは、先入れ先出し戦略が実装されます。

- NONE: リフレッシュまたは再起動が実行されるまで、キャッシュにあるすべてのエントリは増大し続けます。キャッシュのサイズを制御することはできません。使用はお薦めできませんが、ポリシーのフットプリントがきわめて小さい場合には効率的です。

最適なパフォーマンスを確保するために、デフォルト値のままにすることを検討してください。

oracle.security.jps.policystore.rolemember.cache.size

1000

ロール・メンバーのキャッシュのサイズ。参照するロールは、エンタープライズ・ロール(グループ)です。最初にIDストアのグループ数を確認できます。次に、パフォーマンス要件に基づいて、この数値をフル・キャッシュ・シナリオのグループ数に設定できます。または、部分グループ・キャッシュ・シナリオの特定の比率のグループ数に変更できます。

oracle.security.jps.policystore.policy.lazy.load.enable

True

True

False

ポリシーの遅延ロードを有効または無効にします。このパラメータをfalseに設定すると、特に大きいポリシー・ストアでサーバーの初回の起動に時間がかかります。推奨値はtrueです。

oracle.security.jps.policystore.policy.cache.strategy

PERMISSION_FIFO

PERMISSION_FIFO

NONE

パーミッションのキャッシュで使用する戦略のタイプ。Java EEアプリケーションでのみ有効です。

有効な値:

- PERMISSION_FIFO: キャッシュでは、先入れ先出し戦略が実装されます。

- NONE: リフレッシュまたは再起動が実行されるまで、キャッシュにあるすべてのエントリは増大し続けます。キャッシュのサイズを制御することはできません。使用はお薦めできませんが、ポリシーのフットプリントがきわめて小さい場合には効率的です。

最適なパフォーマンスを確保するために、デフォルト値を使用することを検討してください。

oracle.security.jps.policystore.policy.cache.size

1000

パーミッションのキャッシュのサイズ。すべてのポリシーをキャッシュする場合、この値を付与の合計数に設定できます。

oracle.security.jps.policystore.cache.updatable

True

True

False

このプロパティは、リフレッシュを有効にする目的で使用します。最適なパフォーマンスを確保するために、デフォルト値のままにすることを検討してください。

oracle.security.jps.policystore.refresh.enable

True

True

False

このプロパティは、リフレッシュを有効にする目的で使用します。パフォーマンスを確保するために、デフォルト値のままにすることを検討してください。

oracle.security.jps.policystore.refresh.purge.timeout

43200000

ポリシー・ストアがリフレッシュされるまでの時間(ミリ秒)。最適なパフォーマンスを確保するために、デフォルト値のままにすることを検討してください。

oracle.security.jps.ldap.policystore.refresh.interval

600000 (10分)

ポリシー・ストアで変更がポーリングされる間隔(ミリ秒)。最適なパフォーマンスを確保するために、デフォルト値のままにすることを検討してください。このプロパティは、Java EEおよびJ2SEアプリケーションで有効です。

oracle.security.jps.policystore.rolemember.cache.warmup.enable

False

True

False

このプロパティによって、ApplicationRoleメンバーシップ・キャッシュの作成方法が制御されます。Trueに設定すると、キャッシュはサーバーの起動時に作成されます。それ以外の場合は、必要に応じて作成されます(遅延ロード)。

ユーザーおよびグループの数がアプリケーション・ロールの数を大きく上回っている場合はTrueに設定します。それ以外の場合、つまりアプリケーション・ロールの数が非常に多い場合はFalseに設定します。

8.4 Oracle Webサービス・セキュリティのチューニング

Oracle Web Services Securityは、XMLベースのメッセージを使用してWebサービスとやり取りするための認可および認証のフレームワークを提供します。この項では、Webサービスのパフォーマンスに影響を与える要因について説明します。

- 適切なポリシーの選択

- ポリシー・マネージャ

- SOAPメッセージを記録するためのログ・アサーションの構成

- Webサービスのパフォーマンスのモニタリング

8.4.1 適切なポリシーの選択

Oracle Web Services Securityでは多くのポリシーがサポートされていますので、デプロイメントのセキュリティ・ニーズに基づいて適切なポリシーを実装する必要があります。追加するセキュリティ・ポリシーはそれぞれパフォーマンスに影響を与える可能性があるため、パフォーマンスを十分に考慮してください。たとえば、トランスポート・レベルのセキュリティ(SSL)は、アプリケーション・レベルのセキュリティより高速ですが、マルチステップのトランザクションでは脆弱性を生む可能性があります。アプリケーション・レベルのセキュリティの方がパフォーマンスへの影響は大きいものの、エンドツーエンドのセキュリティを実現できます。

デプロイメントに必要なセキュリティ・ポリシーを決定するには、Oracle Web Services ManagerによるWebサービスの保護およびポリシーの管理の使用する事前定義済ポリシーの決定に関する項を参照してください。

8.4.2 ポリシー・マネージャ

データベースベースのポリシー強制を使用する際には、パフォーマンスへの影響がつきものです。データベース・ポリシーの強制を選択した場合、エージェントからデータベースへのポーリングの頻度を慎重に検討する必要があります。

8.4.3 SOAPメッセージを記録するためのログ・アサーションの構成

デフォルト・ポリシーのリクエスト・パイプラインおよびレスポンス・パイプラインには、ポリシー強制ポイント(PEP)でSOAPメッセージをデータベースまたはコンポーネント別ローカル・ファイルに記録するログ・アサーションが含まれています。ロギング・レベルはパフォーマンスに影響を与えることがあります。パフォーマンスの問題を回避するには、デプロイメントに適した最低のロギング・レベルを使用することを検討してください。

ログ・ステップ内に構成できるロギング・レベルには次のものがあります。

- ヘッダー: SOAPヘッダーのみが記録されます。

- 本文: メッセージの内容(本文)のみが記録されます。

- エンベロープ: SOAPエンベロープ全体(ヘッダーと本文の両方を含む)が記録されます。添付ファイルは記録されません。

- すべて: メッセージ全体が記録されます。これには、SOAPヘッダー、本文、およびすべての添付ファイル(SOAPメッセージそのものの外部に存在するURLなど)が含まれます。

注意: 一般に、ログ・ファイルをトポロジ的に強制コンポーネントに近い場所に配置すると、システムのパフォーマンスが向上します。可能であれば、著しい分散環境では複数の分散ログを使用してください。

8.4.4 接続プーリングの構成

com.sun.jndi.ldap.connect.pool環境プロパティを使用して、コンテキスト・インスタンスが接続プーリングを使用するように要求した場合、使用される接続はプールされることもありますが、プールされないこともあります。デフォルト・ルールでは、単純な認証を使用する、または認証を使用しないプレーン(非SSL)接続のプールを許可します。このデフォルトは、システム・プロパティを使用して、SSL接続およびDIGEST-MD5認証タイプを含むように変更できます。プレーン接続とSSL接続の両方のプールを許可するには、次に示すように、com.sun.jndi.ldap.connect.pool.protocolシステム・プロパティに文字列plain sslを設定します。

"-Dcom.sun.jndi.ldap.connect.pool.protocol="plain ssl"

8.4.5 Webサービスのパフォーマンスのモニタリング

Oracle Fusion Middleware Controlの「Webサービス」ホームページで、次のOracle Web Servicesのパフォーマンスをモニターできます。

- 次のエンドポイント有効メトリック

- ポリシー参照ステータス

- 合計違反

- セキュリティ違反

- 完了した呼出し

- レスポンス時間(秒)

- 次のポリシー違反

- 合計違反

- 認証違反

- 認可違反

- 機密保持違反

- 整合性違反

- 障害の合計

Oracle Fusion Middlewareコンポーネントのモニタリングの概要は、第4章「Oracle Fusion Middlewareのモニタリング」を参照してください。

Oracle Fusion Middleware Controlを使用したOracle Webサービスのモニターの詳細は、Webサービスの管理のパフォーマンスのモニタリング、監査およびチューニングの概要に関する項を参照してください。

第III部

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

この部では、パフォーマンスの向上を目的とするOracle Fusion Middlewareサーバー・コンポーネントの構成について説明します。次の章で構成されています。

- 第9章「Oracle Application Development Framework (ADF)のチューニング」

- 第10章「Oracle TopLinkのチューニング」

9 Oracle Application Development Framework (ADF)のチューニング

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

- 第9.1項「Oracle ADFについて」

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

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

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

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- ADF FacesによるWebユーザー・インタフェースの開発

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

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

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

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

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

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

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

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

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

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

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

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

表9-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/)を参照してください。

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

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

表9-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リクエストの直後にコールされた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>

デフォルトでJDeveloperでは、使用ページの上部にaf:documentコンポーネントが配置されます。ただし、場合によっては、ページ・フラグメントまたはテンプレートにこのコンポーネントを配置することができます。テンプレートを使用してaf:documentを実装する場合、テンプレート定義の外で重複する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スタイルシート、イメージなど)がキャッシュ可能であることをレスポンス・ヘッダーから判断できません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソースの確認:

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

2. コードを確認します。コメントや長い変数名がある場合、ライブラリは曖昧化されていません。
注意: 著作権を示すコメントは、曖昧化されたJSファイルでも保持されます。

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

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

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

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

表9-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ユーザー・インタフェースの開発』のclientComponentをtrueに設定した場合の処理に関する項を参照してください。

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

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

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

- f:attribute

- af:setPropertyListener

- af:clientListener

- af:serverListener

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

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

table、treeおよびtreeTableは、最も複雑で使用頻度の高いコンポーネントです。これらのコンポーネントは大きなデータ・セットを格納できるため、よくパフォーマンスの問題の原因となります。表9-4に、パフォーマンスに関する推奨事項を示します。

表9-4 tableコンポーネントおよびtreeコンポーネントの構成

構成に関する推奨事項

説明

editingMode="clickToEdit"を使用します。

editingMode="editAll"を使用すると、編集可能な値ホルダーの全コンテンツとその子コンポーネントが送信されます。これにより、クライアントのペイロードおよび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ユーザー・インタフェースの開発』の表およびツリーの使用に関する項を参照してください。

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

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

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

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

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

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

遅延配信(デフォルト)

遅延配信は、表やフェッチ時間の遅いスタンプ設定された他のコンポーネントに使用する必要があります。たとえば、スタンプ設定されたコンポーネントがWebサービス呼出しを使用したデータ・コントロールや遅いデータ・フェッチの他のデータ・コントロールに基づく場合です。ユーザーが下にスクロールしないとすぐに内容が表示されないページにも遅延配信を使用できます。この場合、クライアントに表示されるコンテキストの配信時間が短くなり、ユーザーがパフォーマンスの向上を認識します。
遅延配信は、データ・ストリーミング技術を使用して実現されます。この方式が優れているのは、サーバーがデータ・フェッチを並行して実行し、データが使用可能になると同時に、そのデータをクライアントへストリーミング配信することが可能な点です。この方式は、ページに表が2つあり、一方の表ではデータがごく短時間で返され、もう一方の表ではデータが返されるまで長時間かかるといった場合に、高い効果を発揮します。高速な表のデータは、取得されると同時にユーザーに対して表示されます。

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

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

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

即時配信

即時配信(contentDelivery="immediate")を使用するのは、表データ・コントロールが高速な場合、または小さいデータ・セットを返す場合です。このような場合には、遅延配信を使用するよりレスポンス時間が短くなります。
即時配信のもう1つの利点は、遅延配信に比べてサーバー・リソースの使用率が低いことです。即時配信では、サーバーに送信されるリクエストは1つのみなので、特定のユーザー・インタラクションにおけるCPUおよびメモリーの使用率が低下します。

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

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

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

構成に関する推奨事項

説明

RangeSize属性を使用します。

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

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

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

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

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

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

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

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

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

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

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

注意:
ADFmを使用するときには、パフォーマンスを維持するために遅延実行の使用を検討し、リフレッシュ状態をモニターしてください。

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

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

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

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

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

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

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

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

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

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

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

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

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

9.3.1.3 バッチ処理

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

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

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

9.3.1.4 RangeSizeチューニング

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

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

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

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

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

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

-Djbo.load.components.lazily=true

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

アプリケーション・モジュール(AM)・プーリングを使用すると、複数のユーザーが複数のアプリケーション・モジュール・インスタンスを共有できます。AMプールの構成は、予想されるアプリケーションの使用状況によって異なります。

ほとんどのAMプール・パラメータは、Oracle JDeveloperを介して設定できます。構成内容はbc4j.xcfgに保存されますが、必要に応じて手動で編集できます。パラメータをJVMパラメータ(-Dプロパティ=値)として指定し、システム・レベルで設定することもできます。bc4j.xcfgの構成は、JVMの構成より優先されます。そのため、システムレベルの汎用構成をアプリケーション固有の例外でオーバーライドすることも可能です。

表9-7 アプリケーション・モジュール(AM)・プールのチューニング

構成に関する推奨事項

説明

アプリケーションのAMプール数を最適化します。

システムレベルで適用されるパラメータは、AMプール単位で適用されます。アプリケーションで複数のAMプールを使用する場合は、AMインスタンス数を表すシステムレベルの値にAMプール数を掛けて、システムで指定されている実際の制限の合計を把握する必要があります。

たとえば、アプリケーションが4つの独立したAMプールを使用してアプリケーションにサービスを提供しており、システムレベルの構成によってAMプールの最大サイズが100に制限されている場合、AMインスタンスの最大数は400になります(4つのプール * 最大プール・サイズ100)。

目的とするのがアプリケーション全体で最大プール・サイズを100に制限することであれば、システムレベルの構成では最大プール・サイズとして25を指定する必要があります(最大プール・サイズ100 / 4つのプール)。JDevを介して、または直接bc4j.xcfgで各プールを別々に構成すれば、各AMプールの構成をさらにきめ細かく行うことができます。

データベース接続数を最適化します。

デフォルトでは、AMインスタンスはAMプールに戻された後もデータベース接続を保持します。この関連付けを維持することには、パフォーマンス上、多くの利点があります。パフォーマンスを確保するには、指定したデータベース接続の最大数より多くのAMインスタンスを構成することを検討してください。

注意: AMプールの1つをルート・プールとして使用する必要がある場合は、そのAMプール・レベルでのチューニングを検討してください。使用頻度の低いプールについては、トップレベルのアプリケーション・パラメータが使用されないように、プール・サイズをプール・レベルでチューニングすることを検討してください。

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

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

表9-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に設定すると、この動作は行われず、前述の状況で受動化のコストが発生することはありません。

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

表9-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の負荷をある程度軽減できるパラメータについては、表9-10を参照してください。

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

パラメータ

説明

jbo.ampool.initpoolsize

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

jbo.recyclethreshold

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

9.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%多い値に設定します。

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

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

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

表9-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処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。

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

パラメータ

説明

jbo.ampool.minavailablesizeおよびjbo.ampool.maxavailablesize

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

jbo.ampool.timetolive

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

jbo.ampool.maxinactiveage

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

jbo.ampool.monitorsleepinterval

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

9.3.1.7 ADFc: リージョンの使用

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

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

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

注意:
領域とタスク・フローの場合、現在のviewIdを評価するためにかかる時間とフローへの入力パラメータを計算するためにかかる時間が、全体のパフォーマンスに影響することがあります。設計フェーズではこれを検討してください。

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

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

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

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

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

- f:attribute

- af:setPropertyListener

- af:clientListener

- af:serverListener

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

- 条件付きアクティブ化を使用します。
jsff内のポップアップでプロパティ・リスナーを追加して条件を設定します。

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

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

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

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

9.3.1.11 静的データの再利用

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

9.3.1.12 条件付き検証

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

10 Oracle TopLinkのチューニング

この章では、EclipseLinkに対して使用可能なパフォーマンス・チューニング機能について説明します。EclipseLinkは、Oracle TopLinkとともに使用するオープンソースの永続性フレームワークです。この章の内容は次のとおりです。

- 第10.1項「Oracle TopLinkおよびEclipseLinkについて」

- 第10.2項「チューニングに関する基本的な考慮事項」

- 第10.3項「チューニングに関する高度な考慮事項」

10.1 Oracle TopLinkおよびEclipseLinkについて

Oracle TopLinkには、オープンソースのEclipseLinkがJava Persistence API (JPA)実装として含まれています。Oracle TopLinkは、Oracle Application Serverへの高度な統合によってEclipseLinkを拡張します。

この章の内容は、読者がEclipseLinkの基本的な機能を熟知しているものと想定して書かれています。チューニングを始める前に、次の概論に目を通すことを検討してください。

- 「Understanding Queries」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/queries.htm#CHDGGCJB)

- 「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/general004.htm#CHDEEBFG)

- 「Understanding Mappings」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/mappingintro.htm#CHDFEJIJ)

Oracle TopLinkの詳細は、Oracle Technology Network (OTN)のTopLinkのページを参照してください。

注意:
この章は、Java EE環境に則したJPAのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。この章では、パフォーマンス・チューニングに関する一般的な考慮事項と関連のドキュメント・リソースを示しますが、チューニングが必要な分野をすべて網羅してはいません。

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

チューニングに関する次の推奨事項は、ほとんどのデプロイメントに適用できます。これらのうち、いずれの構成を実装する場合でも、その前に各自のユースケース・シナリオを検討してください。

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

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

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

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

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

この項では、効率的なSQL文およびSQL問合せの使用について説明します。表10-1と表10-2に、SQL文およびSQL問合せに関連したチューニング・パラメータとパフォーマンス上の推奨事項を示します。

表10-1 EJB/JPAでの効率的なSQL文およびSQL問合せの使用

チューニング・パラメータ

説明

パフォーマンス上の注意点

パラメータ使用のSQLのバインディング

パラメータ使用のSQLおよびプリコンパイル文のキャッシュを使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。EclipseLinkでは、パラメータ使用のSQLがデフォルトで有効になります。ただし、データベースやJDBCドライバの中には、このオプションをサポートしないものもあります。Oracle Application ServerにバンドルされているOracle JDBCドライバは、このオプションをサポートしていませんので注意してください。これを構成するには、persistence.xmlの永続性プロパティeclipselink.jdbc.bind-parametersを使用します。

関連項目: 「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache.htm#CDEFHHEH)および「Understanding Querying」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/queries.htm#CHDGGCJB)

デフォルト値: 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順序付けを使用してください。

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

表10-2に、パフォーマンス・チューニング用のエンティティ・リレーションシップ問合せパラメータを示します。

表10-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 Fetching」(http://www.eclipse.org/eclipselink/documentation/2.5/solutions/performance001.htm#CHDEGCHH)

デフォルト値: 使用しない

必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。SELECTのパフォーマンスを最適化するために、バッチ・フェッチがサポートされていない場合は結合を使用することをお薦めします。

遅延ロード

遅延ロードをOnにしていない場合、EclipseLinkは、永続オブジェクトを取得する際に、それが参照する従属オブジェクトをすべて取得します。リレーションシップ・マッピングによってマップされた属性に対して遅延読取り(インダイレクション、遅延ロード、ジャストインタイム読取りとも呼びます)を構成すると、EclipseLinkは被参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトを使用します。

その属性にアクセスするまで、従属オブジェクトの読取りはEclipseLinkによって遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。

関連項目: 「Using Lazy Loading」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/mappingintro001.htm#CEGBCJAG)

デフォルト値: コレクション・マッピングの場合はOn (ToManyマッピング、@OneToMany、@ManyToMany)

デフォルト値: 参照の場合はOff (ToOneマッピング、@OneToOne、@ManyToOne)

(@OneToOneおよび@ManyToOneに対して遅延ロードをOnに設定するには、ウィービングが必要です。Java EEの場合、ウィービングはデフォルトでOnになっています。)

すべてのマッピングに対して遅延ロードを使用します。遅延ロードを使用し、バッチ・フェッチまたは結合を使用して被参照オブジェクトを問い合せる方が、即時ロードより効率的です。

リレーションシップのインスタンス化を問合せで強制できるようにするLoadGroupsとともに最適化されたロードを使用することも検討できます。

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

この項では、EclipseLinkに付属しているデフォルト内部キャッシュのチューニングについて説明します。Oracle Toplink/EclipseLinkは、Oracle Coherenceとも統合できます。Oracle Coherenceを使用したEclipseLinkエンティティ・キャッシュの構成およびチューニングの詳細は、第10.3.1項「Oracle Coherenceとの統合」を参照してください。

EclipseLink永続性マネージャおよびキャッシュとともに使用するEJB3.0/JPAのデフォルト設定は、ロックなし、キャッシュ・リフレッシュなしで、キャッシュの使用方法はDoNotCheckCacheです。(排他的アクセス権限がない場合に)アプリケーションでキャッシュを使用し、失効したデータをキャッシュから読み取らないようにするには、これらの設定に加えて、その他の分離関連の設定を適切に構成する必要があります。表10-3に、キャッシュ構成オプションを示します。

キャッシュ構成の詳細は、「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache.htm#CDEFHHEH)を参照してください。

注意:
デフォルトでは、アプリケーションが使用データへの排他的アクセス権限を持つ(つまり、EclipseLink以外の外部アプリケーションがデータを変更することはない)ものと想定されます。アプリケーションがデータへの排他的アクセス権限を持たない場合は、表10-3に示すデフォルト値を一部変更する必要があります。

表10-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"

関連項目: 「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache.htm#CDEFHHEH)および「JPA Query Customization Extensions」( http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/queryhints.htm#sthref498)

デフォルト値: 使用しない

主キー以外のキーで頻繁に実行される問合せのうち、結果セットがあまり変わらないものに使用します。キャッシュ無効化タイムアウトとともに使用すると、必要に応じてリフレッシュができます。

キャッシュ・サイズ

キャッシュ・サイズは、次の永続性プロパティを使用して構成します。eclipselink.cache.size.<entity>

"eclipselink.cache.size.default"

"eclipselink.cache.type.default"

関連項目: 「About the Persistence Unit」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/appdeployment002.htm#BABHCJDG)および「Class PersistenceUnitProperties」(http://www.eclipse.org/eclipselink/api/2.3/org/eclipse/persistence/config/PersistenceUnitProperties.html)

デフォルト値: タイプSoftWeak、サイズ100 (1エンティティ当たり)。ToplinkがExalogicで実行していると、デフォルト値は異なる可能性があります。Exalogicデフォルトの詳細は、Oracle TopLinkのソリューション・ガイドのExalogic自動チューニング処理の有効化に関する項を参照してください。

使用可能なメモリーの量、使用するクラスのインスタンス数、エンティティのアクセス頻度、および失効したデータの許容度に基づいたキャッシュの必要量を基準に、キャッシュ・サイズを設定します。

アクセス頻度の高いインスタンスが多いエンティティや、失効したデータが大した問題にはならないエンティティについては、サイズの大きなキャッシュを作成することを検討してください。

更新頻度が高く、常に最新のデータが必要とされるエンティティや、アクセス頻度の低いエンティティには、小さなキャッシュ・サイズを使用するか、キャッシュをまったく使用しないことを検討してください。

ロック

Oracleでは、表10-4に示すロック・ポリシー(ロックなし、オプティミスティック、ペシミスティック、読取り専用)をサポートしています。

ロックは、JPAの@Versionアノテーションeclipselink.read-onlyを使用して設定します。

「Descriptors and Locking」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/descriptors002.htm#CHEEEIEA)を参照してください

デフォルト値: ロックなし

同時に更新可能なエンティティには、ユーザーが他のユーザーの変更を上書きできないようなロック・ポリシーを使用することを検討してください。読取り専用エンティティのパフォーマンスを最適化するには、エンティティを読取り専用として定義するか、読取り専用の問合せヒントを使用することを検討してください。

キャッシュの使用方法

デフォルトでは、どのタイプの問合せも、まずデータベースを検索してからキャッシュと同期を取ります。問合せにリフレッシュが設定されている場合を除き、キャッシュされたオブジェクトはデータベースからリフレッシュされずに返されます。特定の問合せを、インメモリー・キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。

すでにキャッシュにあるオブジェクトがデータベースで検索されるのを防いでパフォーマンスを向上させるには、検索の際に必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみデータ・ソース内を検索するよう構成します。主キーに基づいて単一オブジェクトを検索する問合せについては、問合せヒントeclipselink.cache-usageをCheckCacheByExactPrimaryKeyに設定します。

デフォルト値: DoNotCheckCache

通常はデータがキャッシュにあり、リフレッシュ処理をそれほど必要としない場合に、主キー問合せのパフォーマンスを高速化するには、まず主キー問合せでキャッシュをチェックすることをお薦めします(CheckCacheByExactPrimaryKeyを使用)。

これにより、まずデータベースからオブジェクトを取得した後、すでにキャッシュにあるオブジェクトを検索し、キャッシュされた値(問合せにリフレッシュが設定されている場合を除き、データベース・アクセスによって更新されていない)を返すというデフォルト動作を回避できます。

分離

EclipseLinkを使用するJPAアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。

一般的なEJB3.0 JPAアプリケーションでは、データベース・トランザクションの分離レベルが適用されるタイミング、および特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響を与えます。

- ロック・モード

- セッション・キャッシュの使用

- 外部アプリケーション

- データベース・ログイン・メソッドsetTransactionIsolation

関連項目: 「Isolated Cache」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache001.htm#CDEEGICF)

キャッシュのリフレッシュ

デフォルトでは、EclipseLinkはデータ・ソースから読み取ったオブジェクトをキャッシュします。このオブジェクトに対する後続の問合せではキャッシュへのアクセスが行われるため、データ・ソースへのアクセスが減るとともに、オブジェクトとそのリレーションシップを再構築するコストも発生せず、パフォーマンスが向上します。問合せでデータ・ソースにアクセスする場合でも、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、EclipseLinkはキャッシュされたオブジェクトを使用します。このデフォルトのキャッシュ・ポリシーは、失効したデータがアプリケーション内に生じる原因となります。

リフレッシュは、エンティティ・レベル(alwaysRefreshまたはrefreshOnlyIfNewerとexpiry)および問合せレベル(eclipselink.refresh問合せヒントを使用)で有効にできます。また、disableHitsを使用して、問合せが必ずデータベースに送られるようにすることも可能です。失効したデータや競合するデータがデータベースにコミットされないようにするには、適切なロック・ポリシーを使用するしかありません。

詳細は、第10.2.2.1項「キャッシュ・リフレッシュのシナリオ」を参照してください。

関連項目: 「Understanding Caching」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache.htm#CDEFHHEH)

デフォルト値: キャッシュのリフレッシュなし

エンティティ・レベルでのキャッシュのリフレッシュはできるかぎり避け、かわりに次の構成を検討してください。

- 問合せごとのキャッシュのリフレッシュ

- キャッシュの有効期限

- 分離キャッシュ

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

キャッシュでのデータのリフレッシュに関して、考慮すべきシナリオがいくつかあります。これらのシナリオはいずれも、パフォーマンスに影響を与えます。

- キャッシュされたデータではなく、最新のデータが常に必要な場合は、分離キャッシュ(Shared=False)を使用することを検討してください。これに当てはまるのは、アプリケーション内の特定のデータが頻繁に変更されるため、競合が検出されたときにのみデータをリフレッシュするのではなく、常にデータをリフレッシュすることが望ましいような場合です。

- 失効したデータは使用したくないが、失効したデータを取得することになっても大した問題ではないという場合は、解決策としてキャッシュ失効ポリシーを使用することをお薦めします。この場合は、ロック・エラー発生時に失効したオブジェクトを自動的にリフレッシュする、オプティミスティック・ロックも使用してください。オプティミスティック・ロックを使用する場合は、エンティティの@Cache属性であるalwaysRefreshおよびrefreshOnlyIfNewerをさらに有効にすると、データベースにアクセスする問合せで、返された失効オブジェクトをリフレッシュできるとともに、無効なオブジェクトが変更されていない場合はリフレッシュしないようにできます。また、リフレッシュされたデータが必要であることがわかっている場合に、特定の問合せ操作に対してリフレッシュを有効にしたり、クライアントから取得したデータをリフレッシュするオプション(リフレッシュ問合せをコールするもの)を提供したりすることもできます。

- データが失効していても問題ない場合は、オプティミスティック・ロックを使用してください。そうすると、ロック・エラーの際にキャッシュ内の失効したオブジェクトが自動的にリフレッシュされます。

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

表10-4に示すロック・モードを、EclipseLinkのキャッシュ使用方法および問合せリフレッシュのオプションとともに使用すると、JPAを使用するEJBエンティティのデータ一貫性が保証されます。どの組合せも機能とパフォーマンスの両面に影響を与えますが、これらのオプションの設定は、たとえパフォーマンスのコストが発生したとしても、データを最新で一貫した状態に保つための機能上の要件を優先して決めるのが一般的です。

詳細は、「Descriptors and Locking」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/descriptors002.htm#CHEEEIEA)を参照してください。

表10-4 ロック・モード・ポリシー

ロック・オプション

説明

パフォーマンス上の注意点

ロックなし

ユーザーが別のユーザーの変更内容を上書きできます。これはデフォルトのロック・モードです。エンティティが同時に更新されることがない場合や、read-committedセマンティクスによる同じ行の同時読取りおよび更新で十分な場合は、このモードを使用します。

デフォルト値: ロックなし

通常はロックなしの方が高速ですが、データ一貫性のニーズには対応できない場合があります。

オプティミスティック

すべてのユーザーがデータへの読取りアクセス権限を持ちます。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。

関連項目: 「Using Optimistic Locking」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/mappingintro005.htm#CEGDIIIB)

同じ行に対する同時更新を頻繁には実行しないと予想される場合、オプティミスティック・ロックを使用すれば、最適なパフォーマンスを得ながら、データの一貫性も保証することができます。

ペシミスティック

更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。

同じ行に対して頻繁に同時更新を実行することが予想される場合、同時アクセスの例外および再試行が多数発生するオプティミスティック・ロックより、ペシミスティック・ロックの方が高速になることがあります。

エンティティ・レベルでペシミスティック・ロックを使用する場合は、最適なパフォーマンスを得るために、分離キャッシュ(Shared=False)を併用することをお薦めします。

読取り専用

EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、EclipseLinkが作業ユニットのパフォーマンスを最適化できるようになります。

@ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定します。問合せヒントeclipselink.read-onlyを使用して、問合せレベルで設定することもできます。

エンティティを読取り専用として定義すると、読取り専用として定義されていないが、挿入、更新または削除を行わないエンティティよりも、パフォーマンスが向上します。これは、EclipseLinkによる作業ユニットのパフォーマンスの最適化が可能になるためです。すべての読取り専用操作に対して、常に読取り専用を使用してください。

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

EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びます。マッピングは、EclipseLinkプロジェクトの中核をなしています。

マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。

マッピングの詳細は、「Mapping and Descriptors」(http://www.eclipse.org/eclipselink/documentation/2.5/solutions/performance002.htm#sthref153)を参照してください。

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

EclipseLinkでは、@Partitionedアノテーションを使用してデータのパーティション化を構成できます。パーティション化すると、アプリケーションはクラスタ・データベースなどの複数のデータベース間で情報を増減できます。@Partitionedおよびその他のパーティション・ポリシー・アノテーションの使用方法の詳細は、「Partitioning Annotations」(http://www.eclipse.org/eclipselink/documentation/2.5/jpa/extensions/annotations_ref.htm#CACHIHIB)を参照してください。

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

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

- Oracle Coherenceとの統合

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

10.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キャッシュとともに使用する方法の詳細は、『Oracle Coherenceの統合』のグリッド・キャッシュの構成に関する項を参照してください。

Oracle ToplinkのOracle Coherenceとの統合の詳細は、『Oracle Coherenceの統合』のOracle CoherenceでのToplink Gridの概要に関する項を参照してください。

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

この項では、JPAアプリケーションのパフォーマンス分析に役立つEclipseLinkの機能をいくつか示します。

- パフォーマンス・モニタリング・フォームの詳細は、「Performance Monitoring」(http://www.eclipse.org/eclipselink/documentation/2.5/concepts/monitoring003.htm#BABJABIH)を参照してください。このツールは、マルチスレッド化されたサーバー環境の情報をプロファイルおよびモニターすることを目的としています。

- パフォーマンスのプロファイルの詳細は、「Task 1: Measure EclipseLink Performance with the EclipseLink Profiler」(http://www.eclipse.org/eclipselink/documentation/2.5/solutions/performance002.htm#CHDIAFJI)を参照してください。このツールは、シングルスレッドの限定的なユースケースでの使用を想定しています。

- パフォーマンスの問題のデバッグおよびテストを行う場合、EclipseLinkから生成されたSQLを確認できます。SQLを確認するには、ロギング用のEclipseLink JPA拡張機能を使用して、ロギング・レベルをFINEに上げます。
最適なパフォーマンスを得るために、プロファイリングまたはデバッグが終了したら、必ずロギング・レベルをデフォルト・レベルに戻してください。

第IV部

SOA Suiteコンポーネント

この部では、パフォーマンスを改善するためにOracle SOA Suiteコンポーネントをチューニングしてする方法について説明します。

SOA Suiteコンポーネントについては、次の章で説明します。

- 第11章「SOAインフラストラクチャのチューニング」

- 第12章「Oracle BPEL Process Managerのチューニング」

- 第13章「Oracle Mediatorのチューニング」

- 第14章「Oracle Managed File Transferのチューニング」

- 第15章「Oracle Business Rulesのチューニング」

- 第16章「Oracle Business Process Managementのチューニング」

- 第17章「Oracle Human Workflowのチューニング」

- 第18章「Oracle Business Activity Monitoringのチューニング」

- 第19章「Oracle Service Busのチューニング」

- 第20章「Oracle Enterprise Scheduler Serviceのチューニング」

B2B、Healthcare Integrationおよびアダプタのチューニング情報は、他の場所で説明しています。示されたリンクを使用して、パフォーマンスのためのチューニング方法を見つけることができます。

- Oracle B2Bユーザーズ・ガイド

- Oracle SOA Suite Healthcare Integrationユーザーズ・ガイド

- テクノロジ・アダプタの理解のOracle JCA Adapterチューニング・ガイドに関する項

11 SOAインフラストラクチャのチューニング

この章では、SOAインフラストラクチャのプロパティのチューニング方法について説明します。

- 第11.1項「SOAインフラストラクチャについて」

- 第11.2項「SOAワーク・マネージャのチューニング」

- 第11.3項「SOAインフラストラクチャのパラメータのチューニング」

- 第11.4項「高度なチューニング・オプションの使用」

- 第11.5項「ワーク・マネージャの高度なチューニング」

11.1 SOAインフラストラクチャについて

SOAインフラストラクチャは、Oracle WebLogic Serverで実行されるJava EE準拠のアプリケーションです。アプリケーションでは、コンポジットとそのライフサイクル、サービス・エンジンおよびバインディング・コンポーネントが管理されます。詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のSOAインフラストラクチャ・アプリケーションの概要に関する項を参照してください。

この章では、ワーク・マネージャおよびその他のチューニング・パラメータを使用して、SOAインフラストラクチャ・コンポーネントをチューニングするために使用できる概念およびプロシージャをいくつか説明します。

この章では、全体的な方法に必要な診断ツールや手法は対象としませんが、分離された症状のための分離されたチューニング・オプションについて説明しています。問題のある領域を特定するためのSOAインフラストラクチャのパフォーマンス・モニタリングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャのモニタリングに関する項を参照してください。

11.2 SOAワーク・マネージャのチューニング

この項では、ワーク・マネージャを利用するために実行できる簡単なチェックおよび構成をいくつか説明します。

Oracle SOA Suite 12c (12.1.3)から、ワーク・マネージャはほとんどのSOA関連ワーク・スレッドを処理するようになりました。ワーク・マネージャがスレッドを管理して自己チューニングする方法の詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャの理解に関する項を参照してください。

ワーク・マネージャの構成を試みる前に、使用する環境をよく理解し、次を定量化できる必要があります。

- 処理が必要な受信リクエストのボリューム

- トランザクションのSLA予測を含む内部処理要件

- イベント配信ネットワークやほとんどのアダプタなど、ワーク・マネージャを使用しないプロセスの理解

ここで収集した情報に基づいて、次のタスクを実行することによってワーク・マネージャの自己チューニング機能を利用できます。

- SOADataSourceプロパティでのデータベース接続の構成

- SOAMaxThreadsConfig属性でのワーク・マネージャの構成

11.2.1 SOADataSourceプロパティでのデータベース接続の構成

SOADataSourceプロパティは、SOAプロセスに使用可能な同時データベース接続の総数を決定します。SOAプロセスはほとんどのアクティビティにデータベースを使用するため、これは非常に重要な設定であり、適切に構成しないとボトルネックとなる可能性があります。

この設定をチューニングするには、使用するデータベース・リソースについて理解し、DBAに助言を求めることが重要です。

SOADataSourceをチューニングするには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 左側のメニューから「サービス」を選択し、「DataSources」を選択します。

3. 「DataSource」構成ページで、「SOADataSource」を選択します。

4. 「接続プール」タブを選択し、スクロールダウンして「最大容量」属性を見つけます。

「最大容量」属性のデフォルトは50です。最も実用的なユースケースのために、この値を300に設定してSOADataSource接続プール全体のサイズを大きくする必要があります。

SOADataSource設定は、第11.2.2項で説明されるSOAMaxThreadConfig構成によって利用されます。SOADataSourceはすべてのワーク・マネージャが使用できる接続の総数を定義し、SOAMaxThreadConfig属性は、それらの接続のなかでワーク・マネージャの特定のカテゴリが使用できる接続の割合を定義します。

11.2.2 SOAMaxThreadsConfig属性でのワーク・マネージャの構成

SOAコンポジットには、様々なコンポーネントおよび機能領域を処理するワーク・マネージャのグループが関連付けられます。SOAMaxThreadsConfig属性は、ドメイン内の異なるSOAワーク・マネージャのグループに許可されるスレッド数を決定します。

受信リクエスト、内部プロセスおよびその他のSOAプロセスを処理するために割り当てられたスレッド数は、第11.2.1項で説明されているSOADataSourceプロパティの割合として定義されます。SOAMaxThreadsConfig属性のデフォルトの割合の値とカテゴリを表11-1に示します。

表11-1 SOAMaxThreadsConfigによって決定されるワーク・マネージャに対するスレッド配信

グループ

説明

incomingRequestsPercentage

デフォルト: 20%

このパラメータは、受信クライアント・リクエストを処理するワーク・マネージャにシステムが割り当てるスレッドの割合を決定します。

internalBufferPercentage

デフォルト: 30%

このパラメータは、EDNやアダプタなど、その他のSOA機能に配信されるスレッドの割合を決定します。

internalProcessingPercentage

デフォルト: 50%

このパラメータは、内部プロセス用にシステムがワーク・マネージャに割り当てるスレッドの割合を決定します。

この属性はドメイン・レベルで定義され、そのドメインにあるすべてのワーク・マネージャに適用されます。Fusion Middleware Control MBeanブラウザでSoaInfraConfig MBeanを使用してこの属性を設定できます。

属性にアクセスするには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 「WebLogicドメイン」メニューから「システムMBeanブラウザ」を選択します。

3. 「システムMBeanブラウザ」フォルダ構造で、次のフォルダにナビゲートします: 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: AdminServerName」→「SoaInfraConfig」→「soa-infra」

4. 「soa-infra」をクリックすると、その属性が右側のメイン・ペインにリストされます。SOAMaxThreadsConfig属性を探してクリックします。表11-1に示されたパラメータおよび値が表示されます。
変更の準備ができたら「適用」をクリックします。

この画面で調節している値は、スレッドの個別の数ではなく割合であることに注意してください。第11.2.1項に説明されているSOADataSourceプロパティの値を調べることによって、使用できるスレッドの総数を確認する必要があります。

SOADataSourceが50接続に設定され、表11-1に示されているデフォルトのSOAMaxThreadConfigの割合を保持しているサンプル・シナリオでは、次のスレッド割当てになります。

- 50の20% = 10のスレッドが受信リクエストを処理します

- 50の30% = 15のスレッドがワーク・マネージャを使用しないプロセス用です

- 50の50% = 25のスレッドが内部プロセスを処理します

11.3 SOAインフラストラクチャのパラメータのチューニング

表11-2に、SOAインフラストラクチャのパフォーマンスに最も大きい影響を与えるパラメータの最適な設定を示します。

表11-2 重要なSOAインフラストラクチャのチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

AuditLevel

デフォルト: Production

- データベースのCPU使用率が高くなっています

- 競合により、アプリケーションでの処理時間が長くなっています

パフォーマンス低下を防ぐために、監査レベルを可能なかぎり低く保持するか、デフォルトのProductionを保持します。監査レベルをDevelopmentに設定することは、可能なかぎり避けます。

このパラメータはEnterprise Managerで設定できます。「SOAインフラストラクチャの共通プロパティ」ページにAudit Levelパラメータ・ページがあります。

このページを見つけるには、次の手順を実行します。

1. 左側の「ターゲット・ナビゲーション」でSOAフォルダを切り替えます。

2. チューニングするsoa-infra (soa_server)上で右クリックします。

3. 「SOA管理」→「共通プロパティ」の順に選択します。

このパラメータの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle SOA SuiteおよびOracle BPM Suiteプロファイルの構成に関する項を参照してください。

監査レベルを下げると、システムが生成する監査データが少なくなります。

パフォーマンスに関する問題の診断および一般的なトラブルシューティングは、さらに難しい場合があります。

Audit Purge Policy

デフォルト: 毎日深夜に、7日以上経過したレコードをパージします

- データベース・サイズが指数関数的に増大しています

- ピーク時に構成した場合、パージによって他のプロセスのリソースが奪われる可能性があります

- 自動パージが有効であることを確認します

- パージの実行回数を増やします

- 他のプロセスとのリソース競合が少ない時間に自動パージが開始されるように設定します
Oracle Enterprise Manager Fusion MIddleware Controlの「自動パージ」ページを検索する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle Enterprise Manager Fusion Middleware Controlでの多数のインスタンスの削除に関する項を参照してください。

この機能を無効にすると、進行中のデータベース増大の保守にさらに時間がかかります。

11.4 高度なチューニング・オプションの使用

この章の後半では、検討する可能性があるその他のSOAのパフォーマンス・チューニング設定について説明します。これらのオプションは特定の順序で並んではいません。これらのプロパティを変更する前に、使用する環境、SOAプロセスおよび非SOAプロセスについて全体的に理解しておく必要があります。

高度なパフォーマンス最適化は、個別のシナリオ、設定、環境および予測に対してカスタマイズされた方法にする必要があることを理解することが重要です。カスタマイズされた方法には、最適化が必要なボトルネックおよび領域を特定して分離するために、詳細な診断情報の取得が必要です。

問題のある領域を特定するためのSOAインフラストラクチャのパフォーマンス・モニタリングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャのモニタリングに関する項を参照してください。

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

- コンポジットの遅延ロード機能の有効化

- モジュール性のプロファイルの変更

- SOAプロセスのデータベースのチューニング

- イベント配信ネットワーク・パラメータのチューニング

- WebLogic Serverのチューニング

11.4.1 コンポジットの遅延ロード機能の有効化

コンポジットの遅延ロードは12cの新機能です。多数のコンポジットがデプロイされているとき、これによってサーバー起動時間が改善されます。

サーバー起動時に、最小限のコンポジットがロードされ、つまり、メモリー内のJavaモデルおよびMBeanのみが作成されます。コンポジットによって使用されるコンポーネントおよびリソースのロードなどの初期化タスク、つまり、WSLDおよびスキーマ・ファイルは、後で必要になり最初に要求された時にロードされます。

これによってサーバー起動時間が大幅に改善され、リクエストを受信するときのコンポジット起動時間がずれて、ほとんど使用されないまたはリタイアしたコンポジットによるオーバーヘッドが削減されます。

コンポジットの遅延ロードは次の場合に役立ちます。

- サーバー障害時に迅速な障害回復時間を必要とするシナリオ

- サイズが大きいWSDLSまたはスキーマ・ファイルを使用するコンポジットを大量に持つ顧客

コンポジットの遅延ロードはデフォルトで有効であり、ドメイン・レベルおよびコンポジット・レベルで構成できます。詳細は、次の各項を参照してください。

- ドメイン・レベルでのコンポジット遅延ロードの構成

- コンポーネント・レベルでのコンポジット遅延ロードの構成

11.4.1.1 ドメイン・レベルでのコンポジット遅延ロードの構成

コンポジットの遅延ロードは、デフォルトでドメイン・レベルで有効です。この設定は、Fusion Middleware ControlのEnterprise ManagerのシステムMBeanブラウザから無効にできます。この設定への変更は、サーバーの再起動時に有効になります。

ドメイン・レベルの遅延ロード機能の設定を変更するには、次の手順を実行します。

1. Enterprise Managerにログインした後、「ターゲット・ナビゲーション」ブラウザのWebLogicドメインのリストで、チューニングするドメインを右クリックします。

2. ドロップダウン・メニューから「システムMBeanブラウザ」を選択します。

3. 「システムMBeanブラウザ」フォルダ構造で、次のフォルダにナビゲートします: 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: AdminServerName」→「SoaInfraConfig」→「soa-infra」

4. 「soa-infra」をクリックすると、その属性が右側のメイン・ペインにリストされます。CompositeLazyLoading属性を探してクリックします。

5. CompositeLazyLoadingページで、値をtrueに設定して有効にするか、falseに設定して無効にすることができます。変更の準備ができたら「適用」をクリックします。

11.4.1.2 コンポーネント・レベルでのコンポジット遅延ロードの構成

デフォルトでは、コンポジットはドメイン・レベルの遅延ロード設定を継承します。この動作を特定のコンポジット・レベルで制御するユースケースがある場合、composite.xmlで構成することができ、これは新しいSOA Suiteコンポジット・アプリケーションを作成したときに生成されるファイルです。

編集するアプリケーションのホーム・フォルダにcomposite.xmlがあります。また、JDeveloperでアクセスすることでcomposite.xmlを編集できます。composite.xmlの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のSOAアプリケーションおよびプロジェクトを作成した場合の処理に関する項を参照してください。

編集するアプリケーションのcomposite.xmlの先頭に新しいプロパティlazyLoading="false"を追加して、ドメイン・レベルでのデフォルトの動作をオーバーライドする必要があります。その後コンポジットをデプロイします。

サンプル・コード・スニペットを次に示します。

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 12.1.3.0.0 at [8/7/13 4:14 PM]. -->
<composite name="ValidatePayment"
revision="1.0"
label="2013-08-07_16-14-11_843"
mode="active"
state="on"
lazyLoading="false"
xmlns="http://xmlns.oracle.com/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
……….
……….
</composite>

11.4.2 モジュール性のプロファイルの変更

モジュール性は、メモリー・フットプリントおよびサーバー起動時間の改善に役立つもう1つの12c機能です。プロファイル・オプションの一部は、選択したコンポジットによって使用されるコンポーネントおよび機能のみに制限されています。選択したモジュール性プロファイルによって、メモリーにロードされるコンポーネントが決定されます。

12cには、インストール完了後に変更できる即時利用可能なプロファイルが付属しています。デフォルトで、新規の12c顧客には、インストール・プロファイルとしてSOA_FOUNDATIONがあります。12cにアップグレードする既存の顧客には、デフォルトでインストール・プロファイルとしてSOA_CLASSICがあります。

表11-3に、メモリー・フットプリント・サイズが増加する順にモジュール性プロファイルを示します。

表11-3 モジュール性プロファイル

プロファイル

コンポーネント

BPEL-ONLY

BPELコンポーネント + SOA共通インフラストラクチャ + 部分アダプタ・セット

ORCHESTRATION

BPELのみ + HWF + 部分アダプタ・セット

SOA FOUNDATION

新規12c顧客のデフォルト

Orchestration + Mediator + Rules + 部分アダプタ・セット

SOA FOUNDATION ENTERPRISE

SOA Foundation + 完全アダプタ・セット

SOA FOUNDATION WITH B2B

SOA Foundation Enterprise + B2B

SOA FOUNDATION WITH HEALTHCARE

SOA Foundation with B2B + Healthcare UI

SOA CLASSIC

アップグレード顧客のデフォルト

SOA Foundation with B2B + BPMモジュール

SOA Suiteで制限されたコンポーネントまたは機能のセットを使用している場合、プロファイルを変更してメモリー使用率およびサーバー起動時間を最適化できます。これによって重要なプロセス用にリソースを解放し、障害回復を改善できます。

モジュール性プロファイルは、Fusion Middleware ControlのEnterprise ManagerのSOAダッシュボードから変更できます。

プロファイルの変更方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャの共通プロパティに関する項を参照して、「SOAインフラストラクチャの共通プロパティ」ページを探してください。

次にプロファイルの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle SOA SuiteおよびOracle BPM Suiteプロファイルの構成に関する項を参照してください。

11.4.3 SOAプロセスのデータベースのチューニング

この項では、データベースをSOAプロセス用にチューニングするための高度な戦略について説明します。先に進む前にこのドキュメントの第2.6項に記載されている一般的なデータベース・チューニング提案を参照して従っていることを確認してください。

11.4.3.1 オプティマイザ統計の収集

オプティマイザ統計により、データベースとデータベース・オブジェクトに関する詳細が提供されます。問合せオプティマイザは、これらの統計を使用して各SQL文に最適な実行計画を選択します。詳細は、『Oracle Database SQLチューニング・ガイド』の問合せオプティマイザの概要に関する項を参照してください。

11.4.3.1.1 自動統計収集

データベース内のオブジェクトは絶えず変化するため、オブジェクトを正確に表すには統計を定期的に更新する必要があります。

すべてのSOAデータベースでは、自動統計収集を使用する必要があります。これはデフォルトで有効化されています。このジョブは毎晩実行されます。詳細は、『Oracle Database SQLチューニング・ガイド』の自動オプティマイザ統計収集の制御に関する項を参照してください。

11.4.3.1.2 手動統計収集

自動オプティマイザ統計収集は大半のデータベース・オブジェクトで十分ですが、動作中に近いデータベースや、大幅に変更されたりパージされた表では、手動統計収集が必要です。詳細は、『Oracle Database SQLチューニング・ガイド』のオプティマイザ統計の手動収集に関する項を参照してください。

失効データを定期的にパージするSOAデータベースでは、パージ完了直後に統計を手動で収集する必要があります。これらの場合、DBMS_STATS.GATHER_TABLE_STATSプロシージャを使用します。この方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_STATSに関する項を参照してください。

11.4.3.1.3 統計によるMDSデータベース・リポジトリの最適化

自動統計収集が有効化されていることを確認します。詳細は、『Oracle Database SQLチューニング・ガイド』の自動オプティマイザ統計収集の制御に関する項を参照してください。

ほとんどの場合、MDS_PATHS表のPATH_FULLNAMEにおける最初の32文字は同じです。次を行うことでヒストグラムの同じセクションにデータベースで格納しないようにできます。

1. 次のようにシステムとして構造化されたコマンドを実行することで、PATH_FULLNAME列のヒストグラムを削除します。

execute dbms_stats.delete_column_stats(ownname=>'mdsSchemaOwner', tabname=>'MDS_PATHS', colname=>'PATH_FULLNAME', col_stat_type=> 'HISTOGRAM');

2. 次のように構造化されたコマンドでPATH_FULLNAME列のヒストグラムの収集を除外するように、表プリファレンスを設定します。

execute dbms_stats.set_table_prefs(mdsSchemaOwner, 'MDS_PATHS', 'METHOD_OPT', 'FOR COLUMNS SIZE 1 PATH_FULLNAME');

11.4.3.2 SOAの一時表領域のチューニング

この項に進む前に、TEMP表領域をOracle Fusion Middleware用にチューニングするための一般的なガイドラインについて、第2.6.2項を参照してください。

一部のSOA問合せでは大容量のディスク・ソートが生成される場合があり、大容量の一時表領域が必要になります。そのため、複数の一時表領域と表領域グループを使用して、これらの要件に適合させ、最適なパフォーマンスを確保することをお薦めします。

SOAスキーマ所有者に割り当てられる一時表領域グループまたはTEMP表領域の最小提案サイズは、自動拡張が有効な状態で6GBです。表領域をサイズ変更し自動拡張を有効にする方法の詳細は、『Oracle Database管理者ガイド』のデータ・ファイル・サイズの変更に関する項を参照してください。

11.4.3.3 SOAデータベース競合の最小化

大半のSOAワークロードでは高い負荷のDMLアクティビティがデータベースで生成され、競合がデータベース・オブジェクトで発生する可能性があります。

自動ワークロード・リポジトリ(AWR)レポートの待機イベント・データにより、パフォーマンスに影響する場合がある様々な症状が明らかになります。SOAデータベースで発生する場合がある最多発待機イベントは、次のとおりです。

- DB CPU

- db file順次読取り、db file散布読取り

- log file sync

- enq: HW - contention

- enq:TX-indexcontention

- buffer busy waits

- gc buffer busy acquire、gc buffer busy release (RAC)

- enq: SQ - contention

この項の残りでは、次の待機イベントをチューニングする方法について説明します。

- log file sync

- enq:HW contention

- enq:TX-indexcontention

また、gc buffer busy acquireとgc buffer busy releaseの待機イベントの推奨事項は、「enq:TX-indexcontention」の項でも説明しています。

AWRレポートを使用して競合をデータベースで識別する方法の詳細は、データベース・パフォーマンス・チューニング・ガイドの時間の経過によるデータベース・パフォーマンスの比較に関する項を参照してください。

11.4.3.3.1 log file sync

SOAデータベースでは、長い平均待機時間のフォアグラウンド待機イベントlog file syncが発生することがごく普通です。これはREDOログ・パフォーマンスにより発生します。長いlog file sync待機では次のような原因が考えられます。

- データベースのログ・ライター(LGWR)では、次のいずれかの原因で高速に書込みを完了できません。

- ログ・ファイルのディスクI/Oパフォーマンスは十分ではありません。

- LGWRではCPUリソースが不足しています。

- LGWRでは、過剰なコミットにより十分高速にプロセスをポストできません。

- LGWRでは他のデータベース競合(エンキュー待機やラッチ競合など)が発生しています。

REDOログのパフォーマンスをチューニングすると、Oracle Fusion Middleware環境で実行するアプリケーションのパフォーマンスを向上できます。

この項に記載の戦略を使用してSOAプロセス用にチューニングする前に、REDOログをOracle Fusion Middleware用にチューニングするための一般的なガイドラインについて、第2.6.2項を参照してください。

- LGWR待機イベントの検索

- ログ切替えの頻度を制御しシステム待機を最小化するようにオンラインREDOログのサイズ設定

- ボトルネック防止のためのREDOログ・ディスクの最適化

- log_bufferの最適サイズ設定の決定

- LGWRプロセスのチューニング

- ExaData用スマート・フラッシュ・ロギングの使用

LGWR待機イベントの検索

根本原因を識別する最初の手順では、LGWR待機イベントを探して分析します。次の例に示すように、SIDを使用して、LGWR待機イベントを問い合せます。

SQL> SELECT sid, event,  time_waited, time_waited_micro
FROM v$session_event
WHERE sid IN
(SELECT SID FROM v$session WHERE type!='USER' AND program LIKE '%LGWR%' )
ORDER BY time_waited;

ログ切替えの頻度を制御しシステム待機を最小化するようにオンラインREDOログのサイズ設定

REDOログの最小提案設定は、それぞれ2GBのログ・グループを3つ以上保持することです。REDOログのパフォーマンスを定期的に監視します。そして、ログ切替えの頻度を制御しシステム待機を最小化するために、REDOログ・グループの数と各メンバーのサイズを適切に調整します。

システムが生成するREDOの量に従って、REDOログ・ファイルをサイズ設定します。大まかなガイドラインとしては、20分ごとに最大1回ログを切り替えます。

たとえば、データベース・アクティビティのピーク時にオンラインREDOログを5分ごとに1回切り替える場合、20分ガイドラインを実現するには、ログはそれぞれ現在のサイズよりも4倍大きくする必要があります。この計算方法は、20分/5分=4xです。

ボトルネック防止のためのREDOログ・ディスクの最適化

SOAデータベースは高い書込み集中型で、トランザクションごとに1秒当たり過大な量のREDOが生成されます。ディスクをチューニングしていなくてもREDOログ・ボトルネックが軽減される場合があります。Oracleではすべての更新をすべてのディスクで単一のREDO場所に書き込む必要があるからです。

I/O帯域幅が問題の場合、I/O帯域幅を改善する処置以外を行っても有用ではありません。REDOボトルネックを軽減する方法の1つは、高速なREDO記憶域を使用することです。ソリッド・ステート・デバイス(SSD)のREDOログ・ファイルを使用することをお薦めします。SSDは円盤ディスクよりも帯域幅が広いです。

log_bufferの最適サイズ設定の決定

SOAアプリケーションでは大量のデータの挿入、変更および削除が行われます。これらの操作の大半は、バッチ・モードではなく行単位の方法でコミットされます。頻繁にコミットすると、大幅なオーバーヘッドがREDOパフォーマンスで発生するので、log_bufferのサイズを最適に設定することはパフォーマンスで重要になります。

AWRレポートまたはV$ビュー(あるいはその両方)からのREDO BUFFER ALLOCATION RETRIES統計では、ユーザー・プロセスがREDOログ・バッファ内の領域の使用を待機した回数を反映します。次の問合せで動的パフォーマンス・ビューのV$SYSSTATによりこの統計を取得できます。

SELECT NAME, VALUE
FROM V$SYSSTAT
WHERE NAME = 'redo buffer allocation retries';

redo buffer allocation retriesの値は、ある時間間隔に対して0(ゼロ)に近い値である必要があります。この値が一貫して増分する場合は、プロセスがREDOログ・バッファ内の領域を待機する必要があったということです。この待機は、ログ・バッファが小さすぎること、あるいはチェックポイント機能が原因となっていることがあります。次を試行することでこの待機を改善できます。

- 必要であれば、初期化パラメータのLOG_BUFFERの値を変更することによって、REDOログ・バッファのサイズを大きくできます。このパラメータの値はバイト単位で表されます。書込み集中型ワークロードにおける経験則としてはまず、ログ・バッファを100MBに構成することです。log_buffer設定の値を大きくする際は注意してください。過大なREDOサイズによって長時間のlog file sync待機も発生する場合があるからです。

- チェックポイント機能またはアーカイブ・プロセスを改善します。

また、log buffer space待機イベントがインスタンスの待機時間における重要な要因であるかどうかもチェックできます。そうでない場合、ログ・バッファ・サイズが適切である可能性が高いです。

LGWRプロセスのチューニング

ほとんどのSOAワークロードでは、コミット率が非常に高く、コミットを減らすことはオプションではありません。前の戦略で長時間のlog file syncに対処してもREDOログのパフォーマンスが向上しない場合、コマンド・ラインからLGWRの優先度クラスをRTに高くしたり、LGWRの優先度を高くします。

ExaData用スマート・フラッシュ・ロギングの使用

データベースがExaDataマシンにある場合、スマート・フラッシュ・ロギング機能を活用するためには、少なくともバンドル・パッチ11 (BP11)がインストールされている必要があります。

Exadataスマート・フラッシュ・ロギングは、データベース・バージョン11.2.0.2 + BP11とExadata Storageソフトウェア11.2.2.4.2で実装された追加機能です。この機能により、512MBのフラッシュ記憶域がREDO書込み用に予約され、異なるパターンの動作がLGRWプロセスで採用されます。

この機能を使用しないシステムでは、LGWRではREDOログの多重化コピーに並列して書込みを行い、すべての書込みが完了するのを待機します。これらの書込みの実行に要する時間(Oracle待機インタフェース統計ログ・ファイル・パラレル書込みで示される)は、最も低速なディスクが書込みを完了するのに要する時間であることをこれは意味します。

Exadataスマート・フラッシュ・ロギングでは、REDOログ・ファイルはディスクに残りますが、512MBの予約領域が別にフラッシュ記憶域に作成されます。書込みコールが発行されると、LGWRではREDOログをディスクに通常どおりに書き込みますが、フラッシュ領域への並列書込みも行います。そして、他方を待機せずに続行した後に、LGWRではこれらの書込みのどれかが最初にポストを完了するのを待機します。

11.4.3.3.2 enq:HW contention

競合プロセスが同じ表に挿入して、表の最高水位標を同時に増加させようとすると、最高水位エンキュー競合(enq:HW - contention)が発生します。

SOAデータベースでは、ラージ・オブジェクト(LOB)列(CUBE_SCOPE、XML_DOCUMENT、AUDIT_DETAILSなど)のある表でこの問題が発生します。負荷が高くなると、これらの表のLOBセグメントでは競合が発生し、AWRレポートで待機イベントのenq: HW contentionとして表示されます。

OracleデータベースにおけるLOBのデフォルト記憶域はBasicFileです。頻繁にエクステントを割り当てたりチャンクを再利用すると、LOBセグメントの最高水位標で競合が発生する場合があります。また、ASSMが管理するLOBセグメントでこの競合が発生する場合があります。領域割当てでは一度に1つのブロックのみ取得するからです。

LOB記憶域をBasicFileからSecureFileに切り替えることで、この競合を解消できます。SecureFileは、従来のBasicFileに比べてパフォーマンス上の利点があるLOB記憶域アーキテクチャです。これらの2つのアーキテクチャの詳細は、データベースSecureFileおよびラージ・オブジェクト開発者ガイド のLOB記憶域に関する項を参照してください。

次のいずれかの方法を使用すると、BasicFileをSecureFileに移行できます。

- データベース・パラメータSECURE_FILES = ALWAYSを設定します。
RCUを使用してSOA表を作成する前に新規インストールでこの方法が適用できます。このパラメータがインスタンス・レベルで設定されると、作成された新規LOBセグメントではSecureFileを自動的に使用します。

- オンライン再定義方法を使用します。
SOA表が作成されているインストールでこの方法が適用できます。このような場合、enq: HW contentionが発生しているSOAデータベースにある表からLOBセグメントをSecureFileに移行できます。

オンライン再定義方法を使用してSecureFileに移行でき、停止時間はほとんどありません。lob_storage_asパラメータを使用してLOBストアの再割当てを行う方法の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』のDBMS_REDEFINITIONの使用に関する項を参照してください。

- 次のスクリプトを使用してデータベース・イベント値を44951に設定します。

ALTER SYSTEM SET EVENT='44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024? scope=spfile;

この方法により、11gよりも古いOracleバージョンを使用するSOAインストールでenq:HW contentionsをLOBセグメントで防止するのを支援します。

AWRと自動データベース診断モニター(ADDM)のレポートを使用して、enq:HW – contentionsで影響を受けるLOBオブジェクトを識別できます。ただし、ほとんどのシステムでは、次の表に記載されているLOB列をSecureFileに移動することを強くお薦めします。

表の名前

列名

推奨LOB記憶域アーキテクチャ

ATTACHMENT

ATTACHMENT

COMPRESS CACHE

AUDIT_DETAILS

BIN

COMPRESS CACHE

CUBE_SCOPE

SCOPE_BIN

COMPRESS CACHE

11.4.3.3.3 enq:TX-indexcontention

ほとんどのSOAシナリオでは、複数のデータベース・セッションにより何千もの行がSOA表に挿入されます。これらの状況では、索引キー(特に主キー索引)の数は絶えず増加します。

主キー索引の数が時間の経過により増加しても、Bツリー構造索引がキー挿入で少数のデータベース・ブロックのみをターゲットにします。これらのBツリー索引挿入がReal Application Cluster (RAC)で問題になる場合があります。この問題は、AWRレポートで長時間のバッファ・ビジー待機と表示されます。

Bツリー索引により、RAC環境で他の競合が生成され、gc buffer busy acquireとgc buffer busy releaseの待機イベントとしてAWRに表示されます。索引に行を挿入するトランザクションが、他のトランザクションによる索引ブロック分割の終了を待つ必要ある場合、これらが発生し、同様にセッションが強制的に待機します。多くの同時挿入により過剰な索引ブロック分割が行われると、パフォーマンスが低下します。

これらの競合の解決策は、グローバルでハッシュのパーティション化索引を作成することです。これによって多くのデータベース・ブロックにおいて索引キーを強制的にランダムに分散して、これらの競合やホット・スポットを防止します。

ハッシュ・パーティション化は、索引競合に対処する最善のチューニング方法であることが立証されています。AWRとADDMのレポートを使用して、パーティション化が必要な索引を識別する必要があります。ホット索引を識別したら、ハッシュ・パーティション化を検討し、索引競合を削減するか予防します。

ハッシュ・パーティション化の詳細は、データベースVLDBおよびパーティショニング・ガイドのハッシュ・パーティション化表とグローバル索引の作成に関する項を参照してください。

11.4.3.4 パージ

積極的で継続的なパージの必要性は、パフォーマンスを改善しディスク領域をSOAで制御する重要な要因です。

自動パージ機能の管理がデフォルトで有効にされ、12cで進行中のデータベース増大の管理に役立ちますが、この機能が表11-2に記載されています。また、大量のデータが蓄積されるSOAインストールでは、パージ戦略を実装して、冗長なデータをクリーンアップし、SQL問合せパフォーマンスを支援して, ディスク領域を節約する必要があります。

パージ戦略を作成するには、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のパージとパーティション化方法の開発に関する項を参照してください。

11.4.3.5 領域の再利用

不要なデータをSOA表から頻繁にパージするSOAインストールは、ディスク領域問題が発生する可能性が高いです。

ASSMとローカル管理表領域でもこの問題が発生します。自動パージ・スクリプトで行をデータベースの表と索引から削除して、再利用できるようにデータブロック内の領域を解放しても、行が削除された直後に領域は解放されません。特に表にLOB列がある場合。これによって、断片化が発生し、領域が過小で再利用できません。

断片化を軽減してディスク領域を統合するには、表とLOB列を手動で小さくして、定期的に領域を解放する必要があります。

オンラインによるセグメントの縮小で利点を得られるセグメントを特定するには、セグメント・アドバイザを使用します。ただし、定期パージ後はSOAセグメントの大半がオンラインのセグメント縮小操作の候補になります。セグメント・アドバイザの使用方法の詳細は、『Oracle Database管理者ガイド』のセグメント・アドバイザの使用に関する項を参照してください。

縮小が必要なデータベース表と索引を識別したら、次のコマンドを使用して、領域を手動で解放します。

ALTER TABLE CUBE_SCOPE ENABLE ROW MOVEMENT;
ALTER TABLE CUBE_SCOPE SHRINK SPACE;
ALTER TABLE CUBE_SCOPE MODIFY LOB (SCOPE_BIN) (SHRINK SPACE);
ALTER TABLE CUBE_SCOPE DISABLE ROW MOVEMENT;

この縮小操作によって、最高水位標を下回る空き領域が統合され、セグメントが圧縮されます。そして、最高水位標が移動し、最高水位標の上で領域が割当て解除されます。

11.4.4 イベント配信ネットワーク・パラメータのチューニング

イベント配信ネットワーク(EDN)は、Oracle Mediator、Oracle BPEL Process Manager、およびOracle Application Development Frameworkエンティティ・オブジェクトなどの外部パブリッシャによってパブリッシュされたイベントを配信します。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のイベント配信ネットワークの概要に関する項を参照してください。

表11-4に、Fusion Middleware MBeanブラウザで検索してイベント配信を改善するためにチューニングできるパラメータを示します。

表11-4 イベント配信ネットワークのチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

numberOfPollerThreads

デフォルト: -1

- リソース不足問題、つまりメモリー不足、システム過負荷、トランザクションの問題など。

- 他のSOAスレッドとの競合

デフォルト値の-1は、システムがThreadsPerSubscriberを使用してポーラー・スレッド数を決定することを意味します。これはほとんどの構成に最適です。

ただし、多数のサブスクライバがある場合、デフォルト設定では各サブスクライバに対するスレッドの割当てが試行されます。これによってシステムが遅くなります。このタスクに作成されるポーラー・スレッドの数を制限するには、正の整数を定義する必要があります。

このパラメータの値をFusion Middleware MBeanブラウザで変更する方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のサービス・コンポーネント・レベルでのローカルのnumberOfPollerThreads値の更新に関する項を参照してください。

値がシステムに対して小さすぎる場合、ポーラー・スレッドによってイベント・バックログが発生し、イベント・パブリッシュとコンポジット・インスタンス作成の間の待機時間が長くなる可能性があります。

値が大きすぎる場合は、余分なポーラー・スレッドがサーバー・リソースを不必要に消費します。

ThreadsPerSubscriber

デフォルト: 1スレッド

- リソース不足問題、つまりメモリー不足、システム過負荷、トランザクションの問題など。

- 他のSOAスレッドとの競合

一般的に、スクライバごとに1スレッドというデフォルトは最適です。

パラメータnumberOfPollerThreadsはこの値よりも優先されるため、先に調整する必要があることに注意してください。

このパラメータの値をFusion Middleware MBeanブラウザで変更する方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のシステムMBeanブラウザでのThreadsPerSubscriber属性の更新に関する項を参照してください。

値がシステムに対して小さすぎる場合、ポーラー・スレッドによってイベント・バックログが発生し、イベント・パブリッシュとコンポジット・インスタンス作成の間の待機時間が長くなる可能性があります。

値が大きすぎる場合は、余分なポーラー・スレッドがサーバー・リソースを不必要に消費します。

表11-5に、JDeveloperで個別のビジネス・イベントに対して変更できるパラメータを示します。これらの属性を変更するには、編集するイベントを右クリックしてポップアップ・メニューを出します。このメニューから、編集するパラメータに応じて「サブスクライブ済イベントの編集...」または「パブリッシュ済イベントの編集...」を選択します。

編集できるサブスクライブ済イベント・パラメータの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のビジネス・イベントのサブスクライブ方法に関する項を参照してください。

表11-5 ビジネス・イベントのチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

サブスクライブ済イベントの一貫性

デフォルト: oneAndOnlyOne

ビジネス・イベント配信で次のいずれかまたは両方の問題が発生しています。

- イベント・サブスクライバに対する配信保証要件が満たされていません

- グローバル・トランザクションからの不必要なシステム・オーバーヘッドがあります

JDeveloperで選択したビジネス・イベントのレベルをguaranteedに設定します。保証付き配信はローカル・トランザクションで実行され、メイン・キューへのトリップは1回のみです。

Oracle Enterprise Manager Fusion Middleware Controlのサブスクリプション・ページでこのパラメータを編集できます。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のビジネス・イベント・サブスクライバの表示に関する項を参照してください。

oneAndOnlyOneは、リソースに負担をかけることによって配信を保証します。

guaranteed配信が失敗した場合、ローカルでの再試行は行われず、システム障害のメッセージが生成されます。コールしているグローバル・トランザクションがロールバックして再試行した場合、メッセージ配信はそのトランザクションの外部にあるため、メッセージ重複が発生する可能性があります。

サブスクライブ済イベントの永続性

デフォルト: Yes

ビジネス・イベント・メッセージで次のいずれかまたは両方の問題が発生しています。

- 複数削除されたイベントがあります

- システム内のメッセージが不必要に保存されています

JDeveloperで、「恒久」列の下の値をNoに設定して、サブスクライブ済イベントの永続性を無効にします。これによって、システムはメッセージを記憶域に永続化させることから解放されます。

Noにすると、イベントがパブリッシュされたときにサブスクライバが実行していない場合は、システムがイベントを削除します。

Yesにすると、イベントがJMSサーバーに保持され、オーバーヘッドが発生します。

パブリッシュ済イベントの永続配信

デフォルト: yes

- 信頼性のないメッセージング

- 高いオーバーヘッド

この値をNoに設定して永続配信を無効にします。これによってオーバーヘッドが削減されます。

Noにすると、永続性がなくなるためイベント・パブリッシュに続くメッセージングの信頼性が小さくなります。

Yesにすると、JMSサーバー・クラッシュから保護するためにオーバーヘッドが発生します。

パブリッシュ済イベントの存続時間

デフォルト: 0ミリ秒

- 期限切れでなく未消費のメッセージはシステム・リソースを占有し、手動でのクリーンアップが必要になります。

- サブスクライバが読み取る前にメッセージが削除されます。

期限切れメッセージがシステムから自動的に削除されてサブスクライバによって消費されないように、正の整数を指定します。整数はミリ秒を表します。

最善の値はシステムによって異なり、モニタリング・メトリックによって決定できます。

デフォルト値の0はメッセージが期限切れにならないことを意味します。

メッセージ有効期間の値が小さすぎると、パブリッシュ済のメッセージが対象のサブスクライバによって読み取られる前に期限切れになることがあります。一度削除されると取得できません。

値が大きすぎる場合は、残っているメッセージがシステム・リソースを占有することがあります。

11.4.4.1 マッピングによるJMSトピックの追加

デフォルトでは、すべてのイベントが単一のWLSトピックにマップされます。

JMSトピックが1つまたは制限されているためにイベントのバックログが大量にある場合や、イベント処理に待機時間が発生したり処理の速度が遅い場合、追加のJMSトピックを作成してJMSマッピングへのイベントを変更し、異なるパフォーマンス特性のイベント・タイプが別々にグループ化または管理されるようにする必要があります。

ただし、このようにすると、システムが管理するJMSトピックおよびJMSアーティファクトが追加されて、マッピング変更を考慮する必要があります。

新しいJMPSトピックの追加を選択した場合は、次のステップを考慮する必要があります。

- JMSトピック・タイプの選択

- JMSトピックの作成

- JMSトピックへのイベントのマッピング

JMSトピック・タイプの選択

WLSJMSトピックまたはAQJMSトピックのいずれかを作成できます。

WLSJMSはデフォルトのJMSトピック・タイプです。AQJMSと同様に、データベース索引付け、LOBストリーミング、埋込みルール・エンジンおよびロック管理は提供されません。

AQJMSは一般的にWLSJMSよりも高速ではありませんが、シングルスレッドであるため、システムのオカレンス数が多い場合はAQJMSが適切に機能します。AQJMSはまた、Exalogicの記憶域ノード数を少なくすることによって制限できます。

JMSトピックの作成

管理者としてログインしている場合、WebLogic管理コンソールのSOAJMSModuleの下に新規のWLSJMSトピックを作成できます。「新しいJMSシステム・モジュール・リソースの作成」に移動してJMSトピックを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプでシステム・モジュールでのトピックの作成に関する項を参照してください。

JDeveloperまたはSQL Developerでデータベース・ナビゲータを使用して、soainfraユーザーとして次のスクリプトを実行することによって、AQJMSトピックを作成できます。

define edn_user=your_soainfra_schema_username
define topic=your_custom_aqjms_topic_name, e.g. 'EDN_AQJMS_TOPIC_2'
define topic_table=your_custom_aqjms_topic_table, e.g. 'EDN_AQJMS_TOPIC_TABLE_2'

begin
DBMS_AQADM.stop_queue(queue_name => '&edn_user..&topic');
DBMS_AQADM.drop_queue(queue_name => '&edn_user..&topic');
DBMS_AQADM.drop_queue_table(queue_table => '&edn_user..&topic_table');
end;
/
begin
dbms_aqadm.create_queue_table(queue_table => '&edn_user..&topic_table',
queue_payload_type => 'SYS.AQ$_JMS_MESSAGE',
multiple_consumers => true);
dbms_aqadm.create_queue(queue_name => '&edn_user..&topic',
queue_table => '&edn_user..&topic_table',
max_retries => 256);
dbms_aqadm.start_queue(queue_name        =>       '&edn_user..&topic');
end;
/
commit;

AQ JMSトピックの詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSキューまたはトピックの作成に関する項を参照してください。

JMSトピックへのイベントのマッピング

新規のJMSトピックを作成すると、ビジネス・イベントを特定のトピックにマップできます。1つのイベント・タイプは1つのJMSトピックにのみマップできますが、1つのJMSトピックは複数のイベント・タイプを格納できることに注意してください。

Fusion Middleware ControlのEnterprise Managerを使用してイベントをマップする方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ビジネス・イベント」ページでのJMSトピック宛先へのビジネス・イベントのマッピングに関する項を参照してください。

11.4.5 WebLogic Serverのチューニング

SOAインフラストラクチャのパフォーマンスは、WebLogic Serverに依存します。WebLogic Serverのチューニングは別のタスクでありこのマニュアルでは詳細に説明していませんが、表11-6を使用して、SOAインフラストラクチャに影響を与えるチューニング・ノブを確認できます。

表11-6 SOAインフラストラクチャに対する重要なWebLogic Serverのチューニング

パラメータ

チューニングに関する推奨事項

リソース

ProductionModeEnabled

デフォルト: ドメイン作成中に設定したモード。

本番モードがパフォーマンスを最大化します。アプリケーションを開発中でない場合は、これを有効にする必要があります。Oracle Fusion Middleware ControlでProductionModeEnabled MBeanを有効にできます。

『Fusion Middleware ControlによるOracle WebLogic Serverの管理』の一般設定の構成に関する項を参照してください。

ドメイン・モードを変更すると、特定のセキュリティ設定および自動デプロイメント設定も変更されます。ドメイン・モードの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の開発モードと本番モードのデフォルトのチューニング値に関する項を参照してください。

WebLogic Serverのロギング・レベル

デフォルト: Notification

ログ記録リクエストの量を減らすために、可能なかぎりERRORやWARNINGなどの最低限のロギング・レベルを使用します。ハンドラおよびロガーのログ・レベルは様々な方法で設定できます。

これらの方法の詳細は、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のログ重大度レベルの使用に関する項を参照してください。

HTTPアクセス・ロギング

デフォルト: 有効

デフォルトでは、HTTPサブシステムはすべてのHTTPトランザクションのログをテキスト・ファイルに保存します。パフォーマンスを改善するには、HTTPアクセス・ロギングをオフにします。Oracle WebLogic Server管理コンソールを使用してこのプロパティを無効にできます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプでHTTPログの有効化および構成に関する項を参照してください。

JMS永続性および永続記憶域

デフォルト: Enabled

適切な永続性レベルがJava Message Service (JMS)の宛先に設定されていることを確認します。

- 永続的なJMSシナリオには、「ファイル・ストア」および「JDBCストア」の2つの選択肢があります。一般的に、「ファイル・ストア」での操作は「JDBCストア」での操作よりもパフォーマンスが向上します。複数のJMSサーバーが含まれる場合、個別のディスクに各ストアを作成して、I/Oの競合を少なくします。

- 非永続JMSシナリオの場合は、WebLogic ServerコンソールのJMSサーバーの「一般」タブで「詳細」セクションから「ストアの有効化」フラグの選択を解除して、JMSサーバー・レベルの永続性をオフにします。また、JMS宛先レベルの永続モードをオーバーライドできます。

永続的なJMSストアの作成および管理の詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のカスタム・ファイル・ストアおよびJDBCストアの使用に関する項を参照してください。

JMSサーバー・レベルの永続性をオフにする必要があるかどうかを決定するには、『Oracle WebLogic Serverサーバー環境の管理』の永続ストアの制限に関する項を参照してください。

接続バックログのバッファリング

多くの同時クライアントを処理する場合には、Accept Backlogパラメータをチューニングできます。

「バックログの受入れ」パラメータには、待機キューにバッファリングできるTCP接続の数を指定します。追加のリクエストを拒否する前にWebLogic Serverインスタンスが受け入れる接続リクエストの数をチューニングできます。

詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の接続バックログのバッファリングのチューニングに関する項を参照してください。

11.5 ワーク・マネージャの高度なチューニング

この項では、ワーク・マネージャをSOAプロジェクトおよび特定のコンポーネントにマップする方法、および高度な構成オプションのいくつかを使用してワーク・マネージャのパフォーマンスを細かくチューニングする方法の詳細を説明します。これらのオプションには次のチューニング戦略が含まれます。

- SOAワーク・マネージャ用のフェア・シェア・リクエスト・クラスの構成

- 新しいワーク・マネージャの制約の作成

SOA Suiteがインストールされると、SOAインフラストラクチャの様々な領域を管理するために、デフォルトのワーク・マネージャ、グローバル・ワーク・マネージャおよびアプリケーション・ワーク・マネージャのセットを作成します。

優先度が高いコンポジットには、高い優先度用に構成されたワーク・マネージャ・グループを関連付けることができます。表11-7に、SOAのインストール時に作成されるワーク・マネージャのセットを示し、それらが管理する作業領域を説明します。

表11-7 ワーク・マネージャの説明

ワーク・マネージャ名

担当する領域

SOA_Request_WM

次のようなSOA同期リクエスト・クライアント:

- ファサード呼出し

- WebServiceクライアント・リクエスト

- 直接/ADF/RESTリクエスト

- B2B

SOA_Notification_WM

すべてのSOA通知リクエスト。

WorkManagerName_dspSystem

BPEL固有のシステム・ディスパッチャ・メッセージ。

WorkManagerName_dspInvoke

BPEL固有のエンジン・プロセス呼出しディスパッチャ・メッセージ

WorkManagerName_dspEngine

BPELエンジン・プロセス・ディスパッチャ・メッセージ

WorkManagerName_dspNonBlocking

BPELエンジン・プロセス非ブロッキング呼出しディスパッチャ・メッセージ

WorkManagerName__Analytics

BPEL分析

WorkManagerName_MediatorParallelRouting

メディエータ・パラレル・ルーティング

WorkManagerName_MediatorErrorHandling

メディエータのエラー処理

WorkManagerName_bpmnSystem

BPMシステム・ディスパッチャ・メッセージ

WorkManagerName__bpmnInvoke

BPMエンジン・プロセス呼出しディスパッチャ・メッセージ

WorkManagerName__bpmnEngine

BPMプロセス・エンジン・ディスパッチャ・メッセージ

WorkManagerName__bpmnNonBlocking

BPMプロセス非ブロッキング呼出しディスパッチャ・メッセージ

SOA_DataSourceBound_WM

ワークフローEnterprise JavaBeans (EJB)を含む、SOADataSourceにアクセスするすべてのSOAバックエンド処理サービス。

SOA_Default_WM

SOADataSource接続プールにアクセスしないすべてのSOAサービス。ケース管理も処理します。

SOA_EDN_WM

イベント配信ネットワーク(EDN)

WorkManagerName_Adapter

アダプタ・フレームワーク

第11.2.2項で説明しているSOAMaxThreadsConfigプロパティは、ワーク・マネージャが受信リクエスト、内部プロセスおよびその他のプロセスの処理に使用する接続の数を決定します。この構成によって、システムが最大の可能性で機能しているときの、これらの各処理カテゴリの最適な使用率が決定されます。

また、最小および最大の制約をワーク・マネージャで設定して、ワーク・マネージャの接続の上限および下限を制御できます。ワーク・マネージャに割り当てられる相対的な優先度を決定するために、ワーク・マネージャのフェア・シェア・リクエスト・クラスを作成できます。ここで説明する制約およびリクエスト・クラスは、SOAワーク・マネージャで最も一般的に構成されているものです。

すべてのSOAワーク・マネージャには、最も有用なリクエスト・クラスおよび制約が事前に構成されています。デフォルトの設定で実行して、評価期間の後に重要な変更を行うことをお薦めします。

作成できるすべてのワーク・マネージャの制約およびリクエスト・クラス、およびそれらのデフォルトの動作の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のワーク・マネージャ・グループの管理に関する項を参照してください。

11.5.1 SOAワーク・マネージャ用のフェア・シェア・リクエスト・クラスの構成

フェア・シェア・リクエスト・クラスを使用すると、指定されているワーク・マネージャの相対的な優先度を指定できます。内部プロセスを管理するすべてのSOAワーク・マネージャは、デフォルトでそれぞれフェア・シェア値を20と80に設定して作成された2つのフェア・シェア・クラス(soa_fairShare_20およびsoa_fairShare_80)のいずれかに構成されています。フェア・シェア値は1から1000の相対値です。

SOAワーク・マネージャの優先度をさらにチューニングする場合、新しいフェア・シェア・クラスを作成する必要があります。この方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のワーク・マネージャ・グループの表示および作成に関する項を参照してください。

11.5.2 新しいワーク・マネージャの制約の作成

SOAMaxThreadConfigで使用可能なデフォルトのカテゴリに加えて、特定のシナリオに対処する新しいカテゴリを作成できます。

SOAのプロセスには、データベース接続が不要なものもあります。このようなプロセスはSOAデータ・ソースの割当てに依存せず、使用可能な接続を待機する必要がありません。

SOAインフラストラクチャは、ほとんどのプロセスを管理して適切にリソースを割り当てるワーク・マネージャを自動的に作成します。ほとんどの場合、既存のワーク・マネージャを利用して、前述のノブのいくつかを使用してそれらのパフォーマンスをチューニングすることによって、パフォーマンスを改善できます。

独自に処理する必要がある特別なシナリオがある場合は、新しいワーク・マネージャを作成して、特別な状況に合うようにそれを構成できます。新しいアプリケーションまたはWebアプリケーションのワーク・マネージャのいずれかを作成します。詳細な手順は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のワーク・マネージャ・グループの表示および作成に関する項を参照してください。

12 Oracle BPEL Process Managerのチューニング

Oracle Business Process Execution Language (BPEL) Process Managerには、コンポジット、ファブリック、アプリケーション、サーバーの各レベルでパフォーマンスを最適化するために構成可能なプロパティ設定がいくつか用意されています。この章では、各プロパティ設定について説明し、プロパティ設定の使用方法に関する推奨事項を示します。

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

- 12.1項「BPEL Process Managerについて」

- 第12.2項「BPELパラメータのチューニング」

- 第12.3項「その他のチューニング戦略の使用」

12.1 BPEL Process Managerについて

BPELとは、一連の独立したサービスを集めてエンドツーエンドのプロセス・フローを組み立てるための標準です。BPELを使用すれば、プロセス統合の取組みのコストおよび複雑さを大幅に軽減できます。Oracle BPEL Process Managerは、BPELビジネス・プロセスの作成、デプロイおよび管理を目的とした、包括的で使いやすいインフラストラクチャを提供します。

Oracle BPEL Process Managerの概要は、Oracle SOA Suiteの理解の主なコンポーネントに関する項にあるOracle Business Process Execution Language (BPEL) Process Managerを参照してください。

12.2 BPELパラメータのチューニング

この項には、パフォーマンスの改善に役立つまたは大いに役立つと思われるBPELパラメータのチューニングに関する推奨事項が含まれます。SOAコンポーネントで使用可能なその他のチューニング・パラメータについては、このマニュアルおよび『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のコンポーネント固有の章を参照してください。

BPELプロセスのサービス・コンポーネントとサービス・エンジンのモニター、構成および管理の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「BPELプロセスのサービス・コンポーネントとエンジンの管理」にリストされている各項を参照してください。また、BPEL選択アクティビティの使用方法は、Oracle SOA SuiteでのSOAアプリケーションの開発のBPELプロセス・サービス・コンポーネントの使用に関する項を参照してください。

12.2.1 BPELエンジンのチューニング

この項では、BPELエンジン・レベルでのパフォーマンス・チューニング・プロパティについて説明します。これらはEnterprise Manager Fusion Middleware Controlを使用して構成できます。Oracle Enterprise Manager Fusion Middleware Controlを使用したパラメータの構成およびモニターの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle SOA SuiteおよびOracle BPM Suiteの管理のスタート・ガイド」およびコンポーネント・プロパティ・ページからのシステムMBeanブラウザへのアクセスに関する項を参照してください。

12.2.1.1 BPELエンジンのパラメータのチューニング

表12-1に、BPELエンジンのパフォーマンスを改善するために調整できる重要なチューニング・パラメータを示します。

表12-1 重要なBPELエンジン・チューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

auditLevel

デフォルト: Inherit

audit_trail表へのデータベース挿入が頻繁であるためにパフォーマンスが低くなっています。

Off値を使用して、監査情報の格納を停止します。

auditLevelはSOAインフラストラクチャ・レベルで設定されていることに注意してください。このパラメータの検索およびチューニングの方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

このプロパティは、永続プロセスと一時プロセスの両方に対して監査証跡ロギング・レベルを設定します。

これをオフにすると、ビジネス・フローおよびペイロード・トラッキングの両方が無効になります。Oracle Enterprise ManagerコンソールでBPELプロセスの状態を表示できなくなります。

表12-2に、チューニングするとパフォーマンスが少し改善されるその他のBPELエンジン・パラメータを示します。ほとんどのユースケースで、デフォルト値は推奨値であることに注意してください。

表12-2 その他のBPELエンジン・チューニング・ノブ

パラメータ

説明

SyncMaxWaitTime

デフォルト: 45秒。

このパラメータの値を小さくしてパフォーマンスを改善できます。

SyncMaxWaitTimeプロパティには、プロセス結果レシーバが戻るまでに結果を待つ最大時間を設定します。このプロパティは同期の相互作用に必要であり、一時プロセスに適用できます。

Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザでこのプロパティを検索する方法の詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のトランザクション・タイムアウト値の指定方法を参照してください。

largedocumentthreshold

デフォルト: 10000 (100KB)

このパラメータの値を小さくしてパフォーマンスを改善できます。

このプロパティは、BPEL変数の最大サイズ(KB)を設定し、これを超えると、BPEL変数が他のインスタンス・スコープ・データとは異なる表に格納されるようになります。これは、永続プロセスと一時プロセスの両方に適用されます。

インスタンス処理を行う必要が生じるたびに、大きなXMLドキュメントの読込みおよび書出しが絶えず行われる場合は、パフォーマンスが低下することがあります。

Enterprise Manager Fusion Middleware Controlでこのパラメータを検索およびチューニングする方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

validateXML

デフォルト: False

パフォーマンスを改善するには、このパラメータをデフォルト値のFalseに設定する必要があります。

このプロパティによって、Oracle BPEL Process Managerは受信および送信XMLドキュメントを検証することによって、非スキーマ準拠のペイロード・データをインターセプトできるようになります。ただし、XMLペイロード検証はパフォーマンスを低下させる場合があります。

このパラメータはシステムMBeanブラウザで検索できます。Enterprise Manager Fusion Middleware Controlの「BPELサービス・エンジン・プロパティ」ページから「詳細BPEL構成プロパティ...」ボタンを使用して拡張BPELプロパティを検索する方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

InstanceKeyBlockSize

デフォルト: 10000キー

インスタンス・キー・ブロックのサイズをci_id_range表への更新の数よりも大きい値に増やして、パフォーマンスを改善できます。

InstanceKeyBlockSizeプロパティは、インスタンスIDの範囲サイズを制御します。Oracle BPEL Serverは、指定された値を使用して、インスタンス・キー(プロセス・インスタンスIDの範囲)をバッチ形式で作成します。このメモリー内IDの範囲が作成されると、次の範囲が更新されて、ci_id_range表に保存されます。

Enterprise Manager Fusion Middleware ControlでシステムMBeanブラウザを使用してこのパラメータを検索およびチューニングする方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

監査レベルしきい値

デフォルト: 10000

このパラメータの値を小さくしてパフォーマンスを改善できます。

このプロパティには、監査証跡詳細文字列の最大サイズ(KB)を設定し、これを超えると、監査証跡詳細文字列が監査証跡とは別に格納されるようになります。しきい値設定より大きな文字列は、audit_trail表ではなくaudit_details表に格納されます。変数が非常に大きい場合は、変数を監査証跡に記録すると、パフォーマンスに重大な影響を与える可能性があります。

Enterprise Manager Fusion Middleware Controlでこのパラメータを検索およびチューニングする方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

12.2.2 コンポジットでのBPELのチューニング

この項では、パフォーマンスを改善するために個々のコンポジットに対してチューニングできるいくつかのBPELプロパティを示します。コンポジット内に設定されるBPELプロパティは、BPELプロセスを含むコンポーネントの動作にのみ影響を与えます。各BPELプロセスは、コンポジットのコンポーネントとして作成できます。

BPELコンポジット・プロパティは、JDeveloperを使用してcomposite.xmlで変更するか、Oracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで変更できます。各プロパティの機能の詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発の「デプロイメント・ディスクリプタのプロパティ」を参照してください。

表12-3に示されているBPELのチューニングに関する考慮事項は、すべてのBPELデプロイメントには適用できない場合があります。必ず各自のユースケース・シナリオを検討して、これらの構成をデプロイメントで使用できるかどうかを判断してください。次に示すパラメータの検索および編集方法は、Oracle SOA SuiteでのSOAアプリケーションの開発のプロパティ・インスペクタのデプロイメント・ディスクリプタ・プロパティの定義方法に関する項を参照してください。

表12-3 コンポジット・チューニングでの重要なBPEL

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

OneWayDeliveryPolicy

デフォルト: async.persist

配信メッセージを永続化するためにリソースが使用されているため、パフォーマンスが低下しています。

値をasync.cacheに設定します。永続プロセス用に受信した配信メッセージは、インメモリー・キャッシュにのみ保存されます。

デフォルトでは、受信リクエストは配信サービス・データベース表dlv_messageに保存されます。

この設定には、メッセージの紛失やシステムの過負荷という高いリスクがあります。これはアダプタのスレッド・モデルも変更します。

監査ポリシー

デフォルト: すべてのアクティビティ

すべてのアクティビティが監査されているため、パフォーマンスが低下しています。

主なアクティビティのみを監査します。

レベルが低いアクティビティの監査証跡がなくなります。

inMemoryOptimization

デフォルト: False

completionPersistPolicyパラメータがBPELコンポーネント・レベルでアクティブ化されて、BPELサーバーがすべてまたは一部のインスタンスをデハイドレーションしているため、パフォーマンスが低下しています。

値をFalseに設定して、処理対象のプロセスが一時プロセスであり、デハイドレーションが必要ないことをOracle BPEL Serverに示します。

デハイドレーションを行わないということは、システムがクラッシュした場合にインスタンス内のアクティビティが失われることを意味します。

表12-4に、チューニングするとパフォーマンスが少し改善されるその他のBPELエンジン・パラメータを示しますが、ほとんどの場合にそのデフォルト値は推奨値です。各プロパティの機能の詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のpartnerLinkBindingデプロイメント・ディスクリプタのプロパティに関する項を参照してください。

表12-4 コンポジット・チューニング・ノブのその他のBPEL

パラメータ

説明

idempotent

デフォルト: True

idempotentアクティビティは、再試行できるアクティビティです。このパラメータの値をTrueにすると、アクティビティが失敗した直後にBPELサーバーがデハイドレーションを行うことを防止することによって、idempotentアクティビティが許可されます。

このパラメータは、BPELでの実行時にパートナ・リンクに構成されます。

validateXML

デフォルト: False

Falseは、システムがreceiveアクティビティ中にすべてのXMLメッセージを検証しないことを意味します。

このパラメータは、BPELでの実行時にパートナ・リンクに構成されます。

12.3 その他のチューニング戦略の使用

前述の項に示したパラメータをチューニングした後、パフォーマンスをさらに改善するために次の戦略の使用を検討できます。

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

- インスタンス・データ増大の影響を受ける表の識別

- コンポジット・インスタンスの表示中の頻繁なトランザクション・タイムアウトのトラブルシューティング

12.3.1 インスタンス・データ増大の影響を受ける表の識別

インスタンス・データは、Oracle BPEL Process Managerのスキーマ表の領域を占有します。監査やデハイドレーションによってデータが増大すると、データベースのパフォーマンスおよびスループットに大きな影響を与える可能性があります。

表12-5を使用して、インスタンス・データ増大によって影響を受ける可能性がある表を識別することができます。次のデータベース表のパフォーマンスをモニターする方法は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の領域使用量、ハードウェア・リソースおよびデータベース・パフォーマンスのモニタリングに関する項を参照してください。

表12-5 インスタンス・データ増大の影響を受けるOracle BPEL Process Managerの表

表の名前

表の説明

audit_trail

インスタンスの監査証跡を格納します。Oracle BPEL Controlに表示される監査証跡は、XMLドキュメントから作成されます。インスタンスが処理されると、各アクティビティがイベントをXMLとして監査証跡に書き込みます。

audit_details

APIを通じてログに記録される監査詳細を格納します。assignアクティビティなどは、デフォルトで、変数を監査詳細としてログに記録します。

監査詳細はサイズが大きいため、audit_trail表から分離されています。詳細のサイズがこのプロパティに指定した値より大きい場合、詳細はこの表に格納されます。それ以外の場合は、audit_trail表に格納されます。

cube_instance

プロセス・インスタンス・メタデータ(インスタンスの作成日、現在の状態、タイトル、プロセス識別子など)を格納します。

cube_scope

インスタンスのスコープ・データ(BPELフローで宣言されているすべての変数や、フロー全体のルーティング・ロジックを支援する内部オブジェクトなど)を格納します。

dlv_message

受信(呼出し)メッセージおよびコールバック・メッセージを受信時に格納します。この表には、メッセージのメタデータ(現在の状態、プロセス識別子、受信日など)のみが格納されます。

dlv_subscription

インスタンスの配信サブスクリプションを格納します。receiveアクティビティやonMessageアクティビティのように、インスタンスがパートナからのメッセージを待っているときは必ず、そのreceiveアクティビティに対するサブスクリプションが書き込まれます。

document_ci_ref

xml_document表に格納されているデータへのキューブ・インスタンスの参照を格納します。

document_dlv_msg_ref

xml_document表に格納されているdlv_messageドキュメントへの参照を格納します。

wftask

インスタンスに対して作成されたタスクを格納します。TaskManagerプロセスは、この表に現在の状態を保存します。

work_item

インスタンスによって作成されたアクティビティを格納します。BPELフローのすべてのアクティビティにwork_item表が存在します。この表には、アクティビティのメタデータ(現在の状態、ラベル、(waitアクティビティで使用される)有効期限)が格納されます。

xml_document

システム内のすべてのラージ・オブジェクト(dlv_messageドキュメントなど)を格納します。この表には、データがバイナリ・ラージ・オブジェクト(BLOB)として格納されます。ドキュメントとメタデータの記憶域を分けることで、ドキュメントのサイズに関係なく、メタデータを頻繁に変更できるようになります。

Headers_properties

ヘッダーおよびプロパティの情報を格納します。

パフォーマンス低下を引き起こしている表を特定したら、それらをパージできます。データベース増大の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の増大管理の課題の理解および戦略のテストに関する項を参照してください。

12.3.2 コンポジット・インスタンスの表示中の頻繁なトランザクション・タイムアウトのトラブルシューティング

Enterprise Managerからのコンポジット・インスタンスのフェッチ中にトランザクション・タイムアウトが発生する場合、FLOW_IDベースの索引をCUBE_INSTANCEスキーマ表に追加する必要がある場合があります。

指定したフローIDに関連付けられたすべてのコンポーネント・インスタンスを取得するEnterprise Managerの検索には、この索引が必要です。この索引は最新の12c (12.1.3)のインストールまたはアップグレードされた環境で失われることがあります。

複数の管理対象サーバーを含むクラスタ環境でこれを修正するには、次の手順を実行します。

1. 管理サーバーと管理対象サーバーが稼働中であれば停止します。

2. SQLを使用してSOAINFRAスキーマに接続します。

3. 次のコマンドを実行します。

CREATE INDEX CI_FLOW_ID ON CUBE_INSTANCE(FLOW_ID);

4. 管理および管理対象サーバーを再起動します。

13 Oracle Mediatorのチューニング

この章では、Oracle Mediatorをチューニングしてパフォーマンスを改善する方法について説明します。

内容は次のとおりです。

- 第13.1項「Oracle Mediatorについて」

- 第13.2項「Mediatorのパラメータのチューニング」

13.1 Oracle Mediatorについて

Mediatorは、Oracle SOA Suiteのコンポーネントであり、選択的ルーティング、トランスフォーメーション、検証などの仲介機能を備え、同期、非同期、イベントのパブリッシュ、イベントのサブスクリプションといった様々なメッセージ交換パターンに対応しています。Oracle Mediatorは、サービスおよびイベントの各種プロバイダとコンシューマを仲介するフレームワークを提供します。メディエータ・サービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーションと連携して動作します。

関連項目:
SOA Suiteの詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発を参照してください。
Oracle Mediatorの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle Mediatorのサービス・コンポーネントとエンジンの管理」を参照してください。

13.2 Mediatorのパラメータのチューニング

ほとんどのビジネス環境では、顧客データは、取引先、レガシー・アプリケーション、エンタープライズ・アプリケーション、データベース、カスタム・アプリケーションなど、様々なソースに点在しています。こうしたデータを効率的に統合するという課題は、Oracle Mediatorを使用することで解決できます。Oracle Mediatorは、同じデータの更新やその他の処理を共通して行うすべてのアプリケーションに対して、リアルタイムのデータ・アクセスを実現します。

注意:
Oracle Mediatorプロパティのチューニングを始める前に、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle Mediatorのサービス・コンポーネントとエンジンの管理」にあるOracle Mediatorに関する章を必ず読み、内容を理解しておいてください。

表13-1に、パフォーマンスのためにチューニングできるパラメータ値を示します。パフォーマンスを改善するためにMediatorをチューニングする必要があることはあまりないことに注意してください。

表13-1 重要なMediatorチューニング・ノブ

パラメータ

チューニングに関する推奨事項

DeferredMaxRowsRetrieved

デフォルト: 20行

1回の反復でDBから遅延メッセージ処理をより多く取得する場合は、デフォルト値を大きくします。

Mediatorではこのパラメータは必ずパラレル・ルーティング・ルールとともに使用されることに注意してください。

DeferredLockerThreadSleep

デフォルト: 2秒

遅延メッセージが合計メッセージのなかで占めている割合が小さい場合、デフォルト値を大きくして、遅延メッセージを取得するためのDBへのトリップ実行を少なくします。

一部のユースケース・シナリオでは、3600秒(60分)のアイドル時間を利用できます。

metricsLevel

デフォルト: enabled

DMSメトリック・データを収集する必要がない場合、このパラメータを無効にするとパフォーマンスを改善できます。

各パラメータの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「Oracle Mediatorのサービス・コンポーネントとエンジンの構成」を参照してください。

13.2.1 メッセージに対するリシーケンサの使用

リシーケンサは、関連性はあるが順序が正しくないメッセージのストリームを再配置して順序どおりに戻すために使用します。ランダムな順序で届く着信メッセージを順序付けし、ターゲット・サービスに正しい順序で送信します。

表13-2に、Mediatorのリシーケンサに対するチューニング可能なパラメータを示します。『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のOracle Mediatorサービス・エンジン・プロパティの構成に関する項で説明されているいずれかの方法を使用して、「メディエータ・サービス・エンジン・プロパティ」ページまたはシステムMBeanブラウザにアクセスすることによって、次のパラメータをチューニングできます。

表13-2 Mediatorのリシーケンサに対する重要なチューニング・ノブ

パラメータ

チューニングに関する推奨事項

ResequencerMaxGroupsLocked

デフォルト: 4行

1回の反復でデータベースからロックするリシーケンサ・グループを増やす場合は、デフォルト値を大きくします。

ResequencerLockerThreadSleep

デフォルト: 10秒

リシーケンサ・グループが合計グループおよびメッセージのなかで占めている割合が小さい場合、デフォルト値を大きくして、リシーケンサ・グループをロックするためのデータベースへのトリップ実行を少なくします。

DeleteMessageAfterComplete

デフォルト: True

正常実行後にメッセージを削除するため、値をTrueのままにします。負荷が高いユースケースの場合、このようにすると多くのデータベース領域が必要になります。

デフォルト値をFalseに変更すると、リシーケンスされたメッセージはリシーケンサ・データベースに保持されます。これによってリシーケンサ・データベース問合せが遅くなり、パフォーマンスが低下します。

Mediatorのリシーケンサの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のリシーケンスされた・メッセージの構成に関する項を参照してください。

14 Oracle Managed File Transferのチューニング

この章では、パフォーマンスおよびトラブルシューティングのためにManaged File Transfer (MFT)をチューニングする方法について説明します。

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

- Managed File Transferについて

- MFTパラメータのチューニング

14.1 Managed File Transferについて

Oracle Managed File Transfer (MFT)は、パフォーマンスが高く、標準ベースのエンドツーエンド管理対象ファイル・ゲートウェイです。これは、ファイル暗号化、スケジュール、埋込みFTPおよびsFTPサーバーを含む軽量のWebベース設計時コンソールを使用した設計、デプロイメントおよびファイル転送のモニタリングを特徴とします。

Managed File Transferの詳細は、『Oracle Managed File Transferの使用』のOracle Managed File Transferの理解に関する項を参照してください。

14.2 MFTパラメータのチューニング

この項では、パフォーマンスを最適化するパラメータについて説明します。次のトピックが含まれます:

- リモートFTP / SFTP/ FILEタイプのソースのチューニング

- MDSラベルの最小化

- マテリアライズド・ビューのリフレッシュ間隔の調整

表14-1に、MFTパフォーマンスの改善のためにチューニングが必要になると思われるノブを示します。MFTの問題のある領域を診断するには、『Oracle Managed File Transferの使用』のOracle Managed File Transferのモニタリングに関する項およびOracle Managed File Transferの管理に関する項を参照してください。

表14-1 重要なMFTチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

プロセッサ数

デフォルト: 各タイプのプロセッサごとに2個

JMSメッセージがメッセージ処理キューに蓄積されています。

メッセージが蓄積されているキューのプロセッサ数を増やします。

最適な値はメタデータおよび受信ペイロードによって異なります。DMSメトリックを使用して最適なプロセッサ数を計算できます。

DMSメトリックを有効にするには、MBeanプロパティのenablePerformanceMetricを追加します。後でメトリックを無効にするには、値をFalseに設定します。

プロセッサ数が増えると、同時処理に必要なシステム・リソースが増えます。

埋込みFTP/SFTPサーバーの最大同時リクエストおよび最大ログイン数の設定

デフォルト: 10

- 複数の接続リクエストが待機状態です

- 埋込みサーバー・ログ・ファイルに「ログイン・ユーザー数が多すぎるため、ユーザーは切断されます」というメッセージが表示されます。

同時リクエストの最大数および埋込みFTP/SFTPサーバーの最大ログイン数を大きくします。

パフォーマンスが直線的に拡張を続けるかぎり、数を増加できます。

埋込みサーバー・サービス(FTP/SFTP)が使用されていない場合は、この設定を無効にします。

数が増えると、同時処理に必要なシステム・リソースが増えます。

LDAPの最大プール

デフォルト: 10

- LDAPへの同時接続数が常に上限に達しています。

数を大きくします。

LDAPは、WebLogicサーバーにデプロイされているすべてのアプリケーションの共有リソースであるため、LDAP接続をモニターしてこの値を適切に調節する必要があります。

数が増えると、必要なシステム・リソースが増えます。

MFTDataSourceへの最大接続数

デフォルト: 50

- データ・ソースへの同時接続の数が、常に上限に達しています

パフォーマンスが直線的に拡張を続けるかぎり、接続数を増やします。

最適な値は、プロセッサ数、リスニング・ソース・スレッド・モデル、および埋込みサーバーの最大同時リクエスト設定に基づいて決定できます。

数が増えると、必要なシステム・リソースが増えます。

チェックサムの生成設定

デフォルト: Enabled

- 全体的なMFTメッセージ処理が遅くなっています

MFTから配信されたペイロードのチェックサム検証が不要な場合は、このパラメータを無効にします。

チェックサムの生成は時間がかかる操作です。

定期的なパージ

デフォルト: Disabled

- ディスク領域が上限に近づいています

- MFTの表によって使用されている表領域が、割り当てられた表領域の上限に達しています

パージを実行してディスク領域または表領域を解放します。

履歴情報/データは破棄されます。

表14-2に、通常はチューニングする必要がないチューニング・プロパティを示します。これらのパラメータを調べて値が変更されたかどうかを確認できるように、デフォルト値を保持することをお薦めします。

表14-2 重要度が低いまたは中間のMFTパラメータ

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

ブロードキャスト・ユースケースの処理関数/コールアウト使用の推奨事項

デフォルト: ターゲット・レベル

関連付けられた処理関数/コールアウトがターゲットごとに実行されますが、これはパフォーマンスを低下させます。

ブロードキャスト・ユースケースの場合、処理関数/コールアウトを可能なかぎりターゲット・レベルではなくソース・レベルで関連付けます。

なし。

サブフォルダ数のMBean設定

デフォルト: 256

ファイルを格納するための多数のサブフォルダにおけるMFT切替えによって、ディスク・パフォーマンスの低下が発生しています。

サブフォルダ数を少なくします。

サブフォルダの数を減らすと、各サブフォルダに格納されるファイルの数が増加します。着信ファイルのボリュームが大きい場合、1つのサブフォルダ内のファイル数が多いとパフォーマンスが低下します。

インライン・ペイロードのストア設定

デフォルト: ファイル・システム

ディスクからWebサービス・ソースのインライン・ペイロードへのアクセスの時間がかかりすぎているため、パフォーマンスが低下しています。

インライン・ペイロードを、ファイル・システムではなくデータベースに格納します。

インライン・ペイロードはデータベースに格納されるため、MFTによって使用される表のサイズが大きくなります。

ターゲット・レベルでの「変更したファイルを常に保存」設定

デフォルト: False

監査目的でこの設定をTrueに変更すると、ディスク領域の使用量が増加します。

デフォルト値のFalseでは、ディスク領域使用量が減少します。

監査情報が使用できなくなります。

ターゲットに関連付けられた前処理がある場合、ターゲット・レベルの再送信は機能しないことに注意してください。

minFileSizeForProgressMonitor

デフォルト: 10 MB

バイト転送に関する更新が頻繁です。

最小ファイル・サイズを指定して、大きいファイルに対してのみ転送の進行状況画面が表示されるようにします。

指定した最小よりも小さいファイルの場合は、ファイル転送進行状況が表示されません。

progressMonitorTimeToCommit MBean

デフォルト: 4秒

バイト転送に関する更新が頻繁です。

最小ファイル・サイズを指定して、大きいファイルに対してのみ転送の進行状況画面が表示されるようにします。

進行中のファイル転送に対して転送されたバイトに関するデータベース更新が遅くなります。

MaxMdsSessionCacheCount

デフォルト: 100

MDSキャッシュ・メモリー・フットプリントによってメモリー不足例外が発生しました。

この値を小さくします。

キャッシュからのデータ・アクセスの方が早いため、これを小さくすると、全体的なMFTメッセージ処理のパフォーマンスが低下します。

14.2.1 リモートFTP / SFTP/ FILEタイプのソースのチューニング

ポーリング間隔が過ぎた後でもMFTでファイルを選択できない場合、リモートFTP/SFTP/FILEタイプのソースをチューニングする必要があります。MFTは、これらのすべてのソース・タイプの下でJCAアダプタを使用します。テクノロジ・アダプタの理解のOracle JCAアダプタ・フレームワークのパフォーマンスとチューニングに関する項に示されているSOAアダプタに関する推奨事項を参照してください。

プロパティの一部を表14-3に示します。

表14-3 リモートFTP/SFTP/FILEタイプのソースのチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

ThreadCount

デフォルト: -1

グローバル・プール内のスレッド数が不足しているため、優先度が高いエンドポイントのファイル・ダウンロードが遅くなっています。

0よりも大きい値を指定します。これによって、ファイルをダウンロードするために指定したエンド・ポイントに専用のスレッド・プールが作成されます。

値が大きすぎる場合、1つのエンド・ポイントに多数のスレッドが割り当てられ、全体的なパフォーマンスが低下することがあります。

SingleThreaded

デフォルト: False

まれに、グローバル・スレッドを使用したくない場合や、優先度が低いエンド・ポイントに別のスレッド・プールを割り当てたくない場合があります。

値をTrueに設定します。

trueに設定すると、新しいファイルのポーリングおよびダウンロード用のスレッドが単一になるため、エンド・ポイントからのファイルのダウンロードが遅延する場合があります。

14.2.2 MDSラベルの最小化

アーティファクトのデプロイメントによって、新しいMDSラベルが作成されます。MDSラベルが増えると、メモリー・フットプリントおよびメタデータを取得するための時間が増えます。

通常、ユーザーはデプロイメントに関して次のベスト・プラクティスに従う必要があります。

- 頻繁なデプロイメントおよびメタデータ作成を最小化します。

- 一括デプロイメントのWLSTコマンドを使用します。

- メタデータへのすべての変更を行い、それらを一度にデプロイします。

14.2.3 マテリアライズド・ビューのリフレッシュ間隔の調整

マテリアライズド・ビューは1分ごとにリフレッシュされます。データベース・サーバーの負荷が高い場合、リフレッシュ頻度を1分よりも大きくします。

MFTコンソールのマテリアライズド・ビューからデータを表示できます。データベース・サーバーで高い負荷が検出される場合、次のコマンドを使用してこのリフレッシュ頻度を調整できます。

ALTER MATERIALIZED VIEW <<MV_NAME>> REFRESH NEXT <<REFRESH_INTERVAL>>;

MFTで使用されるマテリアライズド・ビューは次のとおりです。

- MV_MFT_PAYLOAD_INFO

- MV_MFT_SOURCE_INFO

- MV_MFT_SOURCE_MESSAGE

- MV_MFT_TARGET_INFO

- MV_MFT_TRANSFER

- MV_MFT_TRANSFER_COUNT_INFO

15 Oracle Business Rulesのチューニング

このマニュアルでは、Oracle Business Rulesのパフォーマンスをチューニングする方法について説明します。Oracle Business Rulesテクノロジは、ビジネス・ルールの自動化、およびJavaコードやBPELプロセスといった手続き型ロジックからのビジネス・ルールの抽出を可能にします。

この章には次の項が含まれます:

- 第15.1項「Oracle Business Rulesについて」

- 第15.2項「Oracle Business Rulesのチューニング」

15.1 Oracle Business Rulesについて

Oracle Business Rulesには、簡単に使用できるオーサリング環境およびパフォーマンスが高く推論可能なルール・エンジンが備えられています。Oracle Business Rulesは、Oracle Fusion Middlewareスタックの一部であり、多くのOracle製品(ミドルウェアとアプリケーションの両方を含む)のコア・コンポーネントとなります。

詳細は、Oracle Business Rulesユーザーズ・ガイドおよびOracle SOA SuiteでのSOAアプリケーションの開発のOracle Business Rulesのスタート・ガイドを参照してください。

15.2 Oracle Business Rulesのチューニング

この項では、パフォーマンスを最適化するチューニングの推奨戦略について説明します。

ほとんどの場合、ルールを記述する際にパフォーマンスに注意を払う必要はありません。ただし、どのテクノロジにも言えることですが、パフォーマンスを最大化するのに役立つヒントやコツがありますので、必要に応じて利用してください。考慮事項の大半は、データ・モデルの初期構成に関するものです。

表15-1 重要なビジネス・ルール・チューニング戦略

戦略

説明

推奨事項

Java Beansの使用

ルール・エンジンの効率が最も高いのは、推論するファクトがJava Beans (またはRLクラス)であり、関連付けられたテストにBeanプロパティが含まれている場合です。

Beanでは、各Beanプロパティのgetメソッドおよびsetメソッド(setが使用可能な場合)を公開する必要があります。

Java Beansでアプリケーション・データを直接利用できない場合は、そのデータをフラット化して、ファクトとしてアサートされる(さらにルールで使用される)Java Beansのコレクションにします。

複数の逆参照を使用するかわりに子ファクトをアサート

Account.Contact.Addressのような式には、オブジェクトの逆参照が複数含まれています。ルール条件では、これは単独の逆参照を含む式ほど効率的ではありません。

ベスト・プラクティスとして、ファクト・タイプは可能なかぎりフラット化してください。

ファクト・タイプに階層構造がある場合、オブジェクト階層をアサートするためにassertXPathまたは他の方法を使用することを検討してください。

ルール条件における副作用の回避

ルール条件でテストが評価される回数は、手続き型プログラムでの回数よりも多くなるか、または少なくなる場合があります。

ルール条件では、値や状態の変更といった副作用を持つメソッドまたは関数を使用しないでください。

メソッドまたは関数に副作用がある場合、その副作用が発生する回数は予測できません。

ルール条件における高コストの操作の回避

コストの高い操作とは、I/O(ディスクまたはネットワーク)や大量の計算処理を伴う操作です。このような操作は、ルール・エンジンの外部で行います。

ルール条件では、コストの高い操作を避けてください。一般に、I/OやDBMSにルール・エンジンから直接アクセスするのは避けることを検討してください。

コストの高いその他の操作や計算については、計算処理を実行し、その結果をJavaファクトまたはRLファクトとしてアサートすることを検討してください。これらのファクトは、コストの高い操作ではなく、ルール条件で使用されます。

パターンの順序の検討

ルール・パターンの順序を変更すると、時間またはメモリー使用量、あるいはその両方の点でルール評価のパフォーマンスが向上します。システムに最適な順序を見つけるには実験が必要です。

あるファクトがルール評価中に変更されない(頻繁には変更されない)と予想される場合は、ファクト句を、変更が予想される率が少ないものから多いものへと順に配置します。

あるファクト句(そのファクトのみを伴うテストを含む)の一致するファクトが、ルール条件内の他のファクト句より少ないと予想される場合は、ファクト句を最も限定的な(一致するファクトが最も少ない)ものから最も限定的でないものへと順に配置します。

ルール条件におけるテストの順序の検討

適切な順序にすると、ルール条件を満たさないファクトに必要な計算処理の量を減らすことができます。

ルール条件内のテストは、より限定的なテストが限定的でないテストより前になるように配置される必要があります。

限定性の度合いが不明な場合や、一連のテストの限定性が同程度になると予想される場合は、単純なテストをコストの高いテストより前に配置してください。

assertXPathメソッドは、1つのコールで階層全体をアサートし、さらにXLinkファクトをアサートして子ファクトが親ファクトにリンクできるようにします。便利ですが、パフォーマンスに影響する場合があります。

assertXPathのパフォーマンスを改善するには、Rule Authorの「ディクショナリ・プロパティ」ページで、「パフォーマンスのために改善されたassertXPathサポートを有効化」チェック・ボックスを選択します。この機能を利用するには、次の条件を満たす必要があります。

- XPath式//*のみを使用してassertXPathを呼び出すこと。他のXPath式を使用すると、RLIllegalArgumentExceptionが発生します。

- XLinkファクトはアサートされないため、XLinkファクトをルール条件で使用しないこと。

子ファクトに対するXLinkファクトが不要であり、2、3のレベルをファクトとしてアサートするだけでよい場合は、関連するファクト・タイプのSupports Xpathをオフにし、関数を使用してカスタム・アサートを実行することをお薦めします。次の例では、assertXPathを使用するかわりに、関数を使用してExpenseReportおよびExpenseLineItemsをアサートしています。

function assertAllObjectsFromList(java.util.List objList)
{
java.util.Iterator iter = objList.iterator();
while (iter.hasNext())
{
assert(iter.next());
}
}

function assertExpenseReport (demo.ExpenseReport expenseReport)
{
assert(expenseReport);
assertAllObjectsFromList(expenseReport.getExpenseLineItem());
}

16 Oracle Business Process Managementのチューニング

Oracle Business Process Management Suiteでは、設計時および実装からランタイムおよびアプリケーション管理まで、アプリケーション開発ライフサイクルの全ステージをシームレスに統合します。

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

- 第16.1項「Oracle Business Process Managementについて」

- 第16.2項「Business Process Managementのパラメータのチューニング」

- 第16.3項「その他のチューニング戦略の使用」

16.1 Oracle Business Process Managementについて

Oracle Business Process Management Suiteは、ビジネス・プロセスを中心にしたビジネス・アプリケーションを開発、管理および使用するための統合環境を提供します。Oracle Business Process Managementは、Oracle SOA Suite上に存在し、統合の実現にBusiness Rules、Human WorkflowおよびOracle Adapter Frameworkを含む多くの同じ製品コンポーネントを共有します。

Oracle Business Process Managementの使用の詳細は、『Oracle Fusion Middleware Oracle Business Process Managementユーザーズ・ガイド』を参照してください。

他のOracle Fusion MiddlewareコンポーネントによるOracle Business Process Managementのチューニングの詳細は、第2章「主なパフォーマンス分野」を参照してください。

16.2 Business Process Managementのパラメータのチューニング

この項では、主な目的がパフォーマンスの最適化であるときにチューニングする必要があるパラメータについて説明します。これらのパラメータは、BPMNプロパティのSOA管理を介してEnterprise Managerでチューニングできます。

Oracle Business Process Managementエンジンのパフォーマンスをチューニングするために、リソースの需要を減らして待機時間を減らし、システム・キャパシティを増やしてスケーラビリティを大きくすることができます。

リソースの需要を減らすには、表16-1に示すパラメータをチューニングできます。

表16-1 リソースの需要を減らすために重要なBusiness Process Managementのチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

largedocumentthreshold

デフォルト: 10000 (100KB)

大きいBPMNデータ・オブジェクトを格納しているため、インスタンスの処理が遅くなっています。

このパラメータの最大サイズ(KB)を小さくして、BPMNデータ・オブジェクトのサイズを制限します。この制限を超過すると、他のインスタンス・スコープ・データとは別の場所にデータが格納されます。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

オーバーフロー・データは、外部の追加専用表に格納されます。これによって、データベース全体のサイズが増加し、データベースからのインスタンスのロード時にワークロード全体が増える場合があります。

auditLevel

デフォルト: インフラストラクチャからのInherit

audit_trail表へのデータベース挿入が頻繁に行われています。これらはプロセスによってログに記録されている監査イベントによって引き起こされています。

監査を減らすか無効にします。次のいずれかの設定に切り替えることができます。

- Offは、イベントまたは監査イベントのログ記録を行いません

- Minimalは、イベントのみをログに記録します。

- Errorは、重大な問題のみをログに記録します

AuditKeyExtentsのサイズを拡張することも検討できます。

後で問題の診断に使用できる詳細なエラー・レポートがなくなります。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。

モニタリングのために監査証跡を使用する方法の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のBPMNプロセス・サービス・コンポーネントおよびエンジンのモニタリングに関する項を参照してください。

完了したインスタンスをビジネス要件で許可されたとおりにパージして、フレックス・フィールドの索引追加を試行することもできます。

システム・キャパシティの増加は、パフォーマンス・テストの結果の分析に基づいてのみ行う必要があります。テストでスケールにおける制約が示されないかぎり、調整は行わないでください。システム・キャパシティを増やすために、表16-2に示されているパラメータをチューニングできます。

表16-2 システム・キャパシティを増やすために重要なBusiness Process Managementのチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

DispatcherEngineThreads

デフォルト: 2スレッド

システム・ディスパッチャ・メッセージとは、通常はサーバーで迅速に処理される一般的なクリーン・アップ・タスク(ステートフル・メッセージBeanを元のプールへ解放するなど)です。一般に、実行時に生成される数のシステム・ディスパッチャ・メッセージは、ごく少数のスレッドで処理できます。次のいずれかの問題がある場合は、このパラメータのチューニングが必要なことがあります。

スレッドが不足しています。CPU利用率が低いままです。

または

スレッドが多すぎます。コンテキスト切替えによってCPU使用率が上昇しますが、スループットは増加しません。

スレッド・プール使用率に基づいてそれぞれのワークロードのスレッド・プール・サイズを増やします。

リクエストおよび追加のCPUキャパシティのバックログがある場合、スレッド数を増やすことを検討してください。

スレッド・プールのサイズを増やすと、CPU利用率およびガベージ・コレクションが増えます。ただし、同じプラットフォームを共有する他のアプリケーションがあり、追加のCPUキャパシティにアクセスすることが予想される場合は、これによって競合が発生する可能性があります。

DispatcherInvokeThreads

デフォルト:20スレッド

呼出しディスパッチ・メッセージは、受信したペイロードごとに生成されるもので、新規インスタンスのインスタンス化を目的としています。次のいずれかの問題がある場合は、このパラメータのチューニングが必要なことがあります。

スレッドはビジーですが、CPU利用率が低いままです。

または

スレッドが多すぎます。コンテキスト切替えによってCPU使用率が上昇しますが、スループットは増加しません。

スレッド・プール使用率に基づいてそれぞれのワークロードのスレッド・プール・サイズを増やします。

リクエストおよび追加のCPUキャパシティのバックログがある場合、スレッド数を増やすことを検討してください。

スレッド・プールのサイズを増やすと、CPU利用率が増えます。ただし、同じプラットフォームを共有する他のアプリケーションがあり、追加のCPUキャパシティにアクセスすることが予想される場合は、これによって競合が発生する可能性があります。

接続プールのサイズを増やして、接続の使用の最適化を試行することもできます。

16.3 その他のチューニング戦略の使用

前述の項に示したパラメータをチューニングした後、パフォーマンスをさらに改善するために次の戦略の使用を検討してください。

16.3.1 Oracleワークスペース・アプリケーションのチューニング

データベース・パフォーマンスおよびセッション状態の管理は、パフォーマンスを改善する主要要因です。効率的なデータベース・チューニングおよびHTTPセッション・タイムアウトの構成が重要です。

アプリケーション設計は次に重要な要因であり、タスク・フォーム上のコンテキスト・データをレンダリングするために使用される追加のデータ・コントロールがある場合は特に重要です。そのような場合、それらのデータ・コントロールからのデータ・アクセスを最適化し、可能な場合は、追加データが必要でないかぎり、その取得を延期することが重要です。ADFのチューニングの詳細は、第9.2.1項「Oracle ADF Facesの構成およびプロファイリング」を参照してください。

次のパラメータは、OracleBPMWorkspace Webアプリケーションのweb.xmlディスクリプタで変更できます。変更したら、再デプロイする必要があります。

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

HTTPセッション・タイムアウト
デフォルト: 15分

システムをアクティブに使用していない可能性があるユーザーに対して、メモリーが割り当てられています。

リソース使用量の管理を改善するために、セッション・タイムアウト値(分)を小さくして、予想されるユーザー体験を保持する最小の値にします。これによってシステムは、未使用セッションに関連付けられているリソースをすぐに解放できます。
このパラメータは、web.xmlファイルで編集されます。次に示すのは、web.xmlのサンプル・スニペットです。

<session-config>
<session-timeout>
5
</session-timeout>
</session-config>

タイムアウト値が小さいとき、時間切れになる場合はユーザーが頻繁にログインする必要があることを意味します。セッション・データが失われる可能性もあります。

ADFクライアント状態トークン
デフォルト: 15

デフォルト値では、メモリーを消費しすぎる場合があります。

メモリー・フットプリントを最小化するために値を3に減らします。
この設定では、ユーザーが情報を失わずにブラウザの「戻る」ボタンで移動可能なページの数を制御できます。CPUおよびメモリーの使用率を下げるには、web.xmlファイルで値を小さくします。

次に示すのは、web.xmlのサンプル・スニペットです。

<context-param>
<param-name>
org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS
</param-name>
<param-value>
3
</param-value>
</context-param>

ユーザーが「戻る」ボタンを3回以上クリックした場合、そのページのセッション・データは格納されません。
値が小さすぎる場合、ユーザーが「戻る」ボタンを使用するとエラーが表示されます。

Compress_View_Stateトークン
デフォルト: True

待機時間が遅い/大きいネットワークのパフォーマンスが低下しています。

圧縮を有効に保つデフォルトを保持します。
この設定は、ページ状態を圧縮するかどうかを制御します。圧縮により、セッション・オブジェクトのページ状態で使用されるメモリーを大幅に削減します。

次に示すのは、web.xmlのスニペットです。

<param-name>org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE</param-name>
<param-value>true</param-value>

表示状態の圧縮および解凍に追加のCPUコストがかかります。

DISABLE_CONTENT_COMPRESSION
デフォルト: False

ページの初期ロードが遅くなっています。

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

<param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name>
<param-value>false</param-value>

なし。

16.3.2 プロセス測定

Process Analyticsは測定イベントを使用して、プロセスをサンプリングし、登録されたコンシューマに測定を公開します。12c (12.1.3)では、これらの測定は、BPM Enterprise Managerの分析構成MBeanでDisableAnalyticsパラメータをFalseに設定することによって有効にできます。

12cでサポートされている測定の2つのコンシューマは、BAM 11gのMonitor ExpressおよびBAM 12cのProcess Metricsです。それらは、AnalyticsConfig MBeanのDisableProcessMetricsおよびDisableMonitorExpress属性を使用して有効または無効にすることができます。

注意:
有益なデータのみが公開されます。プロセス設計では、どのデータ(ディメンション、メジャー、カウンタ)をどの時点で公開するかを指定します。有益でないデータが生成される場合、不要な負荷がシステムに加わっている可能性があります。

測定イベントは、JMSトピックのMeasurementTopicで公開され、登録されたアクションMDBで消費されます。測定するためにJMSをチューニングするには、大規模な環境で必要に応じて表16-3に示されたパラメータを変更することを検討してください。

表16-3 BPMの重要なJMSリソース・チューニング

JMSリソース

問題点

チューニングに関する推奨事項

トレードオフ

dist_MeasurementTopic_auto

デフォルト: Forwarding Policy Replicated

クラスタ・インストール内の分散測定トピックは、デフォルトのFORWARDING POLICY REPLICATEDによって構成されていますが、これはBPM分析の最善のパフォーマンス・オプションではありません。

このパラメータの転送ポリシーをPARTITIONEDに変更します。

このパラメータはWebLogicコンソールで変更できます。次のオプション: 「JMSモジュール」→「BPMJMSModule」→「dist_MeasurementTopic_auto」のフロント・ページからこれを検索できます。変更を有効にするには、すべてのSOA BPMクラスタ・ノードを再起動する必要があります。

Partitionedポリシーの分散トピックは、一般的にFORWARDING POLICY REPLICATEDよりもパフォーマンスが優れています。

分散トピックと他のトピック・タイプの詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』のサポートされるトピック・タイプに関する項を参照してください。

パーティション化およびレプリケート転送ポリシーの詳細は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。

MeasurementTopicConnectionFactory

デフォルト: Send Timeout 200000

ボリュームの大きい環境で、メッセージ・プロデューサから頻繁にリソース割当て例外を受信します。

詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の接続ファクトリでの送信タイムアウトの定義に関する項を参照してください。

ボリュームの大きい環境では、このパラメータの送信タイムアウトを240000に増やします。

この数値は最大の時間(ミリ秒)を表します。

このパラメータはWebLogicコンソールで変更できます。次のオプション: 「JMSモジュール」→「BPMJMSModule」→「MeasurementTopicConnectioNFactory」→「デフォルト配信」のフロント・ページからこれを検索できます。

メモリーおよびリソースを消費するメッセージ・バックログを作成する場合があります。

MeasurementQuota

デフォルト: Message Maximum 1000000およびBytes Maximum 800000000

測定メッセージを公開できず、javax.jms.ResourceAllocationExceptionをスローして失敗します。

このパラメータの「最大メッセージ」および「最大バイト」を、残りのアプリケーションの負荷を考慮に入れて使用可能なシステム・メモリーの量と等しく設定します。

MeasurementQuota属性はWebLogicコンソールで変更できます。次のオプション: 「JMSモジュール」→「BPMJMSModule」→「MeasurementQuota」のフロント・ページからこれを検索できます。

この値を増やすと、さらに多くのメモリーを消費します。コンシューマにプッシュされるメッセージの集計サイズが現在のプロトコルの最大メッセージ・サイズよりも大きい場合は、メッセージ配信がまだ失敗することがあります。

測定割当て容量の詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のサイズの大きなメッセージのチューニングに関する項を参照してください。

BPMJMSServer

デフォルト: MessageBufferサイズ 100000

JMSサーバーがメッセージ本文を頻繁にディスクに書き込んでいます。

指定したBPMJMSServerのメッセージ・バッファ・サイズを増やします。これによって

BPMJMSServerは、ページング・ファイルおよびJMSファイル・ストアを使用します。

このパラメータはWebLogicコンソールで変更できます。次のオプション: JMS Servers_auto_numberのフロント・ページからこれを検索できます。

JMSサーバーがさらに多くのメモリーを使用します。

17 Oracle Human Workflowのチューニング

この章では、Oracle Human Workflowをチューニングして最適なパフォーマンスを得る方法について説明します。

Oracle Human Workflowは、次の分野のチューニングが可能です。

- 第17.1項「Oracle Human Workflowについて」

- 第17.2項「ヒューマン・ワークフローのチューニング」

- 第17.3項「その他のチューニング戦略の使用」

17.1 Oracle Human Workflowについて

Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャ内で稼働するサービス・エンジンです。これを使用すると、対話型の人的プロセスを実行できます。ヒューマン・ワークフローは、プロセスの内部または外部で行われる承認処理、却下処理、再割当て処理といった人間のやり取りに対応しています。Human Workflowサービスは、ビジネス・プロセスと人間とのやり取りの様々な側面を処理する多くのサービスからなります。

詳細は、Oracle SOA SuiteでのSOAアプリケーションの開発のヒューマン・ワークフロー・サービス・コンポーネントの使用に関する項を参照してください。

Oracle Human WorkflowのWebサイト(http://www.oracle.com/technology/products/soa/hw/index.html)も参照してください。

17.2 ヒューマン・ワークフローのチューニング

この項では、タスクフローを最適化する方法について説明します。次の提案はすべて、API使用に適用できます。

表17-1 重要なヒューマン・ワークフロー・チューニング戦略

名前

説明

推奨事項

クライアント側のレスポンス時間の最小化

ワークフロー・クライアント・アプリケーションが対話型の場合、クライアント側の最適なレスポンス時間を維持することが重要です。

レスポンス時間に影響を与える要素としては、サービス・コールのパフォーマンスの影響、リクエストに該当するタスク・セットを特定するための問合せ時間、該当タスクごとに取得される追加情報の量などがあります。

パフォーマンス・メトリックを確認してレスポンス時間を改善する方法を決定してください。

適切なワークフロー・サービス・クライアントの選択

リモート・クライアントは、ほとんどの場合、パフォーマンスの点で最善の選択肢です。クライアントがワークフロー・サービスと同じJVMで稼働している場合(soa-infraアプリケーション)、APIコールはリモート・メソッド呼出し(RMI)の必要がないように最適化されます。クライアントが別のJVMに存在する場合は、RMIが使用されます。このとき、APIメソッド間でデータのシリアライズおよびデシリアライズが行われるため、パフォーマンスに影響が出ることがあります。

SOAPクライアントは、標準化(Webサービスに基づく)について優先されます。リモート・クライアントで使用されるリモート・メソッド呼出し(RMI)と比べると、追加のパフォーマンスに関する考慮事項があります。Webサービス・テクノロジによって追加の処理が行われるため、XML間でAPIメソッド引数の整列化および非整列化が発生します。

クライアント・アプリケーションがJava EEテクノロジをベースとしている場合は、ユースケース・シナリオを基に、使用するクライアントを検討してください。

クライアント・アプリケーションが.Netテクノロジをベースとしている場合は、SOAPワークフロー・サービス以外は使用できないことに注意してください。

厳密なフィルタを使用した該当タスクの絞込み

タスク・リストを取得する際に、データベース・レベルで最大限のフィルタ処理を行えるよう、問合せをできるだけ厳密なものにする必要があります。

レスポンス時間を改善するために正しいフィルタを使用してください。

該当タスクのサブセットの取得(ページング)

問合せAPIには、ユーザーに返される該当行の数および開始行を制御するページング・パラメータが用意されています。

返されるレコードの数を制限できる値へのstartRowおよびendRowパラメータを小さくします。これによって問合せ時間、アプリケーション処理時間、およびクライアントに返されるデータの量が小さくなります。

該当タスクに必要な情報のみのフェッチ

通常は、タスク・リストを表示するためにペイロード・フィールドの一部が必要になるだけです。

queryTaskサービスを使用する際は、リスト内のタスクごとに取得するオプション情報の量を減らすことを検討してください。

まれに、ペイロード全体が必要になることもありますが、その場合はペイロード情報をリクエストできます。

返される問合せ列の数の削減

queryTaskサービスを使用する際は、問合せ列の数を減らして、SQLの実行時間を短縮することを検討してください。

索引付けされた列である可能性が高いため、一般的な列を使用するよう努めてください。これによって、SQLの実行が早くなります。

集計APIを使用したタスク統計のチャート化

タスク情報を要約したチャートや統計を表示することが必要になる場合があります。

問合せAPIを使用してすべてのタスクをフェッチし、クライアント・レイヤーで統計を計算するのではなく、新しい集計APIを使用してデータベース・レベルで統計を計算することを検討してください。

カウントAPIメソッドを使用したタスク数のカウント

特定の条件に一致するタスクの数をカウントするだけでよい場合があります。

countTasks APIメソッドをコールすると、一致するタスクの数のみが返されます。

フレックスフィールドの索引のオンデマンド作成

ワークフロー・スキーマ表WFTASKには、フレックスフィールド属性列がいくつか含まれています。これらを使用すると、ワークフロー・スキーマにタスク・ペイロード値を格納できます。列の数が多く、列の使用はオプションであるため、インストール済のスキーマにはこれらの列の索引は含まれていません。

特定のマップ済フレックスフィールド列が問合せの述語で頻繁に使用される場合は、これらの列に索引を作成してください。

doesTaskExistメソッドの使用

特定の問合せ条件に一致するタスクが存在するかどうかを確認することが必要になる場合があります。

デフォルトのcountTasksではなく、doesTaskExistを使用することを検討してください。

doesTaskExistメソッドは、指定された条件に一致する行が存在するかどうかを確認するだけの、最適化された問合せを実行します。このメソッドを使用すれば、countTasksをコールする場合より優れた結果が得られる可能性があります。

17.3 その他のチューニング戦略の使用

前述の項に示したパラメータをチューニングした後、パフォーマンスをさらに改善するために次の戦略の使用を検討できます。

17.3.1 サーバーのパフォーマンスの向上

負荷の高い状況でのシステムのスケーラビリティは、サーバーのパフォーマンスによって事実上決まります。第17.2項「ヒューマン・ワークフローのチューニング」のクライアント・タスクのレスポンス時間を最小化する戦略では、適切な量の情報をフェッチすること、および問合せに伴うパフォーマンスへの影響を軽減することによってクライアント側のレスポンス時間を最小化する手法をいくつか取り上げています。これらの手法には、データベースおよびサービス・ロジックがサーバー側のパフォーマンスに与える影響を軽減し、サーバーのパフォーマンスを改善する効果もあります。その他、次のような構成変更を行うとサーバーのパフォーマンスが向上します。

表17-2 重要なサーバー・パフォーマンス・チューニング戦略

名前

説明

推奨事項

完了したインスタンスの定期的なアーカイブ

システムのデータベース・スケーラビリティは、システム内のデータ量によって大きく変わります。ビジネス・プロセスおよびワークフローは本来一時的なものであるため、処理が終われば、頻繁に問い合せられることはありません。

アーカイブ手法を使用して、完了したインスタンスを別のシステムへ定期的に移動し、そこで履歴データの問合せに役立てることを検討してください。アーカイブを行う際には、孤立したタスク・インスタンスが発生しないよう注意する必要があります。

適切なワークフロー・コールバック機能の選択

ワークフロー・コールバック機能を使用すると、割当てやタスク完了といった重要なワークフロー・イベントの後、外部システムに対して問合せや更新を行うことができます。

各ワークフロー・イベントの後ではなく、タスクの完了後に外部システムを更新するための十分なリソースがあることを確認してください。

コールバックが避けられない場合は、BPELコールバックではなくJavaコールバックを使用することを検討してください。Javaコールバックでは、コールバック・メソッドが同じスレッド内で実行されるため、BPELコールバックで発生するようなパフォーマンスへの影響は生じません。

通知がパフォーマンスに与える影響の最小化

通知は、実行すべきタスクがあることをユーザーに知らせるのに便利です。ほとんどの承認が電子メール経由で行われる環境では、アクション可能な通知が特に有効です。この場合、ワークリストの使用状況の点ではそれほど負荷がかかっていないとも言えます。

ワークフロー・イベントごとに通知を送信するかわりに、通知を最小限に抑えて、タスクが割り当てられたときのみユーザーに知らせるようにしてください。

また、通知のセキュリティを確保し、タスクの内容そのものではなく、タスクへのリンクのみを通知に含めて送信することを検討してください。

クラスタ・ノードのデプロイ

ワークフロー・インスタンスおよび状態情報はすべて、デハイドレーション・データベースに格納されます。ワークフロー・サービスはステートレスです。つまり、ノードのクラスタ上で複数のワークフロー・サービスを同時に使用できます。

パフォーマンスの重要性が高く、スケーラビリティに優れたシステムが必要な場合は、クラスタ環境を使用してワークフローをサポートすることが可能です。

17.3.2 ワークフロー完了の迅速化

ワークフローの完了に要する時間は、ワークフローに指定されたルーティング・タイプによって異なります。ワークフロー機能には、ワークフローの完了に要する時間を短縮するための手段が用意されています。この項では、そうした手段の一部を説明します。

表17-3 重要なワークフロー完了チューニング戦略

名前

説明

推奨事項

ワークフロー・レポートを使用した進捗状況のモニター

モニタリングおよび予防的な問題解決を容易にするワークフロー・レポート(および対応するビュー)がいくつか用意されています。

不参加タスク・レポートを確認して、長期間キューに入っているタスクを特定のユーザーに割り当てることができます。

サイクル・タイム、その他の統計をモニタリングして、負担の大きいグループやタスクの完了まで時間がかかるグループのスタッフを増員することができます。

エスカレーション・ルールの指定

タスクが特定のユーザーの下で止まってしまうことのないよう、エスカレーション・ルールを指定できます。たとえば、タスクが処理されずに一定の時間が経過した場合は、そのタスクをマネージャへ進めることができます。別のルーティング・ロジックに基づいて他のユーザーへタスクをエスカレートする必要がある場合は、カスタム・エスカレーション・ルールを組み込むことも可能です。

適切なエスカレーション・ルールを指定することで、ワークフローの完了に要する時間を短縮できます。

ユーザー・ルールおよびグループ・ルールを指定した自動割当て

ルールを使用することでワークフローの待ち時間が大幅に短縮され、ワークフロー完了の迅速化につながります。

タスクを他のユーザーやグループの他のメンバーに手動で再割当てするかわりに、ユーザー・ルールおよびグループ・ルールを使用して自動再割当てを実行できます。こうすると、ワークフローにタイミングよくユーザーの注意を向けることができます。

タスク・ビューを使用した作業の優先順位付け

ユーザーの受信ボックスには、様々な期日が設定された様々なタイプのタスクが格納されます。ユーザーは、手動でタスクを選別したり並べ替えたりして、次に処理するタスクを決める必要があります。

タスクが期日や優先度に基づいてフィルタ処理されるようなタスク・ビューを作成すれば、作業の優先順位付けが自動的に行われるため、処理するタスクを決めるのに無駄な時間を費やさずに済み、タスクの完了に専念できるようになります。

17.3.3 アイデンティティ・プロバイダのチューニング

ワークフロー・サービスでは、SQL問合せを構成する際、アイデンティティ・プロバイダの情報を使用して、ユーザーのロールやグループのメンバーシップを基にそのユーザーに該当するタスクを特定します。アイデンティティ・プロバイダに対しては、ロール情報を調べてユーザーがタスク詳細をフェッチする際の権限を特定したり、ユーザーがタスクに対して実行できるアクションを特定する目的でも、問合せが行われます。アイデンティティ・プロバイダへのリクエストを迅速化するには、いくつかの方法があります。

- アイデンティティ構成ファイル内の検索ベースをできるだけ細かくノードに設定します。理想的なのは、ワークフロー関連のグループを単一ノードに集めて、検索および参照のためのトラバースを最小限に抑えることです。これは常に可能であるとはかぎりません。たとえば、既存のグループを使用して、他のノードのグループにメンバーシップを付与する必要が生じる場合もあります。フィルタを指定して検索対象のノードを絞り込むことが可能であれば、アイデンティティ構成ファイルにフィルタを指定してください。

- アイデンティティ・プロバイダの重要な属性(dnやcnなど)のすべてに索引を作成します。そうすることで、検索や参照の際に、ツリー全体ではなくノードのサブセットのみがトラバースされるようになります。

- キャッシュをサポートするアイデンティティ・プロバイダを使用します。LDAPプロバイダの中にはキャッシュをサポートしないものもありますが、Oracle Internet Directoryはキャッシュをサポートしているため、参照および検索の問合せが高速化されます。

- Oracle Internet Directoryをアイデンティティ・プロバイダとして使用する場合、データ形状が変更された後のデータベース上の最新の統計を収集するためにoidstats.sqlを実行するようにしてください。

17.3.4 データベースのチューニング

Human Workflowスキーマでは、最も重要な列にいくつかの索引があらかじめ定義されています。ユーザーのタスク・リストをフェッチするため、リクエストのタイプに応じて異なるSQL問合せが生成されます。データベース・オプティマイザは、様々な計画(全表スキャン、索引による表アクセスなど)のコストを評価して、よりコストの低い計画を決定します。オプティマイザが正しく機能するよう、索引統計を常に最新の状態に維持してください。データベースの使用方法を問わず、最大限のパフォーマンスを得るには、データベース統計を定期的に更新し、その他のチューニング可能なパラメータ(メモリー、表領域、パーティションなど)を効果的に使用することが重要です。

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

18 Oracle Business Activity Monitoringのチューニング

この章では、Oracle Business Activity Monitoring (BAM)ダッシュボード・アプリケーションをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle BAMは、企業のビジネス・サービスおよびビジネス・プロセスをモニタリングするツールを提供します。

この章には次の項が含まれます:

- 第18.1項「Oracle Business Activity Monitoringについて」

- 第18.2項「BAMサーバーのパラメータのチューニング」

18.1 Oracle Business Activity Monitoringについて

Oracle Business Activity Monitoring (BAM)は、企業のビジネス・サービスおよびプロセスをモニタリングするためのツールを備えています。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。

Oracle BAMは、ダッシュボード(リアルタイムのデータ流入を表示し、特定の状況でアラートを送信するためのルールを定義する場所)の作成に必要なツールとランタイム・サービスも提供します。

BAMインストールのパフォーマンスをモニターする方法の詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』のOracle BAMパフォーマンスのモニタリングに関する項を参照してください。

18.2 BAMサーバーのパラメータのチューニング

BAMパフォーマンスは、次のコンポーネントのパフォーマンスに大きく依存します。

- Weblogic Server。『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。

- Metadata Service。第7章「Oracle Metadata Serviceのチューニング」を参照してください。

- Coherence。『Oracle Coherenceの管理』を参照してください。

- ADF。第9章「Oracle Application Development Framework (ADF)のチューニング」を参照してください。

- データベース設定。第2章「データベース・パラメータのチューニング」を参照してください。

- Java仮想マシン(JVM)。『Oracle WebLogic Serverのパフォーマンスのチューニング』のJava仮想マシン(JVM)のチューニングに関する項を参照してください。

- Oracle Platform Security Service。「Oracle Fusion Middlewareのセキュリティ・パフォーマンスのチューニング」を参照してください。

BAMパフォーマンスも、設計時の優れたデータ・オブジェクト設計戦略に依存し、実行時に優れたデータ・オブジェクト・パージ戦略があることに依存します。

BAM 12cはさらに大きいボリューム(BAMへのデータ到着率)のトランザクションをサポートできますが、BAM 12cは運用分析製品であり、ビジネス・インテリジェンス製品ではありません。

このため、運用の意思決定の分析値に関するデータは、BAMに保管することをお薦めします。ほとんどの顧客にとって、これはおよそ5日から30日間のトランザクション・データをBAMに保管することを意味します。一般的にデータ・ウェアハウスと比較できる休止中のデータ・サイズは、運用の意思決定には有益でないため、そのようなデータ・ボリュームはBAM 12cの主なユースケースを構成しません。

表18-1で説明されているチューニングの提案は、BAMサーバーのパフォーマンス改善に使用できます。

表18-1 重要なBAMサーバー・チューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

BAMDatasourceへの最大接続数

デフォルト: 50

データ・ソースへの同時接続の数が、常に上限に達しています。

パフォーマンスが直線的に拡張を続けるかぎり、数を増やします。

これはWebLogicレベルで設定されます。値は主に、プロセッサ数、リスニング・ソース・スレッド・モデル、および埋込みサーバーの最大同時リクエスト設定に基づいて決定できます。

数を増やすと、一般的にシステム・リソースの使用量が増えます。

ビューセット有効期限

デフォルト: 180秒

DC接続が失われた後、ビューセットが残存しています。

ビューセットが残存しないように有効期限の値を減らします。

このパラメータを検索して変更する方法の詳細は、Oracle BAMによるビジネス・アクティビティのモニタリングのビューセットのモニタリングに関する項を参照してください。

なし。

DiagnosticLevel

デフォルト: Info

問題を識別するには詳細な診断ログが必要です。

または

システムは正常に実行されているため、詳細ログは必要ありません。

デフォルトのINFOを保持するとパフォーマンスが改善されます。

BAM診断フレームワークの使用の詳細は、Oracle BAMによるビジネス・アクティビティのモニタリングのBAM診断フレームワークの使用に関する項を参照してください。

システム速度が低下した場合、問題を識別するための詳細ログがありません。

ASM (自動サーバー移行)

デフォルト: WSM

ユーザーが、BAMのあるSOA Suiteインストールを高可用性に移行しようと考えています。BAMはリアルタイム・システムであるため、ASMを有効にする必要があります。

WSMよりも高可用性が早く発生するように、ASMが使用されます。BAMがリアルタイム・システムである場合、BAM HAにASMが必要です

なし。

JVMヒープ・サイズ

デフォルト: -Xms768m -Xmx1536m

Oracle BAMの実行が遅く、メモリー不足の例外が発生します。

ヒープ・サイズを2GBに増やします。次のコマンドを使用し、引数として-Xms2048mおよび-Xmx2048mを指定します。

setenv USER_MEM_ARGS "-Xms2048m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=768m"

BAMのJVMヒープ・サイズを増やすと、他のSOAコンポーネントに影響を与える場合があります。

ヒープ・サイズのチューニングのヒントの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のヒープ・サイズのチューニングのヒントに関する項を参照してください。

18.3 その他のチューニング戦略

Oracle BAMの実行が予想よりも遅い場合、次の戦略を試すことができます。

- 索引列の作成

- ロガーのチューニング

- 連続した問合せサービスのチューニング

18.3.1 索引列の作成

エンタープライズ・メッセージ・ソースまたは他のソースからデータ・オブジェクトへのデータのスループットが遅い場合は、主キー列に索引列を作成してください。詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』の索引列の追加に関する項を参照してください。

18.3.2 ロガーのチューニング

すべてのロガーに対するデフォルトのOracle Diagnostic LoggingレベルはNotificationです。ストレス・テスト用の環境や本番環境では、ERRORやWARNINGなどの最低限のロギング・レベルを使用することを検討してください。

BAMパフォーマンスに影響する可能性があるBEAMのロガーは次のとおりです。

oracle.beam.common.alertsengine
oracle.beam.server.service.alertsengine
oracle.beam.Common
oracle.beam.cqservice
oracle.beam.composer
com.oracle.beam
oracle.beam.datacontrol
oracle.beam.datacontrol.management
oracle.beam.server.service.ems
oracle.beam.messaging
oracle.beam.server.service.persistence
oracle.beam.server.service.reportcache
oracle.beam.security
oracle.beam.mbean
oracle.beam.shared
oracle.beam.server
oracle.beam.impexp.t2p
oracle.beam

これらのロガーの検索およびそのOracle Diagnostic Loggingレベルの変更の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のログ・ファイルの構成に関する項を参照してください。

18.3.3 連続した問合せサービスのチューニング

連続した問合せサービス(CQS)は、Oracle Complex Event Processing Service Engineに含まれるContinuous Query Language (CQL)エンジンのBAM固有のラッパーです。CQSは純粋なプッシュ・システムです。問合せ結果は自動的に配信されます。CQSでは、ストリーム(非永続)とアーカイブされたリレーション(永続)データ・オブジェクトの両方がサポートされています。

問合せを作成すると、CQSでは、CQLエンジン内に表を設定し、問合せを登録して、永続性エンジンからのデータ変更をリスニングします。問合せ結果はCQLエンジン内で処理された後、CQSにプッシュされ、さらにレポート・キャッシュにプッシュされます。

パフォーマンスの問題に対する連続問合せのモニター方法の詳細は、『Oracle BAMでのビジネス・アクティビティのモニタリング』の連続した問合せのモニタリングに関する項を参照してください。現在のシステムがどのように実行されているか理解したら、表18-2に示すノブのチューニングによって、パフォーマンスの改善を試行できます。これらのパラメータのほとんどにとって、パフォーマンスを考慮したチューニングは、診断情報を失うことを意味することに注意してください。

表18-2 連続した問合せサービスのチューニング

パラメータ

問題点

チューニングに関する推奨事項

データ・オブジェクト・タイプ

デフォルト: なし

ストリーム、アーカイブ済ストリームおよびアーカイブ済リレーションとして単純なデータ・オブジェクトを任意に指定しましたが、処理がわかりません。

履歴データに関心がない場合、データ・オブジェクトをストリームとして分類します。

各データ・オブジェクト・タイプおよび関連の詳細は、Oracle BAMによるビジネス・アクティビティのモニタリングのデータ・オブジェクト・タイプに関する項を参照してください。

データ・オブジェクトのパージ

デフォルト: 無効

デフォルトではデータ・オブジェクトの保存は設定されません。データ・オブジェクトに多くの行があると、パフォーマンスの問題を引き起こします。

顧客は、データ・オブジェクトの保存をデータ・オブジェクトの「保存」タブに設定して、データをデータ・オブジェクトに保持する日数を指定できます。指定した日数が経過すると、データ行は自動的にパージされます。

この設定を検索して変更する方法の詳細は、Oracle BAMによるビジネス・アクティビティのモニタリングに関するマニュアルのデータ保存の設定の項を参照してください。

アーカイブ済ストリーム・データ・オブジェクトのリプレイ

アーカイブ済ストリーム・データ・オブジェクトのデータ解析が遅くなっています。

「リプレイ単位」または「リプレイ量」の指定を小さくして、メモリーに保持されている過去データの量を削減します。これによって、データベースから取得されたデータを解析するための時間およびメモリーが削減されます。

入力ストリームの時間ウィンドウ

アクティブ・データ問合せを連続した問合せにし、メモリー不足の例外を受け取っています。

アクティブ・データ・ストリームの時間ウィンドウ・サイズを小さくします。これによって、ウィンドウが要素の格納に使用するメモリーの量が制限されます。

どのぐらいのウィンドウ・サイズがメモリー使用率に影響するかを調べるために、ウィンドウ・サイズ = 1時間(RANGE 1時間)およびイベント・サイズ = 100 バイトのシナリオを想定します。イベント率が1000イベント/秒である場合、ウィンドウには満杯のときで1000 * 3600のイベントが含まれます。消費されるメモリーは1000 * 3600 * 100バイト = ~340MBです。

アクティブ・データ・ビューのウィンドウ・サイズを構成する方法は、Oracle BAMによるビジネス・アクティビティのモニタリングのビューでのアクティブ・データの有効化に関する項を参照してください。

アクティブ・データ縮小間隔

デフォルト: 選択解除

データ集計をアクティブにするために、「アクティブ・データ縮小」のボックスを選択しています。より頻繁なスナップショットが必要であるか、メモリーの解放が必要です。

小さい「間隔」を定義して、ビューの更新を頻繁にし、メモリーに格納される集計済データの量を削減します。

評価間隔、イベント・サイズおよびイベント率に注意することによって、メモリー使用率を最大化できます。次の値を指定したとします。

間隔: 5分ごと
イベント・サイズ: 100バイト
イベント率: 1000イベント/秒
集計ビューの最大サイズは5 * 60 * 1000 = 300,000イベント = ~28MBです。

「アクティブ・データ縮小」設定の検索の詳細は、Oracle BAMによるビジネス・アクティビティのモニタリングのアクティブ・データの使用に関する項を参照してください。

データ・オブジェクト・ディメンション表の緩やかに変化するディメンション

デフォルト: 選択解除

ディメンション表の連続した問合せが遅くなっており、メモリーを消費しています。

このプロパティを選択してアクティブ化します。これは、このディメンション表のデータ変更の頻繁が低いことを示します。

データ・オブジェクトの緩やかに変化するディメンションの指定の詳細は、Oracle BAMによるビジネス・アクティビティのモニタリングのデータ・オブジェクトの緩やかに変化するディメンションの指定に関する項を参照してください。

問合せタイプ

デフォルト: SQL

メモリー不足の例外が発生しており、問合せのほとんどが連続しています。

頻繁な出力が予想されない場合はスケジュール問合せ(SQL)を使用します。CQLはメモリーにデータを格納しますが、SQLにはJDBCリソースが含まれるため、これによってメモリーが節約されます。

19 Oracle Service Busのチューニング

この章では、Oracle Service Busのパフォーマンスをチューニングする方法について説明します。

内容は次のとおりです。

- 第19.1項「Oracle Service Busについて」

- 第19.2項「OSBパラメータのチューニング」

- 第19.3項「その他のチューニング戦略の使用」

19.1 Oracle Service Busについて

SOAフレームワーク内で、Oracle Service Bus (OSB)は、接続性、ルーティング、仲介、管理および一部のプロセス編成機能を提供します。OSBの設計理念は、高いパフォーマンスと2つ以上のアプリケーション間のステートレス(非永続状態)な中間機能を実現することです。ただし、SOA実装のスケールおよび機能の多様性により、OSBアプリケーションには、様々な使用パターン、メッセージ・サイズおよびQOS要件があります。

ほとんどのSOAデプロイメントで、OSBは、2つ以上のアプリケーション(サーバー)の中間機能の役割を果たす大規模なシステムの一部です。通常のOSB構成には、中間バックエンド・サービスの1つ以上のサービス・コールアウトを実行し、クライアントにレスポンスする前に宛先バックエンド・システムにリクエストをルーティングする可能性のあるOSBプロキシ・サービスを起動するクライアントが含まれます。

OSBが大規模なシステムの一部であり、チューニングの目的が全体のシステム・パフォーマンスの最適化であることを理解する必要があります。これには、スタンドアロン・アプリケーションとしてのOSBのチューニングだけではなく、OSBを使用した調整、リクエストのバッファリング、キャッシュ、優先順位付け、並列処理などのフロー制御パターンの実装が含まれます。

Oracle Service Busの詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』を参照してください。

19.2 OSBパラメータのチューニング

Oracle Service Busパフォーマンスは、他のコンポーネントのパフォーマンスに大きく依存します。次のコンポーネントがOSBパラメータに影響を与えます。

- WebLogic Server

- Coherence

- アダプタ

これらのコンポーネントが十分にチューニングされていることが確かな場合は、Oracle Service Busのチューニングを開始できます。

19.2.1 ワーク・マネージャを使用したOracle Service Busのチューニング

12c (12.1.3)から、Oracle Service BusはいくつかのOracle WebLogic Serverワーク・マネージャでチューニングできるようになりました。

たとえば、ワーク・マネージャを使用して分割-結合のチューニングを行うことができます。デフォルトでは、アプリケーションは分割-結合にワーク・マネージャを指定しませんが、パラレル・タスクのスケジュールなど、スレッドが満たす必要がある制約が厳しい場合は、分割-結合にワーク・マネージャを割り当てることができます。

最適なパフォーマンスを得るには、次のワーク・マネージャの制約のバランスを取ります。

- min-threads-constraintは、分割-結合操作にスレッドが不足しないようにします。

- max-threads-constraintは、分割-結合に他のリソースが不足しないようにします

デフォルトでは、最小または最大スレッド数の制約は定義されておらず、分割-結合操作が低下するか、同じスレッド・プールを共有する他の操作が低下する可能性があります。

ワーク・マネージャは、システム全体のプロセスにスレッドを割り当てるときに分割-結合操作を考慮に入れて、このバランスが自動的に取られるようにします。

ワーク・マネージャを使用したOSBのチューニングの詳細は、『Oracle Service Busでのサービスの開発』のOracle Service Busによるワーク・マネージャの使用に関する項を参照してください。

19.2.2 OSB操作設定のチューニング

表19-1に、パフォーマンスの改善のために一般的にチューニングが必要であるノブを示します。障害のある領域を診断するためのOracle Service Busのモニタリングの詳細は、『Oracle Service Busの管理』のOracle Service Busのモニタリングに関する項を参照してください。

表19-1 重要なOSB操作のチューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

モニタリングおよびアラート

デフォルト: Disabled

モニタリングおよびアラートのフレームワークは、パフォーマンスに与える影響が最小になるように設計されていますが、これらのプロセスはすべてパフォーマンスに影響を与えます。

一般的に、定義したモニタリング・ルールおよびパイプライン・アクションが多いほど、パフォーマンスへの影響が大きくなります。

OSBレベルでデフォルトのDisabledを保持します。ほとんどの設定は、グローバルにまたはサービスごとに定義できます。

モニタリングおよびアラートの設定は、Enterprise Manager管理者コンソールで構成できます。

モニタリングは、SLAアラートに対しては有効にできますが、パイプライン・アラートに対しては有効にできないことに注意してください。

パフォーマンスを改善するためにこれらのプロセスを無効にするということは、問題のトラブルシューティングで今後役立つ可能性のあるメトリックおよびアラートのいくつかを犠牲にすることを意味します。

OSBモニタリング・フレームワークの詳細は、『Oracle Service Busの管理』のOracle Service Busモニタリング・フレームワークの概要に関する項を参照してください。

トレース

デフォルト: 無効

メッセージ・サイズが大きく、高スループットのシナリオがある場合、トレースはシステムを低下させる可能性があります。

パフォーマンスを改善するためにトレースを無効のままにします。

詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のトレースを有効または無効にする方法に関する項を参照してください。

無効にすると、メトリックが失われます。

トレースは、ヘッダーおよびメッセージ本文を含めて、メッセージ・コンテキスト全体を出力します。これは、1つ以上のプロキシ・サービスのメッセージ・フローを含む問題のデバッグ、診断およびトラブルシューティングを行う開発および本番環境に非常に便利な機能です。

com.bea.wli.sb.pipeline.
RouterRuntimeCache.size

デフォルト: 100

次のいずれかの問題が発生する可能性があります。

プロキシ・サービスのアクセスが遅くなっています。これは、パイプライン・サービス・ランタイム・メタデータ用のOSBキャッシュの静的な部分に格納するプロキシ・サービスを増やすことを意味します。ここに格納されたプロキシ・サービスはガベージ・コレクションされることがないため、アクセスが早くなります。

または

DMSダンプで多数のキャッシュ・ミスが検出されます。

静的キャッシュに含むプロキシ・サービス数を増やす場合、多数のプロキシ・サービスに対するランタイム・データ処理のメモリーが十分あるかぎり、この値を大きくします。

DMSダンプでキャッシュ・ミスが検出される場合、この値を小さくします。

このシステム・プロパティは、パイプライン・サービス・ランタイム・メタデータ用のOSBキャッシュの静的な部分にあるプロキシ・サービスの数を制限します。これらのサービスはガベージ・コレクションされません。

次に示すように、追加のJava引数としてこの値のサイズをsetDomainEnv.shファイルに設定します。

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}

たとえば、この値を3000に設定する場合、次のようにします。

EXTRA_JAVA_PROPERTIES=
"-Dcom.bea.wli.sb.pipeline.
RouterRuntimeCache.size=3000
${EXTRA_JAVA_PROPERTIES}"

この値を大きくすると、プロキシ・サーバーへの初期コールに要する時間が短縮されます。また、構成セッションがコミットされる際に、キャッシュを事前ロードすることもできます。ただし、プロキシ・サービスをキャッシュするとコンパイル・コストが下がりますが、メモリー消費量は増加します。

この値を小さくすることはメモリーの解放を意味しますが、プロキシ・サーバーへの初期コールに要する時間が長くなる場合があります。

reorderJsonAsPerXmlSchema

デフォルト: False

RESTサービスへのJSON入力が、スキーマ定義で予想された順序ではありません。

JSONからXMLに変換するとき、OSBランタイムは、対応するXML要素を構成するためにJSONの名前/値が表示される順序を使用します。整形式ですが、この形式はXMLスキーマによると有効ではありません。

RESTウィザードを実行して最初のページのボックスを選択することによって、このパラメータをTrueに設定します。

このオプションを選択すると、RESTサービスによって入力JSONの順序が変更され、外部RESTエンドポイントからのレスポンスを、有効なスキーマ定義に従った順序にすることができます。

このオプションを使用すると、大量のパフォーマンス・オーバーヘッドが追加されます。

19.3 その他のチューニング戦略の使用

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

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

- OSBのリシーケンサのチューニング

- プロキシ・アプリケーションの設計時の考慮事項

- XQueryのチューニング

- ポーラーベースのトランスポートのチューニング

19.3.1 OSBのリシーケンサのチューニング

リシーケンサは、関連性はあるが順序が正しくないメッセージのストリームを再配置して順序どおりに戻すために使用します。ランダムな順序で届く着信メッセージを順序付けし、ターゲット・サービスに正しい順序で送信します。

表19-2に示すプロパティを、OSB EMコンソールのグローバル操作設定ページを使用して設定することによって、リシーケンサを細かくチューニングできます。

表19-2 重要なリシーケンサ・チューニング

パラメータ

問題点

チューニングに関する推奨事項

トレードオフ

ResequencerMaxGroupsLocked

デフォルト: 4グループ

このパラメータは、パラレル処理に対してリシーケンサ・ロッカー・スレッドでロックできるメッセージ・グループの最大数を定義します。ロックされたグループはワーカー・スレッドを使用してそれぞれのメッセージを処理できます。

メッセージ処理が遅延する場合、次のどの状況であるか特定します。

- 着信メッセージが多くのグループに属しています

- 多くのメッセージがあり、それらが少ないグループに属しています

多くのグループがあり、それぞれのメッセージ数が少ない場合、このパラメータの値を大きくします。リシーケンサは1回の反復でより多くのグループをロックします。

グループが少なく、メッセージ数が多い場合、この値を小さくします。リシーケンサが処理のためにロックするグループ数が少なくなります。

MaxGroupsLockedの値を大きくすると、使用可能なワーカー・スレッドよりも多くのグループがロックされる場合があります。これによって、ワーカー・スレッドがメッセージ処理に使用可能になることを待機する間、グループがブロックされる場合があります。

デフォルト値を小さくすると、リソースの使用率が下がります。

ResequencerLockerThreadSleep

デフォルト: 10秒

リシーケンサ・ロッカー・スレッドは、パラレル処理に対してグループをロックするためにデータベースに問い合せます。使用可能なグループがない場合、ロッカー・スレッドは、このパラメータで指定された時間スリープします。

次のいずれかの状況の場合は、このパラメータのチューニングが必要です。

- メッセージ数が多く、データベース問合せ間の処理時間が遅くなっています。

- メッセージ数は少ないですが、データベース問合せが頻繁にあります。

メッセージ数が多い場合、このパラメータ値を小さくして処理中のタイム・ラグを短縮します。

着信メッセージが少ないのにリシーケンサ・ロッカー・スレッドが頻繁にデータベース・ラウンドトリップを行う場合は、この値を大きくします。

スリープ時間が短すぎる場合、ロックされたグループの着信メッセージの処理に使用できるワーカー・スレッドが十分ではないことがあります。データベース問合せが多すぎる場合もパフォーマンスが低下します。

着信メッセージの間隔がすでに長い場合は、値を大きくすることは有益ではありません。

DeleteMessageAfterComplete

デフォルト: True

リシーケンサ・データベースの領域が少なくなっています。このパラメータの値をfalseに変更した場合、処理されたメッセージがリシーケンサ・データベースにとどまり、データベース照会を遅くします。

デフォルト値のTrueを保持して、メッセージを正常実行後に削除します。これによってデータベース領域が解放されます。

処理されたメッセージの詳細履歴がなくなります。

19.3.2 プロキシ・アプリケーションの設計時の考慮事項

OSBの使用およびユースケース・シナリオに基づいて、プロキシ・アプリケーションの表19-3に示した設計の構成を検討してください。

表19-3 プロキシ・アプリケーションの設計時のチューニング

戦略

説明

推奨事項

別のXQueryで一度だけ使用される多くのOSBコンテキスト変数の作成を回避します。

割当てアクションを使用して作成されるコンテキスト変数は、XmlBeansに変換され、次のXQueryの固有のXQuery形式に戻されます。FLWOR式を使用すると、複数の「割当て」アクションを1つの割当てアクションに縮小できます。「let」文を使用して中間値を作成できます。

冗長なコンテキスト変数の作成を回避すると、内部データ形式変換に関連するオーバーヘッドがなくなります。この利点とコードの可視性および変数の再利用でバランスをとる必要があります。

$bodyなどのコンテキスト変数の内容を変換します。

コンテキスト変数の内容の変換は、時間がかかる場合があります。

1つの手順で変換を完了するには、置換アクションを使用します。

$bodyの全体の内容を置換する場合、XPathフィールドを空のままにして、「ノードのコンテンツを置換」を選択します。これは、$body($body/Orderなど)の子ノードを参照して「ノード全体を置換」を選択するよりも高速です。

XPathフィールドを空のままにすると、余分なXQuery評価が排除されます。

特別なXPathを指定します。

主な変換リソースを実行する前に、$body/Orderなどの一般的なXPathをXQueryエンジンで評価する必要があります。OSBは、XQueryエンジンを起動しないで評価できる特別なXPathとして$body/*[1]を処理します。

変換(XQuery/XSLT)リソースへの入力として、$body/*[1]を使用して$bodyの内容を表します。

これは、$bodyの子を参照する絶対パスを指定するよりも高速になります。

純粋なコンテンツベースのルーティング・シナリオのストリーミングを有効にします。

OSBは、索引付けされたXPathと組み合せてストリーミングを使用する場合にXQueryエンジンの部分解析機能を利用します。このため、

詳細は、第19.3.3項「XQueryのチューニング」を参照してください。

ストリーミングを有効にするということは、XPathで参照するフィールドにのみペイロードが解析されて処理されることを意味します。ストリーミングはまた、XmlBeansの解析およびシリアライズに関連するオーバーヘッドを排除します。

トレードオフ: 複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。

変換の出力は、メモリーまたはディスクに圧縮されたバッファ形式で格納されます。そのため、メモリー不足の問題がない場合はストリーミングを回避する必要があります。

適切なQOSレベル設定およびトランザクション設定を実行します。

OSBは、QOSが「ベスト・エフォート」の場合にバックエンドHTTPサービスを非同期に起動できます。非同期呼出しにより、OSBは長時間実行するバックエンド・サービスのスケーラビリティを向上できます。また、HTTPでの公開を忠実に一方向に実行できます。

必要な信頼性レベルが1回および1回のみで、その設定を使用できる場合(クライアントがHTTPクライアントの場合は使用できません)を除いて、XAまたは「必ず1回」を設定しないでください。OSBがトランザクションを開始すれば、XAをLLRに置換して同じレベルの信頼性を実現できます。

すべてのログ・アクションを無効化または削除します。

ログ・アクションにより、I/Oオーバーヘッドが追加されます。ロギングには、高負荷になる可能性があるXQuery評価も含まれます。1つのデバイス(リソースまたはディレクトリ)に書き込むと、ロック競合が発生する可能性もあります。

すべてのログ・アクションを無効化または削除します。

19.3.3 XQueryのチューニング

OSBは、割当て、置換、ルーティング表などの様々なアクションに幅広くXQueryおよびXPathを使用します。次のXML構造($body)を使用して、XQueryおよびXPathチューニングの概念を説明します。

<soap-env:Body>
<Order>
<CtrlArea>
<CustName>Mary</CustName>
</CtrlArea>
<ItemList>
<Item name="ACE_Car" >20000 </Item>
<Item name=" Ext_Warranty" >1500</Item>
…. a large number of items
</ItemList>
<Summary>
<Total>70000</Total>
<Status>Shipped</Status>
<Shipping>My Shipping Firm </Shipping>
</Summary>
</Order>
</soap-env:Body>

表19-4に示すチューニング戦略を使用して、XQueryをチューニングできます。

表19-4 XQueryのチューニング戦略

戦略

説明

推奨事項

XPathの先頭の2つのスラッシュ(「//」)の使用を回避します。

"//"は、XMLツリー内の場所に関係なくノードのすべての発生を示します。そのため、「//」の後に指定したパターンでXMLツリーの全体の深さおよび範囲を検索する必要があります。

設計時にノードの正確な場所がわからない場合のみ、「//」を使用してください。

該当する場合、XPathを索引付けします。

索引付けは、システムが必要なものだけを処理する場合に役立ちます。索引付けを行うとき、XQueryエンジンによってドキュメントの最初の部分のみが処理されます。

パスの各ノードの後に"[1]"を追加して、XPathを索引付けします。

たとえば、XPath $body/Order/CtrlArea/CustNameは、$bodyの下のOrderのすべてのインスタンスと、Orderの下のCtrlAreaのすべてのインスタンスを戻すことを示します。前述のXPathを適切に処理するには、ドキュメント全体を読み込む必要があります。

しかし、$bodyの下にOrderの1つのインスタンス、Orderの下にCtrlAreaの1つのインスタンスが存在する場合、前述のXPathを$body/Order[1]/CtrlArea[1]/CustName[1]と書き換えることによって索引付けできます。これは、子ノードの最初のインスタンスのみを戻します。

注意: ノードの配列全体を戻す必要がある場合は、索引付けしないでください。索引付けは、配列の最初の項目ノードのみを戻します。

FLWOR式内の中間変数として、大きいXMLドキュメントの頻繁に使用する部分を抽出します。

中間変数を使用して、複数の値の共通のコンテキストを格納できます。

中間変数の使用はメモリーを多く消費しますが、冗長なXPath処理を削減します。

ストリーミングを使用した読取り専用シナリオにハイブリッド方法を使用します。

複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。

プロキシ・レベルでのストリーミングおよびコンテキスト変数への関連サブセクションの割当を有効にします。このコンテキスト変数から、個々のフィールドにアクセスできるようになります。

3つの割当てアクションを使用して、「合計」および「ステータス」フィールドを取得できます。

Assign "$body/Order[1]/Summary[1]" to "foo"
Assign "$foo/Total" to "total"
Assign "$foo/Status" to "total"

注意:
コンテンツのストリーミングに有効なパイプラインは、"XQuery 1.0"を使用する必要があります。"XQuery 2004"の使用も機能しますが、XQuery 1.0エンジンとの間で発生するオンザフライ変換があるため、大きなパフォーマンス・オーバーヘッドが発生します。その影響に対する設計時の警告があります。

19.3.4 ポーラーベースのトランスポートのチューニング

ポーラーベースのトランスポートの待機時間およびスループットは、ソースがポーリングされる頻度およびポーリング・スイープごとに読み込まれるファイルとメッセージの数によって異なります。

次に、チューニングする主なトランスポート構成を示します。

- ポーリング間隔

- 読取り制限

19.3.4.1 ポーリング間隔

メッセージ・サイズが大きすぎず、CPUが飽和していない高いスループットのシナリオに短いポーリング間隔を使用することを検討してください。追加情報のリンクとともに主なポーリング間隔のデフォルトを次に示します。

ポーリング間隔

デフォルトの間隔

追加情報

ファイル・トランスポート

60秒

『Oracle Service Busでのサービスの開発』のファイル・トランスポート構成に関するページ

FTPトランスポート

60秒

『Oracle Service Busでのサービスの開発』のFTPトランスポート構成に関するページ

MQトランスポート

1000ミリ秒

『Oracle Service Busでのサービスの開発』のMQトランスポート構成に関するページ

SFTPトランスポート

60秒

『Oracle Service Busでのサービスの開発』のSFTPトランスポート構成に関するページ

JCAトランスポート

60秒

『Oracle Service Busでのサービスの開発』のJCAトランスポート構成に関するページ

19.3.4.2 読取り制限

読取り制限は、ポーリング・スイープごとに読み込まれるファイルまたはメッセージの数を決定します。表19-5の情報を使用してこれをチューニングできます。

詳細は、『Oracle Service Busでのサービスの開発』のファイル・トランスポートの使用に関する項を参照してください。

表19-5 重要な読取り制限のチューニング

パラメータ

適切にチューニングされていない場合の症状

チューニングに関する推奨事項

パフォーマンスのトレードオフ

読取り制限

デフォルト: ファイル・トランスポートおよびFTPトランスポートに対して10

同時にメモリーに読み取られるファイル数が多い場合、メモリー使用量が過度になったり多くなります。

この値を任意の同時実行性に設定してください。0を設定して無制限を指定できます。

読取り制限は、ポーリング・スイープごとに読み込まれるファイルまたはメッセージの数を決定します。

読取り制限を高い値、ポーリング間隔を小さい値に設定すると、多くのメッセージがメモリーに同時に読み込まれる場合があります。メッセージ・サイズが大きい場合、メモリー不足エラーが発生する可能性があります。

20 Oracle Enterprise Scheduler Serviceのチューニング

この章では、Oracle Enterprise Scheduler Service (ESS)のチューニング方法について説明します。

- 第20.1項「エンタープライズ・スケジューラ・サービスについて」

- 第20.2項「エンタープライズ・スケジューラ・サービスのパラメータのチューニング」

20.1 エンタープライズ・スケジューラ・サービスについて

Oracle Enterprise Schedulerでは、作業割当てを作成するルールを使用して、特定の時間枠または作業シフト内でジョブをスケジュールおよび実行できます。Oracle Enterprise Manager Fusion Applications Controlを使用すると、ジョブ定義、ジョブ・リクエスト、ジョブ・セット(ジョブ・リクエストのコレクション)、非互換性(特定のアプリケーションで同時に実行できないジョブ定義およびジョブ・セット)、およびジョブ・リクエストの実行を管理するスケジュールを含めて、Oracle Enterprise Schedulerジョブ・メタデータを定義、制御および管理できます。

詳細は、Oracle Enterprise Schedulerの管理のOracle Enterprise Schedulerの管理の概要に関する項を参照してください。

20.2 エンタープライズ・スケジューラ・サービスのパラメータのチューニング

チューニングできるノブは2つあり、それらの戦略を表20-1に示します。

Oracle Enterprise Schedulerのリクエスト・ディスパッチャに適用されます。リクエスト・ディスパッチャは、スケジュールされている実行を待機しているリクエストを管理します。リクエスト・プロセッサは、Oracle Enterprise Schedulerリクエスト・プロセッサに適用されるプロセッサ・チューニング・パラメータをディスパッチすると、ジョブ・リクエストを処理します。リクエスト・プロセッサは、実行スケジュール時間に到達していて、実行準備が整っているジョブ・リクエストを管理します。

表20-1 重要なエンタープライズ・スケジューラ・サービスのチューニング

名前

症状

推奨事項

トレードオフ

最大ポーリング間隔

デフォルト: 15秒

実行時間に到達しているが長時間WAIT状態のままであるリクエストが多数あります。

ディスパッチに適格な待機リクエストが余分にあり、プロセッサ・スレッドが使用可能である場合は、この値を減らします。

値を小さくすると、CPU使用率およびデータベース・アクティビティが増加します。

値を大きくすると、処理の準備ができているリクエストのディスパッチが遅延します。

スレッド数

デフォルト: 25

処理できるREADY状態のリクエストが多数あります。

実行の準備ができているリクエストの累積があり、増加システム・リソース使用率が許容される場合は、この値を大きくします。

リクエスト処理に使用するシステム・リソースの量を減らす場合は値を小さくします。

この値を大きくすると、CPU使用率、メモリー使用率およびデータベース・アクティビティが増加します。

この値を小さくすると、リクエストが累積してその処理が遅れる可能性があります。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, 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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。