Fusion Middleware パフォーマンスおよびチューニング・ガイド

11g リリース1(11.1.1)

B61006-04(原本部品番号:E10108-06)

目次

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

はじめに

- 対象読者

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

- 表記規則

第I部 概要

1 概要とロードマップ

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

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

- 1.3 関連ドキュメント

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

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

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

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

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

- 2.4.1 ガベージ・コレクションの構成

- 2.4.1.1 ヒープ・サイズ値の指定

- 2.4.1.2 ガベージ・コレクション方式の選択

- 2.4.1.3 明示的ガベージ・コレクションの無効化

- 2.4.2 低メモリー状態のロギング

- 2.4.3 JVMの監視およびプロファイリング

- 2.5 WebLogic Serverのチューニング

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

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

- 2.6.1.1 Oracle 10gの初期化パラメータ

- 2.6.1.2 Oracle 11gの初期化パラメータ

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

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

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

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

- 2.9 同時実行性の制御

- 2.9.1 HTTP接続制限の設定

- 2.9.1.1 MaxClients/ThreadsPerChild

- 2.9.1.2 KeepAlive

- 2.9.1.3 MOD_WL_OHSのチューニング

- 2.9.2 接続プールの構成

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

- 2.9.4 Oracle WebCenterの同時実行性のチューニング

- 2.9.5 BPELの同時実行性のチューニング

- 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 11g Fusion Middleware Control

- 4.2.1 Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示

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

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

- 4.5 WebLogic Scripting Tool(WLST)

- 4.5.1 カスタムWLSTコマンドの使用

- 4.5.1.1 システム・コンポーネント用のWLSTコマンドの使用

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

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

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

- 4.7 Oracle Process Manager and Notification Server

- 4.8 Oracle Enterprise Manager 11g Grid Control

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

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

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

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

- 5.1 Oracle HTTP Serverについて

- 5.2 Oracle HTTP Serverディレクティブのチューニングに関する考慮事項

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

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

- 5.3.1 アクセス・ロギング

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

- 5.3.3 エラー・ロギング

- 5.4 Oracle HTTP Serverセキュリティのパフォーマンスに関する考慮事項

- 5.4.1 Oracle HTTP ServerにおけるSecure Sockets Layer(SSL)のパフォーマンスの問題

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

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

- 5.4.1.3 SSLのパフォーマンスのチューニングに関する考慮事項

- 5.4.2 Oracle HTTP Serverポート・トンネリングのパフォーマンスの問題

- 5.5 Oracle HTTP Serverのパフォーマンスに関する考慮事項

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

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

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

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

- 5.5.5 Oracle HTTP Serverの監視

6 Oracle Dynamic Monitoring Serviceのパフォーマンス・チューニング

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

- 6.1.1 共通のDMSの用語と概念

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

- 6.1.1.2 DMSナウン

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

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

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

- 6.1.1.3 DMSセンサー

- 6.1.1.3.1 DMS PhaseEventセンサー

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

- 6.1.1.3.3 DMS状態センサー

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

- 6.2 DMSの可用性

- 6.3 DMSアーキテクチャの概要

- 6.4 DMSメトリックの表示

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

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

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

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

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

- 6.4.6 WSADMIN(IBM WebSphere)を使用したメトリックの表示

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

- 6.6 DMS実行コンテキスト

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

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

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

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

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

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

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

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

- 6.7.1.4 複合操作

- 6.7.2 宛先の構成

- 6.7.2.1 LoggerDestination

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

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

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

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

- 6.7.2.2 MBean Creatorの宛先

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

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

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

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

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

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

- 6.7.3 DMSイベント出力の理解

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

- 6.8 DMSベスト・プラクティス

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

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

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

- 7.2.1 スキーマ統計の収集

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

- 7.2.3 ディスク領域の解放

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

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

- 7.3.1 自動パージ

- 7.3.2 手動パージ

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

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

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

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

- 7.7 DMSメトリックとその特性の理解

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

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

- 8.1 Oracle ADFについて

- 8.2 Oracle ADFビューのパフォーマンス

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

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

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

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

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

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

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

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

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

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

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

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

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

- 8.3.3 バッチ処理

- 8.3.4 RangeSizeのチューニング

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

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

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

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

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

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

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

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

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

- 8.3.11 静的データの再利用

- 8.3.12 条件付き検証

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

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

- 9.2 効率的なSQL文およびSQL問合せ

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

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

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

- 9.3.2 ロック・モード

- 9.4 Coherenceとの統合

- 9.5 マッピングおよびディスクリプタの構成

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

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

10 Oracle Web Cacheのパフォーマンス・チューニング

- 10.1 Oracle Web Cacheについて

- 10.2 ハードウェア・リソースの最適化

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

- 10.2.2 メモリー構成

- 10.2.2.1 Web Cacheメモリーの構成

- 10.3 ネットワーク接続の最適化

- 10.3.1 ネットワーク帯域幅

- 10.3.2 ネットワーク接続

- 10.3.3 ネットワーク関連パラメータ

- 10.4 プラットフォームでの接続の最適化

- 10.4.1 UNIXでの接続

- 10.4.2 Windowsでの接続

- 10.5 キャッシュ・ヒット率の向上

- 10.6 レスポンス時間の最適化

- 10.7 Oracle ADFに対するパフォーマンスの最適化

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

11 SOA Suiteコンポーネントの一般的なチューニング

- 11.1 SOA Suiteの構成プロパティについて

- 11.2 SOAインフラストラクチャの構成

- 11.2.1 監査レベル

- 11.2.2 コンポジット・インスタンスの状態

- 11.2.3 instanceTrackingAuditTrailThreshold

- 11.2.4 ロギング・レベル

- 11.3 SOA構成パラメータの変更

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

- 11.5 データベースの設定

- 11.5.1 SOAのデータ・ソースの構成

- 11.5.2 表および索引の管理

- 11.5.3 Weblogic Serverのパフォーマンス・チューニング

12 Oracle Business Rulesのパフォーマンス・チューニング

- 12.1 Oracle Business Rulesについて

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

- 12.2.1 Java Beansの使用

- 12.2.2 複数の逆参照を使用するかわりに子ファクトをアサート

- 12.2.3 ルール条件における副作用の回避

- 12.2.4 ルール条件における高コストの操作の回避

- 12.2.5 パターンの順序の検討

- 12.2.6 ルール条件におけるテストの順序の検討

- 12.2.7 AssertXPathおよびSupports XPathのかわりに関数を使用

13 Oracle BPEL Process Managerのパフォーマンス・チューニング

- 13.1 BPEL Process Managerについて

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

- 13.2.1 BPELスレッド・モデル

- 13.2.1.1 ディスパッチャ・システム・スレッド

- 13.2.1.2 ディスパッチャ呼出しスレッド

- 13.2.1.3 ディスパッチャ・エンジン・スレッド

- 13.2.1.4 ディスパッチャ最大リクエスト深さ

- 13.2.2 監査

- 13.2.2.1 AuditLevel

- 13.2.2.2 AuditDetailThreshold

- 13.2.2.3 AuditStorePolicy

- 13.2.2.4 AuditFlushByteThreshold

- 13.2.2.5 AuditFlushEventThreshold

- 13.2.3 OneWayDeliveryPolicy

- 13.2.4 MaximumNumberOfInvokeMessagesInCache

- 13.2.5 StatsLastN

- 13.2.6 LargeDocumentThreshold

- 13.2.7 ValidateXML

- 13.2.8 SyncMaxWaitTime

- 13.2.9 InstanceKeyBlockSize

- 13.2.10 MaxRecoverAttempt

- 13.3 コンポジット内で設定するBPELプロパティ

- 13.3.1 コンポーネント・プロパティ

- 13.3.1.1 inMemoryOptimization

- 13.3.1.2 completionPersistPolicy

- 13.3.1.3 auditLevel

- 13.3.2 パートナ・リンク・プロパティ

- 13.3.2.1 idempotent

- 13.3.2.2 nonBlockingInvoke

- 13.3.2.3 validateXML

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

14 Oracle Mediatorのパフォーマンス・チューニング

- 14.1 Oracle Mediatorについて

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

- 14.2.1 metricsLevel

- 14.2.2 ドメイン値マップ

- 14.2.3 遅延ルーティング・ルール

- 14.2.4 エラー・パラメータおよび再試行パラメータ

- 14.2.5 監査レベル

- 14.2.6 再シーケンサ

- 14.3 イベント配信ネットワーク(EDN)のチューニング

15 Oracle Business Process Managementのパフォーマンス・チューニング

- 15.1 Oracle Business Process Managementについて

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

- 15.2.1 監査レベル

- 15.2.2 LargeDocumentThreshold

- 15.2.3 ディスパッチャ・システム・スレッド

- 15.2.4 ディスパッチャ・エンジン・スレッド

- 15.2.5 ディスパッチャ呼出しスレッド

- 15.3 Oracleワークスペースおよびワークリスト・アプリケーションのチューニング

- 15.4 Process Analyticsのチューニング

- 15.4.1 プロセス測定

- 15.4.2 プロセス・キューブのチューニング

16 Oracle Human Workflowのパフォーマンス・チューニング

- 16.1 Oracle Human Workflowについて

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

- 16.2.1 クライアント側のレスポンス時間の最小化

- 16.2.2 適切なワークフロー・サービス・クライアントの選択

- 16.2.3 厳密なフィルタを使用した該当タスクの絞込み

- 16.2.4 該当タスクのサブセットの取得(ページング)

- 16.2.5 該当タスクに必要な情報のみのフェッチ

- 16.2.6 返される問合せ列の数の削減

- 16.2.7 集計APIを使用したタスク統計のチャート化

- 16.2.8 カウントAPIメソッドを使用したタスク数のカウント

- 16.2.9 フレックスフィールドの索引のオンデマンド作成

- 16.2.10 doesTaskExistメソッドの使用

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

- 16.3.1 完了したインスタンスの定期的なアーカイブ

- 16.3.2 適切なワークフロー・コールバック機能の選択

- 16.3.3 通知がパフォーマンスに与える影響の最小化

- 16.3.4 クラスタ・ノードのデプロイ

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

- 16.4.1 ワークフロー・レポートを使用した進捗状況の監視

- 16.4.2 エスカレーション・ルールの指定

- 16.4.3 ユーザー・ルールおよびグループ・ルールを指定した自動割当て

- 16.4.4 タスク・ビューを使用した作業の優先順位付け

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

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

17 Oracleアダプタのパフォーマンス・チューニング

- 17.1 Oracleアダプタについて

- 17.2 Oracle JCA Adapter for Files/FTP

- 17.2.1 インバウンド調整のベスト・プラクティス

- 17.2.2 アウトバウンド調整のベスト・プラクティス

- 17.2.3 アウトバウンド・パフォーマンスのベスト・プラクティス

- 17.3 Oracle JCA Adapter for Databaseのチューニング

- 17.3.1 JCAアダプタのチューニングに関する基本的な考慮事項

- 17.3.2 存在チェック

- 17.3.3 速度調整

- 17.3.3.1 計算式

- 17.3.3.2 RowsPerPollingIntervalとMaxTransactionSize

- 17.3.3.3 構成

- 17.4 Oracleソケット・アダプタのチューニング

- 17.5 Oracle SOA JMSアダプタのチューニング

- 17.5.1 adapter.jms.receive.threadsプロパティ

- 17.6 Oracle AQアダプタのチューニング

- 17.6.1 adapter.aq.dequeue.threadsプロパティ

- 17.7 Oracle MQアダプタのチューニング

18 Oracle Business Activity Monitoringのパフォーマンス・チューニング

- 18.1 Oracle Business Activity Monitoringについて

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

- 18.2.1 BAMサーバーのチューニング

- 18.2.1.1 ViewSetSharingパラメータおよびElementCountLimitパラメータの設定

- 18.2.1.2 非同期サーブレットの有効化

- 18.2.2 BAMダッシュボードのチューニング

- 18.2.2.1 アクティブ・データ取得間隔のチューニング

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

- 18.2.4 インターネット・ブラウザのチューニング

- 18.2.4.1 iActiveDataScriptsCleanupFactorの設定

- 18.2.4.2 ブラウザのキャッシュ設定

- 18.2.5 エンタープライズ・メッセージ・ソースのチューニング

- 18.2.5.1 メッセージのバッチ処理

19 User Messaging Serviceのパフォーマンス・チューニング

- 19.1 Oracle User Messaging Servicesについて

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

- 19.2.1 SMPPドライバのパフォーマンス・チューニング

- 19.2.2 電子メール・ドライバのポーリング頻度

- 19.3 データベース・チューニングによるスループットの最適化

20 Oracle B2Bのパフォーマンス・チューニング

- 20.1 Oracle B2Bについて

- 20.2 MDSキャッシュ・サイズ

- 20.3 スレッド数

- 20.4 JMSの複数のアウト・キュー設定

21 Oracle Service Busのパフォーマンス・チューニング

- 21.1 Oracle Service Busについて

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

- 21.2.1 JVMメモリーのチューニング

- 21.2.2 WebLogic Serverのチューニング

- 21.2.2.1 ドメイン・モード

- 21.2.2.2 WebLogic Serverのロギング・レベル

- 21.2.2.3 HTTPアクセス・ロギング

- 21.2.2.4 JMSのチューニング

- 21.2.2.5 接続バックログのバッファリング

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

- 21.3.1 OSBの監視

- 21.3.2 OSBのトレース

- 21.3.3 プロキシ・サービスの実行時データのキャッシュ・チューニング

- 21.4 トランスポート・チューニング(Oracle WebLogic ServerおよびOracle Service Bus)

- 21.4.1 ポーリング間隔

- 21.4.2 読取り制限

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

- 21.6 XQueryチューニングの設計の考慮事項

22 Oracle Business Intelligenceのパフォーマンス・チューニング

- 22.1 Oracle Business Intelligenceについて

- 22.2 Oracle BI Serverの問合せのパフォーマンス・チューニング

- 22.3 Oracle BI Serverの問合せキャッシュのパフォーマンス・チューニング

- 22.4 Oracle BI Webクライアントのパフォーマンス・チューニング

第V部 Identity Management Suiteコンポーネント

23 Oracle Internet Directoryのパフォーマンス・チューニング

- 23.1 Oracle Internet Directoryについて

- 23.2 Oracle Internet Directoryのチューニングの概要

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

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

- 23.3.2 LDAPサーバー属性

- 23.3.3 データベース統計

- 23.4 拡張構成

- 23.4.1 レプリケーションまたはOracle Directory Integration Platform

- 23.4.2 レプリケーション・サーバー構成

- 23.4.3 ガベージ・コレクション構成

- 23.4.4 Oracle Internet DirectoryとRACデータベース

- 23.4.5 パスワード・ポリシーとパスワード検証プロファイル

- 23.4.6 サーバー・エントリ・キャッシュ

- 23.4.6.1 エントリ・キャッシュを使用する条件

- 23.4.6.2 エントリ・キャッシュを使用する利点

- 23.4.6.3 エントリ・キャッシュを構成するための値

- 23.4.7 結果セット・キャッシュ

- 23.4.7.1 結果セット・キャッシュを使用する条件

- 23.4.7.2 結果セット・キャッシュを使用する利点

- 23.4.7.3 結果セット・キャッシュを構成するための値

- 23.4.8 セキュリティ・イベント追跡のチューニング

- 23.5 チューニングに関する優先度の低い考慮事項

- 23.5.1 検索で返されるエントリの数

- 23.5.2 グループ・キャッシュの有効化

- 23.5.3 書込み操作のタイムアウト

- 23.6 特殊なユースケース

- 23.6.1 バルク・ロード操作

- 23.6.2 バルク削除操作

- 23.6.3 負荷の高いLDAP書込み操作

- 23.7 検索の最適化

- 23.7.1 大きいグループ・エントリの検索の最適化

- 23.7.1.1 エントリ・キャッシュを有効にした構成

- 23.7.1.2 エントリ・キャッシュを無効にした構成

- 23.7.2 スキュー属性の検索の最適化

- 23.7.3 複雑な検索フィルタのパフォーマンスの最適化

- 23.8 UNIXシステムおよびWindowsシステムでのパフォーマンスの評価

- 23.9 チューニングとサイズ設定ウィザードを使用した推奨事項の取得

- 23.10 oidstats.sqlを使用したデータベース統計の更新

- 23.11 パフォーマンス関連のレプリケーション構成属性の設定

- 23.12 システム構成属性の管理

- 23.13 ガベージ・コレクション構成属性の設定

- 23.13.1 ldapmodifyを使用した変更ログ・パージ属性の変更

- 23.13.2 Oracle Directory Services Managerでの変更ログのパージの変更

24 Oracle Virtual Directoryのパフォーマンス・チューニング

- 24.1 Oracle Virtual Directoryについて

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

- 24.3 拡張チューニング構成

- 24.3.1 データベース・アダプタ

- 24.3.2 結合アダプタ

- 24.3.3 フィルタの一般的なチューニング

- 24.3.4 ロード・バランサのローカル・ストア・アダプタのチューニング

- 24.3.5 Cacheプラグインのチューニング

- 24.3.5.1 キャッシュ・ヒット・ロジック

- 24.3.5.2 Cacheプラグインのメモリー管理

- 24.3.6 LDAPリスナーのチューニング

- 24.3.7 サーバーのチューニング

25 Oracle Identity Federationのパフォーマンス・チューニング

- 25.1 Oracle Identity Federationについて

- 25.2 LDAPのチューニング

- 25.2.1 接続プール設定

- 25.2.2 接続設定

- 25.2.3 フェデレーション・データ・ストア設定

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

- 25.3.1 データ・ソース

- 25.3.2 RDBMSのセッション・キャッシュ

- 25.3.3 RDBMSの圧縮

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

- 25.5 SAMLプロトコルのチューニング

- 25.5.1 SOAP接続

- 25.5.2 XMLデジタル署名

- 25.5.3 シングル・サインオンのPOSTプロファイルおよびアーティファクト・プロファイル

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

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

- 26.2 一般的なパフォーマンスの問題の検出

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

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

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

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

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

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

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

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

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

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

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

- 26.4.5 Webサービスのパフォーマンスの監視

第VI部 Oracle WebCenterコンポーネント

27 Oracle WebCenter Portalのパフォーマンス・チューニング

- 27.1 Oracle WebCenter Portalについて

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

- 27.2.1 システム制限の設定

- 27.2.2 JDBCデータ・ソースの設定

- 27.2.3 JRockit仮想マシン(JVM)引数の設定

- 27.2.4 コンテンツの圧縮を使用したダウンロードの削減

- 27.3 WebCenter Portalアプリケーション構成のチューニング

- 27.3.1 Spacesアプリケーションのセッション・タイムアウトの設定

- 27.3.2 HTTPセッション・タイムアウトの設定

- 27.3.3 JSPページ・タイムアウトの設定

- 27.3.4 ADFクライアント状態トークンの設定

- 27.3.5 ADF表示状態圧縮の設定

- 27.3.6 MDSキャッシュ・サイズおよびパージ頻度の設定

- 27.3.7 同時実行性管理の構成

- 27.4 バックエンド・コンポーネント構成のチューニング

- 27.4.1 アナウンスメント・サービスのパフォーマンス・チューニング

- 27.4.2 ディスカッション・サービスのパフォーマンス・チューニング

- 27.4.3 インスタント・メッセージおよびプレゼンス(IMP)・サービスのパフォーマンス・チューニング

- 27.4.4 メール・サービスのパフォーマンス・チューニング

- 27.4.5 メール・サービスのパフォーマンス・チューニング

- 27.4.6 RSSニュース・フィード・サービスのパフォーマンス・チューニング

- 27.4.7 検索サービスのパフォーマンス・チューニング

- 27.4.8 ポリシー・ストアのパラメータのチューニング

- 27.5 ポートレット構成のチューニング

- 27.5.1 ポートレット・サービスのパフォーマンス・チューニング

- 27.5.2 ポートレット・キャッシュ・サイズの構成

- 27.5.3 WSRPプロデューサのJavaオブジェクト・キャッシュの有効化

- 27.5.4 WSRPポートレットのオプティミスティック・レンダリングの抑制

- 27.5.5 Oracle PDK-Javaプロデューサのパフォーマンス・チューニング

- 27.5.6 ポートレット・コンテナ・ランタイム・オプションの設定

- 27.5.7 ポートレットのDefaultServedResourceRequiresWsrpRewriteの設定

- 27.5.8 WSRPポートレットのDefaultProxiedResourceRequiresWsrpRewriteの設定

- 27.5.9 IFrameポートレットのコンシューマCSSファイルのインポート

- 27.5.10 ポートレット・タイムアウトの構成

- 27.5.11 OmniPortletのパフォーマンス・チューニング

第VII部 キャパシティ・プランニング、スケーラビリティおよび可用性

28 キャパシティ・プランニング

- 28.1 Oracle Fusion Middlewareのキャパシティ・プランニングについて

- 28.1.1 キャパシティ・プランニングの際に考慮する要因

- 28.2 パフォーマンス目標の決定

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

- 28.4 システムのボトルネックの特定

- 28.4.1 クラスタ構成の使用

- 28.4.2 接続プーリングの使用

- 28.4.3 JVMの最大ヒープ・サイズの設定

- 28.4.4 メモリーまたはCPUの増加

- 28.4.5 ネットワーク・トラフィックの分離

- 28.4.6 プロセスとハードウェア割込みハンドラの分離

- 28.5 キャパシティ管理計画の実施

- 28.5.1 ハードウェアの構成要件

- 28.5.1.1 CPU要件

- 28.5.1.2 メモリー要件

- 28.5.2 JVM要件

- 28.5.3 管理対象サーバー

- 28.5.4 データベース構成

29 クラスタおよび高可用性機能の使用

- 29.1 クラスタおよび高可用性機能について

- 29.2 Oracle Fusion Middlewareでのクラスタの使用

- 29.3 Oracle Fusion Middlewareでの高可用性機能の使用

索引

Oracle® Fusion Middleware

パフォーマンスおよびチューニング・ガイド

11g リリース1(11.1.1)

B61006-04(原本部品番号:E10108-06)

2012年3月

Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド, 11g リリース1(11.1.1)

B61006-04

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

原本著者: Lisa Jamen

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

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

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

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

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

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

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

はじめに

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

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

- 対象読者

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

- 表記規則

対象読者

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

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

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

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

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

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

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

Oracleサポートへのアクセス

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

表記規則

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

規則

意味

太字

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

イタリック体

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

固定幅フォント

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

第I部

概要

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

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

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

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

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

1 概要とロードマップ

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

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

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

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

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

『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』は、アプリケーション開発者、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 HTTP Serverのパフォーマンス・チューニング」では、Oracle Fusion MiddlewareのWebサーバー・コンポーネントであるOracle HTTP Serverのパフォーマンスを最適化する手法を説明します。Oracle WebLogic Serverのリスナーと静的ページ、動的ページおよびWeb上のアプリケーションのホスティングのフレームワークを提供します。

- 第6章「Oracle Dynamic Monitoring Serviceのパフォーマンス・チューニング」では、Oracle Dynamic Monitoring Service(DMS)の概要および使用可能な機能を示します。

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

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

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

- 第10章「Oracle Web Cacheのパフォーマンス・チューニング」では、Oracle Application Server Web Cache(Oracle Web Cache)のパフォーマンスを改善するための方法およびガイドラインを示します。Oracle Web Cacheは、コンテンツ認識型のサーバー・アクセラレータ(リバース・プロキシ)で、Oracle Fusion Middleware上で稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。

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

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

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

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

- 第15章「Oracle Business Process Managementのパフォーマンス・チューニング」では、接続性、ルーティング、仲介、管理および一部のプロセス編成機能を提供するOracle Service Bus (OSB)のチューニング方法について説明します。

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

- 第17章「Oracleアダプタのパフォーマンス・チューニング」では、Oracleアダプタをチューニングして最適なパフォーマンスを得る方法について説明します。Oracleテクノロジ・アダプタは、Oracle Application ServerおよびOracle Fusion Middlewareのコンポーネント(Oracle BPEL Process Manager(Oracle BPEL PM)やOracle Mediatorのコンポーネントなど)をファイルシステム、FTPサーバー、データベース・キュー(アドバンスト・キュー(AQ))、Java Message Services(JMS)、データベース表およびメッセージ・キュー(MQ Series)に統合します。

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

- 第19章「User Messaging Serviceのパフォーマンス・チューニング」では、User Messaging Serviceのチューニングのヒントを示します。Oracle User Messaging Service(Oracle UMS)を使用すると、ユーザーとデプロイ済アプリケーションの間で双方向通信が行えます。電子メール、IM、SMS、テキストから音声に変換したメッセージなど、様々なチャネルに対応しています。Oracle UMSは、Oracle BPEL PM、Oracle Human Workflow、Oracle BAM、Oracle WebCenterなどのOracle Fusion Middlewareコンポーネントと統合されています。

- 第20章「Oracle B2Bのパフォーマンス・チューニング」では、Oracle B2Bのチューニングのヒントを示します。Oracle B2Bは、企業と取引パートナ間における安全で信頼性の高いビジネス・ドキュメントの交信を可能にするE-Commerceゲートウェイです。Oracle B2Bは、Business-to-Businessのドキュメント標準、セキュリティ、トランスポート、メッセージング・サービス、および取引パートナ管理をサポートしています。Oracle B2BをOracle SOA Suiteコンポジット・アプリケーション内でバインディング・コンポーネントとして使用すると、エンドツーエンドのビジネス・プロセスを実装できます。

- 第21章「Oracle Service Busのパフォーマンス・チューニング」では、Oracle Service Busの基本的および高度なチューニングのヒントと設計に関する考慮事項を示します。

- 第22章「Oracle Business Intelligenceのパフォーマンス・チューニング」では、Oracle Business Intelligenceの基本的および高度なチューニングのヒントを示します。

- 第23章「Oracle Internet Directoryのパフォーマンス・チューニング」では、Oracle Internet Directoryのチューニングおよび構成の要件に関するガイドラインを示します。Oracle Internet DirectoryはLDAPバージョン3対応のサービスです。これを使用すると、分散したユーザー、ネットワーク構成、その他のリソースの情報を高速で取得し、一元的に管理することができます。

- 第24章「Oracle Virtual Directoryのパフォーマンス・チューニング」では、Oracle Virtual Directoryのチューニングのヒントを示します。Oracle Virtual DirectoryはLDAPバージョン3対応のサービスです。これを使用すると、1つ以上の企業データ・ソースを抽象化したビューが得られます。Oracle Virtual Directoryでは、複数のデータ・ソースが単一のディレクトリ・ビューに一体化されます。そのため、LDAP対応のアプリケーションを様々なディレクトリ・サーバー・データ・ストアと統合できます。

- 第25章「Oracle Identity Federationのパフォーマンス・チューニング」では、Oracle Identity Federationのチューニングのヒントを示します。Oracle Identity Federationは、複数ドメインからなるアイデンティティ・ネットワークでのシングル・サインオン(SSO)および認証を可能にする、スタンドアロンの自己完結型フェデレーション・サーバーです。

- 第26章「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セキュリティ実装です。この章では、最適なパフォーマンスを得るための構成方法について説明します。

- 第27章「Oracle WebCenter Portalのパフォーマンス・チューニング」では、環境の構成、アプリケーションの構成、バックエンド・サービスおよびサーバーの構成など、Oracle WebCenterのチューニングのヒントを示します。

- 第28章「キャパシティ・プランニング」では、アプリケーションのニーズを満たすために必要なハードウェアおよびソフトウェアの構成を決定するプロセスについて説明します。

- 第29章「クラスタおよび高可用性機能の使用」では、Oracle Fusion Middlewareコンポーネントのアーキテクチャ、相互作用および依存関係、ならびにコンポーネントを高可用性アーキテクチャにデプロイしてパフォーマンスを最大化する方法について説明します。

1.3 関連ドキュメント

詳細は、Oracle Fusion Middleware 11g リリース1(11.1.1)ドキュメント・セットに含まれる次のドキュメントを参照してください。

- 『Oracle Fusion Middleware管理者ガイド』

- 『Oracle Fusion Middleware 2日で管理者ガイド』

- 『Oracle Fusion Middleware概要』

- 『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』

- 『Oracle Fusion Middleware高可用性ガイド』

- 『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』

- 『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』

- 『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』

- 『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』

- 『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

- 『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』

- Oracle Fusion Middleware Oracle Identity Federationの管理者ガイド

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

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

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

JVMをどのようにチューニングするかによって、Oracle Fusion Middlewareおよびアプリケーションのパフォーマンスが大きく変わります。

注意:

JVMのパフォーマンスを最大化するために、アプリケーションが認定されている製品版のJVMのみを使用してください。また、最新のオペレーティング・システム・パッチを適用してください。

Supported Configurationsページ(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)には、各種プラットフォームにおける最新の認定情報が掲載されています。このページは頻繁に更新されます。

この項では、JVMの次のパフォーマンス・チューニング分野について説明します。

- ガベージ・コレクションの構成

- 低メモリー状態のロギング

- JVMの監視およびプロファイリング

2.4.1 ガベージ・コレクションの構成

ガベージ・コレクションは、Javaヒープ内の使用されていないJavaオブジェクトを解放するJVMプロセスです。JVMガベージ・コレクションは、リソースを大量に消費する処理であり、アプリケーションのパフォーマンスに影響を与えます。非効率的なガベージ・コレクションは、アプリケーションのパフォーマンスを大幅に低下させる可能性があります。したがって、アプリケーションでオブジェクトがどのように生成され、破棄されるかを理解しておくことが重要です。

この項では、ガベージ・コレクションに関連する次のチューニング・オプションについて説明します。

- ヒープ・サイズ値の指定

- ガベージ・コレクション方式の選択

- 明示的ガベージ・コレクションの無効化

ガベージ・コレクションの許容される頻度はアプリケーションによって異なるため、ガベージ・コレクションの実際の所要時間および頻度を分析して調整する必要があります。大きなヒープ・サイズを設定した場合、フル・ガベージ・コレクションは低速化しますが、発生頻度が低くなります。ヒープ・サイズをメモリーのニーズに合せて設定した場合、フル・ガベージ・コレクションは高速化しますが、発生頻度が高くなります。

JVMガベージ・コレクションのオプションをチューニングする場合は、ガベージ・コレクション・データを分析し、ガベージ・コレクションの頻度およびタイプ、メモリー・プールのサイズ、ならびにガベージ・コレクションの所要時間を確認してください。

JVMガベージ・コレクションを構成する前に、次の点を分析します。

1. ガベージ・コレクションの発生頻度。ガベージ・コレクション前後のタイム・スタンプを比較します。

2. フル・ガベージ・コレクションの所要時間。

3. 各フル・ガベージ・コレクション後のヒープ・サイズ。たとえば、ヒープの85%が常に空いている場合は、ヒープ・サイズを小さくしてもかまいません。

4. Young世代のヒープ・サイズ(Sun)またはナーサリのサイズ(JRockit)をチューニングする必要があるか。

verboseガベージ・コレクション・ロギングを使用すると、ガベージ・コレクションおよびメモリー・プールのサイズを手動でログに記録できます。

- Sun JVMコマンドライン・オプション:

-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps

主要なコレクションを特定するには、Full GC行を探します。

- その他のSunツール:

- JStat

- JConsole

- Visualgc

Sunのオプションの詳細は、http://java.sun.com/javase/technologies/hotspot/gc/index.jspを参照してください。

- JRockit JVMコマンドライン・オプション:

-XXverbose:gc

注意: この他にも、JRockit VMのパフォーマンスを改善するコマンドライン・オプションが用意されています。詳細は、JRockit JDKコマンドライン・オプションの名前順リスト(http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html)を参照してください。

- その他のJRockitツール:

- JRockit Runtime Analyzer(jra recording)

- JRockit Management Console(jrmc)

- JRockitメモリー・リーク・ディテクタ

2.4.1.1 ヒープ・サイズ値の指定

ヒープ・サイズをチューニングする目的は、ガベージ・コレクションの所要時間を最小限に抑えながら、Fusion Middlewareスタックが一度に処理できるクライアントの数を最大化することです。

Javaヒープというのは、Javaプログラムのオブジェクトが存在する場所です。ライブ・オブジェクト、デッド・オブジェクトおよび空きメモリーのリポジトリであるとも言えます。実行中のプログラムで、どのポインタからもオブジェクトにアクセスできなくなると、そのオブジェクトはガベージとみなされ、コレクションの対象となります。ベスト・プラクティスとしては、ガベージ・コレクションの所要時間が実行時間の5%以内になるようにチューニングします。

JVMヒープ・サイズによって、ガベージ・コレクションの頻度と所要時間が決まります。ガベージ・コレクションの許容される頻度はアプリケーションによって異なるため、ガベージ・コレクションの実際の所要時間および頻度を分析して調整する必要があります。大きなヒープ・サイズを設定した場合、フル・ガベージ・コレクションは低速化しますが、発生頻度が低くなります。ヒープ・サイズをメモリーのニーズに合せて設定した場合、フル・ガベージ・コレクションは高速化しますが、発生頻度が高くなります。

本番環境では、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定し、ヒープを絶えず拡大縮小するために仮想マシンのリソースが無駄に費やされるのを防ぎます。システムで稼働しているすべてのJVMの最大ヒープ・サイズの合計が、使用可能な物理RAMのサイズを超えないようにしてください。この値を超えると、オペレーティング・システムがページングを開始するため、パフォーマンスが大幅に低下します。仮想マシンは常にヒープ・サイズより多くのメモリーを使用します。ヒープ・サイズの設定に加えて、仮想マシンの内部機能に必要なメモリー、仮想マシン外部のネイティブ・ライブラリに必要なメモリー、および永続世代メモリー(クラスおよびメソッドの格納に必要なメモリー)が割り当てられます。

たとえば、次のJVMオプションを使用してヒープをチューニングできます。

- ヒープ・メモリーが不足している(メモリー・リークが原因ではない)場合は、-Xmxを大きくします。

- ネイティブ・メモリーが不足している場合は、-Xmxを小さくする必要があります。

- Oracle JRockitでは、-Xns:<nursery size>を変更してナーサリのサイズをチューニングします。

- Sun JVMでは、-Xmnを変更してYoung世代のヒープのサイズをチューニングします。
java.lang.OutOfMemoryError: PermGen spaceエラーが発生した場合は、永続世代の領域を増やすことも必要です。

関連項目:

Young世代のチューニングの詳細は、『Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning』のYoung世代に関する項(http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#generation_sizing.young_gen)を参照してください。

Oracle JRockitでのヒープ構成の詳細は、診断ガイドのヒープおよびナーサリのサイズ設定に関する項(http://download.oracle.com/docs/cd/E13188_01/jrockit/geninfo/diagnos/memman.html)を参照してください。

SunのJava仮想マシンについては、『Monitoring and Managing Java SE 6 Platform Applications』のメモリー不足に関する項(http://java.sun.com/developer/technicalArticles/J2SE/monitoring/index.html#Insufficient_Memory)を参照してください。

『Frequently Asked Questions』のメモリー不足に関する項(http://java.sun.com/docs/hotspot/HotSpotFAQ.html#gc_oom)

2.4.1.2 ガベージ・コレクション方式の選択

システム・メモリーの管理に使用するガベージ・コレクション方式は、使用しているJVMに応じて、複数の中から選択できます。アプリケーションのタイプによって、最適なガベージ・コレクション方式は異なります。アプリケーションのワークロードやJVMが利用する各種ガベージ・コレクション・アルゴリズムについて理解すれば、ガベージ・コレクションの構成を最適化できるようになります。

各JVMのガベージ・コレクション・オプションについては、次のリンクを参照してください。

- Sun社のHotSpot VMで利用可能なガベージ・コレクション方式の概要は、『Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning』(http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html)を参照してください。

- 利用可能なコレクション方式についての総合的な説明は、『Memory Management in the Java HotSpot(tm) Virtual Machine』(http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf)を参照してください。

- JRockit JDKで利用可能なガベージ・コレクション方式については、JRockitのメモリー管理システムの使用方法に関する項(http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html)を参照してください。

2.4.1.3 明示的ガベージ・コレクションの無効化

次のパラメータは、明示的ガベージ・コレクションが発生しているかどうかの診断に使用します。必要な場合は、これらを使用して、コードが修正されるまで明示的ガベージ・コレクションを無効にすることもできます。

- Sunの仮想マシンの場合は、-XX:+DisableExplicitGCを使用します。
明示的ガベージ・コレクションの使用の詳細は、『Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning』(http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html)を参照してください。

- Oracle JRockit仮想マシンの場合は、-XXnoSystemGCを使用します。
Oracle JRockitのチューニングの詳細は、http://download.oracle.com/docs/cd/E13188_01/jrockit/geninfo/diagnos/bestpractices.htmlを参照してください。

これらのパラメータを指定すると、明示的ガベージ・コレクションが無効になります。アプリケーションでsystem.gc()コールを使用することは避ける必要があります。アプリケーションがガベージ・コレクションを明示的にトリガーしていると思われる場合は、このパラメータを設定し、ガベージ・コレクションの動作の違いを観察してください。パフォーマンスが明示的ガベージ・コレクションの影響を受けているとわかった場合は、コードをチェックし、明示的ガベージ・コレクションが使用されている場所とその理由、およびコールを無効にした場合の影響を調べます。アプリケーション開発者は、ファイナライザをトリガーする目的でsystem.gc()コールを使用することがあります。これは望ましい使用方法ではなく、予測できない動作を生む原因となります。

2.4.2 低メモリー状態のロギング

WebLogic Serverでは、サーバーで観察された低メモリー状態を自動的にログに記録できます。低メモリーを検出するために、使用可能な空きメモリーが一定時間内にあらかじめ設定した回数だけサンプリングされます。各サンプリング期間の最後に、空きメモリーの平均が記録され、次のサンプリング期間に得られた平均と比較されます。サンプリング期間の後、ユーザーがあらかじめ設定した量だけ平均が低下した場合は、低メモリーを示す警告メッセージがログ・ファイルに記録され、サーバーの状態が「警告」に設定されます。

関連項目:

WebLogic Serverを使用した低メモリー状態の検出の詳細は、次のドキュメントを参照してください。

Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「低メモリー状態のログへの記録」

『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の低メモリー状態の自動的なロギングに関する項

2.4.3 JVMの監視およびプロファイリング

JVMのパフォーマンスを監視することは、最適なパフォーマンスを得るうえで不可欠です。ご使用のプラットフォームに応じて、次のツールを使用してJVMの監視およびプロファイリングを行います。

- Oracle JRockit® Mission Control
Oracle JRockit Mission Controlは、Javaアプリケーションにおけるメモリー・リークの監視、管理、プロファイリングおよび解消を目的とするツール・スイートです。このタイプのツールによくあるように、パフォーマンスに影響を与えることはありません。

Oracle JRockit Mission Controlの詳細は、http://download.oracle.com/docs/cd/E13188_01/jrockit/tools/index.htmlを参照してください。

- Sun JVM
Java(tm)プラットフォームには、次の監視機能が組み込まれています。

- Java仮想マシン監視および管理API

- JConsole

- Hprofツール

- ロギング、監視および管理用インタフェース

- Java Management Extensions(JMX)

Javaプラットフォーム・モニタリング・ツールの詳細は、http://java.sun.com/developer/technicalArticles/J2SE/monitoring/を参照してください。

2.5 WebLogic Serverのチューニング

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

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

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

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

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

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

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

注意:

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

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

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

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

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

次に示す変更を加える前に、パッチ・セット・リリース(PSR)11.1.0.7の適用を検討し、データベースをアップグレードしてください。

2.6.1.1 Oracle 10gの初期化パラメータ

次の表では、Oracle 10gデータベースのパフォーマンスに関連するデータベース初期化パラメータについて説明します。次に示すチューニングの考慮事項は、ほとんどのシナリオに当てはまります。必ず、データベース・パラメータは各自のユースケース・シナリオに基づいて設定してください。

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

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

説明

_b_tree_bitmap_plans

このパラメータをFALSEに設定して、Fusion Middlewareにビットマップ索引がないときにオプティマイザがビットマップ操作を試行しないようにすることを検討してください。

DB_BLOCK_SIZE

DB_BLOCK_SIZEには、Oracleデータベース・ブロックのサイズ(バイト)を指定します。ほとんどのシステムでは、デフォルトのブロック・サイズである8Kが最適です。このパラメータはデータベース作成時に設定します。

NLS_SORT

NLS_SORTをBINARYに設定することを検討してください。そうしない場合、ソートによって全表スキャンが実行されるため、パフォーマンスが影響を受ける場合があります。

OPEN_CURSORS

1つのセッションで同時にオープンできるカーソル(プライベートSQL領域に対するハンドル)の値として500を使用することを検討してください。

SESSION_CACHED_CURSORS

キャッシュするセッション・カーソルの値として500を使用することを検討してください。

SESSION_MAX_OPEN_FILES

SESSION_MAX_OPEN_FILESには、セッションでオープン可能なBFILEの最大数を指定します。この数値に達した後は、DBMS_LOB.FILEOPEN()またはOCILobFileOpen()を使用して、セッションでそれ以上ファイルをオープンしようとすると失敗します。このパラメータの最大値は、基礎となるオペレーティング・システムで定義されている同等のパラメータに依存します。

JOB_QUEUE_PROCESSES

JOB_QUEUE_PROCESSESには、ジョブ実行用に作成可能なプロセスの最大数を指定します。これは、1インスタンス当たりのジョブ・キュー・プロセスの数を示しています。

LOG_BUFFER

LOG_BUFFERには、REDOエントリをREDOログ・ファイルにバッファする際に使用されるメモリーの量(バイト)を指定します。REODログ・エントリには、データベース・ブロック・バッファに加えられた変更のレコードが含まれています。REDOログ・エントリは、LGWRプロセスによってログ・バッファからREDOログ・ファイルに書き込まれます。

UNDO_MANAGEMENT

UNDO_MANAGEMENTには、システムで使用されるUNDO領域管理モードを指定します。AUTOに設定すると、インスタンスは自動UNDO管理モードで起動されます。手動UNDO管理モードの場合、UNDO領域はロールバック・セグメントとして外部的に割り当てられます。

PL_SQL_CODE_TYPE

PL_SQL_CODE_TYPEをNATIVEに設定することを検討してください。

PROCESSES

Oracleに同時に接続するオペレーティング・システム・プロセスの値として5000を使用することを検討してください。

PGA_AGGREGATE_TARGET

PGA_AGGREGATE_TARGETを、インスタンスにアタッチされるすべてのサーバー・プロセスで使用可能なPGAメモリーの値である1Gに設定することを検討してください。

SGA_MAX_SIZE

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

SGA_TARGET

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

TRACE_ENABLED

TRACE_ENABLEDは、Oracleの実行履歴(コード・パス)のトレースを制御します。Oracleサポート・サービスでは、この情報をデバッグに利用しています。

処理によって生じるパフォーマンス上の影響は大きくありませんが、TRACE_ENABLEDをFALSEに設定するとパフォーマンスを改善できることがあります。

2.6.1.2 Oracle 11gの初期化パラメータ

次の表では、Oracle 11gデータベースのパフォーマンスに関連する重要なデータベース初期化パラメータについて説明します。

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

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

説明

AUDIT_TRAIL

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

MEMORY_MAX_TARGET

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

MEMORY_TARGET

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

PGA_AGGREGATE_TARGET

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

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

SGA_MAX_SIZE

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

SGA_TARGET

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

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

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

データベースI/Oのロード・バランシングを管理することは、簡単な作業ではありません。しかし、REDOログ・オプションをチューニングすれば、Oracle Fusion Middleware環境で稼働しているアプリケーションのパフォーマンスを改善できます。また、REDOログを別のディスクに移動することで、I/Oスループットを大幅に改善できる場合もあります。

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

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.9 同時実行性の制御

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

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

- 「HTTP接続制限の設定」

- 「接続プールの構成」

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

- Oracle WebCenterの同時実行性のチューニング

- BPELの同時実行性のチューニング

2.9.1 HTTP接続制限の設定

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

httpd.confファイルの変更の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの構成に関する項を参照してください。

MaxClientsディレクティブおよびThreadsPerChildディレクティブを使用すると、予想されるクライアント負荷およびシステム・リソースに基づいて、Oracle HTTP ServerからWebLogicインスタンスへの受信リクエストを制限できます。次の各項では、接続制限に関連するOracle HTTP Serverチューニング・パラメータについて説明します。これらは通常、予想されるクライアント負荷に基づいてチューニングする必要があります。詳細とチューニング可能なパラメータの詳しいリストは、第5章「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構成プロパティの説明は、表5-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 MOD_WL_OHSのチューニング

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

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

2.9.2 接続プールの構成

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

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

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

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

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

関連項目:

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

『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のプール・サイズのチューニングに関する項

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

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

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

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

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

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

ワーク・マネージャおよびスレッド・プールのメトリックは、Oracle Fusion Middleware Controlからも確認できます。詳細は、4.2.1項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの確認」を参照してください。

2.9.4 Oracle WebCenterの同時実行性のチューニング

Oracle WebCenterには、同時実行性を管理するための独自のコントロールがあります。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』の同時実行性管理の構成に関する項を参照してください。

2.9.5 BPELの同時実行性のチューニング

Oracle BPEL Process Managerには、独自のスレッド・コントロールと特殊なチューニング機能が用意されています。13.2.1項「BPELスレッド・モデル」を参照してください。

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

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

- ピーク使用量やレスポンス時間に対応した高可用性アーキテクチャの構成。Oracle Fusion Middlewareアプリケーションに高可用性機能を実装する方法の詳細は、第29章「クラスタおよび高可用性機能の使用」を参照してください。

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

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

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

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-1 キャパシティおよび機能面での需要の調整」の説明

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

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

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

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

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

推奨される設計手法の詳細は、次のOracle Fusion Middleware開発者向けドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』

- 『Oracle Fusion Middleware Oracle WebCenter Portal開発者ガイド』

- 『Oracle Fusion Middleware Oracle TopLink開発者ガイド』

- 『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド』

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

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

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

関連項目:

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

『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』

『Oracle Fusion Middleware管理者ガイド』

4 Oracle Fusion Middlewareの監視

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

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

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

- 4.2項「Oracle Enterprise Manager 11g Fusion Middleware Control」

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

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

- 4.5項「WebLogic Scripting Tool(WLST)」

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

- 4.7項「Oracle Process Manager and Notification Server」

- 4.8項「Oracle Enterprise Manager 11g Grid Control」

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

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

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

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

Oracle Fusion Middleware環境の管理には、次のツールが使用できます。

- Oracle Enterprise Manager Fusion Middleware Control。4.2項を参照してください。

- Oracle WebLogic Server管理コンソール。4.3項を参照してください。

- Oracle WebLogic診断フレームワーク(WLDF)。4.4項を参照してください。

- Oracle WebLogic Scripting Tool(WLST)。4.5項を参照してください。

- DMSスパイ・サーブレット。4.6項を参照してください。

- Oracle Process Manager and Notification Server。4.7項を参照してください。

- Oracle Enterprise Manager 11g Grid Control。4.8項を参照してください。

- オペレーティング・システムのパフォーマンス・コマンド。4.9項を参照してください。

- ネットワーク・パフォーマンス・モニタリング・ツール。4.10項を参照してください。

特定の手順でファイルの編集が必要になる場合以外は、構成ファイルを直接編集するのではなく、これらのツールを使用してすべての管理タスクを実行します。ファイルを編集すると、設定の一貫性が失われ、問題が発生する可能性があります。

Fusion Middleware ControlとOracle WebLogic Server管理コンソールはどちらも、Oracle Fusion Middleware環境の監視および管理に使用できるグラフィカル・ユーザー・インタフェースです。一部の作業はどちらのツールでも実行できますが、それ以外の作業にはいずれか一方のツールしか使用できません。

WebLogic Server管理コンソールを使用したドメインの監視の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

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.1項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示」を参照してください。

4.2 Oracle Enterprise Manager 11g Fusion Middleware Control

Fusion Middleware Controlは、ファームの監視および管理に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。Fusion Middleware Controlでは、ファーム、ドメイン、サーバー、コンポーネントおよびアプリケーションについて、幅広いパフォーマンス・データと管理機能がWebベースの個別のホームページにまとめられています。The Fusion Middleware Controlのホームページでは、最も重要な監視データおよび最も使用頻度の高い管理機能を各自のWebブラウザから簡単に検索できます。

さらに、Fusion Middleware Controlには一連のMBeanブラウザが用意されています。これを使用すれば、WebLogic Serverまたは選択したアプリケーションのMBeanを参照して、特定の監視作業や構成作業を実行できます。

関連項目:

『Oracle Fusion Middleware管理者ガイド』のOracle Enterprise Manager Fusion Middleware Controlの使用開始に関する項

Fusion Middleware Controlを使用すると、次のことが行えます。

- 単一のFusion Middlewareファームの監視および管理

- ファームのすべての要素(デプロイ済アプリケーションと次のようなFusion Middlewarコンポーネントを含む)の監視

- WebLogicドメイン

- クラスタおよび管理対象サーバー

- SOAコンポーネント

- Web Center

- Webキャッシュ

- Oracle HTTP Server

- Oracle Identity Management

- デフォルトのパフォーマンス・メトリックを使用した、各ターゲットの状態およびパフォーマンスの監視

- Oracle WebLogic ServerのCPU使用率、ヒープ使用率、ワーク・マネージャ、JMSサーバー、JDBCおよびJTAの使用率の監視

- ヒープ使用率とヒープ以外の使用率の比較、ガベージ・コレクションおよびスレッド・パフォーマンスの観点から見た、JVMのパフォーマンスの監視

- WebLogic ServerにデプロイされたアプリケーションおよびWebサービスの監視

- 使用可能なサーブレット、JSPおよびEJBについての各種アプリケーション・メトリックと、フォルト、呼出しおよび違反についてのWebサービス・メトリックの監視。このようなメトリックには、ターゲットのホームページからアクセスできます。

- 管理者がパフォーマンスおよび診断の問題を監視できる、カスタマイズ可能な「パフォーマンス・サマリー」ページへのアクセス。これらのグラフは、自分のドメインに関係のある内容が表示されるように変更できます。グラフにターゲット、つまりコンポーネントを追加して、1つのグラフで2つのターゲットのパフォーマンス情報を比較することも可能です。

関連項目:

「パフォーマンス・サマリー」ページを使用した環境の監視の詳細は、『Oracle Fusion Middleware管理者ガイド』の、Oracle Fusion Middlewareのパフォーマンスの表示に関する項を参照してください。

4.2.1 Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示

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

個々のパフォーマンス・メトリックの定義を調べるには、Fusion Middleware Controlオンライン・ヘルプを使用します。この情報にアクセスする方法は2つあります。

- Fusion Middleware Controlオンライン・ヘルプでメトリックを参照するか、検索します。

- Oracle Fusion Middlewareコンポーネントまたはアプリケーションの「パフォーマンス・サマリー」ページに移動し、次の操作を実行します。

1. 「メトリック・パレットの表示」をクリックします。

2. コンポーネントまたはアプリケーションに対して使用可能なメトリックのリストを参照し、個々のメトリックを見つけます。

3. メトリックの名前を右クリックし、コンテキスト・メニューから「ヘルプ」を選択します。

アプリケーションの実行に時間がかかる、アプリケーションがハングしている、などの問題が発生した場合は、特定のターゲットのパフォーマンス・メトリックなど、さらに詳しいパフォーマンス情報を参照して、問題の詳細を確認することができます。

Oracle Fusion Middlewareでは、実行時のパフォーマンスが絶えず自動的に測定されます。パフォーマンス・メトリックは自動的に有効になります。パフォーマンス・メトリックを収集するためにオプションを設定したり、追加構成を行ったりする必要はありません。履歴データを参照する必要がある場合は、Oracle Enterprise Manager Grid Controlの使用を検討してください。詳細は、『Oracle Enterprise Manager概要』のミドルウェア管理に関する項を参照してください。

4.3 Oracle WebLogic Server管理コンソール

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

関連項目:

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

WebLogic Server管理コンソールを使用すると、次のことが行えます。

- WebLogic Serverインスタンスの構成、起動および停止

- WebLogic Serverクラスタの構成および監視

- データベース接続(JDBC)やメッセージング(JMS)といったWebLogic Serverサービスの構成および監視

- セキュリティ・パラメータの構成(ユーザー、グループおよびロールの作成や管理など)

- Java EEアプリケーションの構成およびデプロイ

- サーバーおよびアプリケーションのパフォーマンスの監視

- サーバーおよびドメインのログ・ファイルの表示

- アプリケーション・デプロイメント・ディスクリプタの表示

- ランタイム・アプリケーション・デプロイメント・ディスクリプタの選択した要素の編集

Oracle WebLogic Serverは、Java Management Extensions(JMX)サーバー実装を含んでおり、独自の管理Bean(MBean)のセットを提供します。この章で説明するOracle管理ツールは、WebLogic Serverが提供するMBeanを使用して、WebLogic Serverリソースの構成、監視および管理を可能にしています。

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

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

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

Oracle Technology Network(http://www.oracle.com/technology/index.html)では、WebLogic Serverの製品ダウンロード、記事、サンプル・コード、製品ドキュメント、チュートリアル、ホワイト・ペーパー、ニュース・グループ、その他の重要なコンテンツを利用できます。

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

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

WLDFには、データの収集および分析用のコンポーネントがいくつかあります。

- データ・クリエータ - WLDFコンポーネント全体に分散されるデータ・パブリッシャおよびデータ・プロバイダ。

- 診断イメージ・キャプチャ: 障害発生後の分析に使用できる診断スナップショットをサーバーから生成します。

- アーカイブ: サーバー・インスタンスとアプリケーションからデータ・イベント、ログ・レコードおよびメトリックを取得し、永続化します。

- インスツルメンテーション: WebLogic Serverインスタンスとその上で稼働しているアプリケーションに診断コードを追加し、コード内の指定した場所で診断処理を実行します。インスツルメンテーション・コンポーネントは、診断コンテキストをリクエストに関連付けて、システムを通過するリクエストの追跡ができるようにするための手段となります。

- ハーベスタ: WebLogic Server MBeanやカスタムMBeanなどのランタイムMBeanからメトリックを取得します。取得したメトリックは、アーカイブしておき、後で履歴データを参照する際にアクセスすることができます。

- 監視と通知: サーバーおよびアプリケーションの状態を監視し、監視内容の中に設定された条件に基づいて通知を送信するための手段となります。(監視ルールに従って監視できるのは、ログ・データ、インスツルメンテーション・コンポーネントのイベント・データ、またはハーベスタによって取得されるデータ・プロバイダのメトリック・データです。監視マネージャでは、複数の監視ルールで構成される監視内容を管理できます。)

- ロギング・サービス: サーバー、サブシステムおよびアプリケーションのイベントを監視するためのログを管理します。

これらのコンポーネントの関係を図4-1に示します。

図4-1 WLDFの主要コンポーネント

「図4-1 WLDFの主要コンポーネント」の説明

フレームワークのコンポーネントはすべて、サーバー・レベルで機能し、サーバーの範囲のみを認識しています。すべてのコンポーネントが完全にサーバー・プロセス内部に存在し、サーバーの標準的なライフサイクルに関与します。フレームワークのアーティファクトはすべて、サーバー単位で構成され、格納されます。

注意:

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

4.5 WebLogic Scripting Tool(WLST)

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

WLSTのコマンドは、次のいずれかの方法で呼び出すことができます。

- コマンドラインでの対話的な呼出し

- スクリプト・モードでのファイルへの指定

- Javaコードへの埋込み

関連項目:

- Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンス

- 『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項

4.5.1 カスタムWLSTコマンドの使用

Oracle SOA Suite、Oracle Platform Security Services(OPSS)、Oracle Fusion Middleware監査フレームワーク、MDSといった多くのコンポーネントや、SSL、ロギングなどのサービスには、カスタムWLSTコマンドが用意されています。

これらのカスタムWLSTコマンドを使用するには、コンポーネントがインストールされているOracleホームからWLSTを起動する必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

4.5.1.1 システム・コンポーネント用のWLSTコマンドの使用

WLSTには、Oracle WebLogic Server用のコマンドに加えて、システム・コンポーネントの監視および管理を目的とするコマンドのサブセットもあります。システム・コンポーネント用のコマンドは次のとおりです。

- startproc(componentName [, componentType] [, componentSet): 指定されたコンポーネントを起動します。

- stopproc(componentName [, componentType] [, componentSet): 指定されたコンポーネントを停止します。

- status(componentName [, componentType] [, componentSet): 指定されたコンポーネントのステータスを取得します。

- proclist(): コンポーネントのリストを取得します。

- dumpMetrics([servers,] [format]): 使用可能なメトリックを内部形式、PDML形式またはXML形式で表示します。

- displayMetricTables([metricTable_1], [metricTable_2], [...,] [servers] [variables]): DMSメトリック表の内容を表示します。

- displayMetricTableNames([servers]): 使用可能なDMSメトリック表の名前を表示します。戻り値は、メトリック表の名前を含む文字列配列です。

注意:

dmstoolコマンドは、dumpMetrics、displayMetricTablesおよびdisplayMetricTableNamesコマンドに代わりました。DMS WLSTコマンドの詳細は、Oracle Fusion Middleware WebLogic Scripting Toolのコマンド・リファレンスのDMSカスタムWLSTコマンドに関する項を参照してください。

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

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

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

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

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

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

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

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

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

「図4-2 スパイ・サーブレット・ページ - メトリック表」の説明

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

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

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

図4-3 MDS_Partition表

「図4-3 MDS_Partition表」の説明

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

4.7 Oracle Process Manager and Notification Server

Oracle Process Manager and Notification Server(OPMN)は、Oracle Fusion Middlewareコンポーネントのステータスを監視します。また、コンポーネントの起動および停止、システム・コンポーネントの監視、ならびにプロセス管理に関連するその他多くの作業も実行できます。たとえば、OPMNを使用して、Oracle HTTP ServerやOracle Web CacheといったOPMN管理プロセスの起動および停止を行うことができます。OPMNコマンドの詳細は、5.5.5項「Oracle HTTP Serverの監視」を参照してください。

注意:

OPMNの使用の詳細は、『Oracle Fusion Middleware Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

4.8 Oracle Enterprise Manager 11g Grid Control

Fusion Middleware Controlを使用すると単一のFusion Middlewareファームのパフォーマンスをリアルタイムに監視できるのに対し、Oracle Enterprise Manager 11g Grid Controlでは、データ・センターのその他の要素(基礎となるホストやオペレーティング・システム、データベース、Oracle E-Business SuiteやSiebelのようなパッケージ・アプリケーション、F5 BIG_IP Local Traffic Managerのようなサード・パーティ製品など)とともに、複数のファームを一元的に管理できます。

注意:

Grid Controlは、Fusion Middlewareをインストールすると自動的に使用可能になるわけではありません。別途インストールする必要があります。Grid Controlのインストール方法の詳細は、Oracle Enterprise Manager 11g Grid Controlのインストレーションおよびアドバンスト構成ガイドを参照してください。

Grid Controlの主な機能の中で、Fusion Middlewareのパフォーマンス監視に利用できる機能、および関係のある機能は次のとおりです。

- 単一コンソールから複数のWebLogic Serverドメインを監視。

- 特別な設定をしなくても可用性およびパフォーマンスの監視が可能

- 可用性およびパフォーマンスをリアルタイムに、また履歴に基づいて監視

- 主要パフォーマンス・メトリックに対して警告のしきい値およびクリティカルのしきい値を指定

- メトリックのしきい値に達したときに電子メールまたはページャ(あるいはその両方)による通知を受信

- 収集したパフォーマンス情報に対して傾向分析を実行

- Application Diagnostics for Java(AD4J)。アプリケーションのインスツルメンテーションを行わなくても稼働状態を診断できます。AD4Jの画面を次に示します。
図ad4j.gifの説明

AD4Jの主な機能は次のとおりです。

- メソッド、スタックおよびスレッドの状態の完全な可視化

- 実行中のコードのうち、コストの高いものをすばやくランク付けして、ボトルネックを特定

- コード行の粒度

- 複数の層にまたがったデータベースとEJB/RMIの相関関係

- Javaスレッドのロックおよび同期の検出

- スレッド・アクティビティのトレース

- ヒープのスナップショットおよび分析

- ヒープの差分分析によるメモリー・リークの迅速な切分け

- しきい値ベースのアラート

- SNMPトラップ、SMTPまたはHTTPリクエストによるアラート処理

- Composite Application Monitor and Modeler(CAMM)では、ポータル、BPEL、ESB、OSB、Webサービスといった複雑なコンポジット・サービスのアプリケーション・サービス管理が可能です。CAMMの画面を次に示します。
図camm.gifの説明

CAMMの主な機能は次のとおりです。

- 複雑なサービス(ポータル、BPEL、ESB、OSB、Webサービス)の自動検出

- 自動メタデータ分析と監視インスツルメンテーション構成

- SOAサービスとエンドポイントの間のランタイム依存性分析

- 固有の用語を使用して監視対象となるターゲットを表すメタデータ・モデル

- インバウンド・リクエストの到着および完了に基づいた呼出しメトリック

- レスポンス時間の平均値、最大値および最小値のメトリック

- 長期的な格納および傾向分析を目的とする階層型データ集計

- 任意の日付/時刻範囲に対する履歴ビュー

- 任意の2つの日付/時刻範囲を同時にスクロールしながら比較する比較ビュー

- 任意のグラフ、表および機能ビューを組み合せたカスタム・ビュー

- カスタマイズ可能なカスタム・ビュー階層

- 任意のメトリックに関するしきい値ベースのアラート(個別および集計)

- SNMPトラップ、SMTP、ロギングまたはカスタム・スクリプトによるアラート処理

- Real User Experience Insight(RUEI)では、アプリケーションの実際のエンドユーザー体験を把握できます。アプリケーションのインスツルメンテーションは不要です。RUEIの画面を次に示します。
RUEIの主な機能は次のとおりです。

- パフォーマンス低下の再現

- エグゼクティブ・ダッシュボード

- KPIおよびSLAの幅広い監視

- 完全なアラート機能

- 迅速なボトルネック分析

- トランザクション・パフォーマンス分析

- カスタマイズ可能なレポート

- 傾向分析

- XMLによる完全なデータ統合

図reui.gifの説明

注意:

Oracle Enterprise Manager 10g Grid Controlで使用可能な監視機能の詳細は、Oracle Technology Network(http://www.oracle.com/technology/documentation/oem.html)から入手できるOracle Enterprise Manager 10g Grid Controlのドキュメントを参照してください。

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

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

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

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

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

第II部

コア・コンポーネント

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

- 第5章「Oracle HTTP Serverのパフォーマンス・チューニング」

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

注意:

Oracle WebLogic Serverのパフォーマンス・チューニングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』を参照してください。

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

この章では、Oracle HTTP Serverのパフォーマンスを最適化する手法について説明します。この章の内容は次のとおりです。

- 5.1項「Oracle HTTP Serverについて」

- 5.2項「Oracle HTTP Serverディレクティブのチューニングに関する考慮事項」

- 5.3項「Oracle HTTP Serverのロギング・オプション」

- 5.4項「Oracle HTTP Serverセキュリティのパフォーマンスに関する考慮事項」

- 5.5項「Oracle HTTP Serverのパフォーマンスに関する考慮事項」

注意:

この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

5.1 Oracle HTTP Serverについて

Oracle HTTP Server(OHS)は、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。Oracle WebLogic Serverのリスナーと静的ページ、動的ページおよびWeb上のアプリケーションのホスティングのフレームワークを提供します。Oracle HTTP ServerはApache 2.2.xインフラストラクチャをベースとし、オラクル社が開発したモジュールを含んでいます。シングル・サインオン、クラスタ化されたデプロイおよび高可用性の機能がOracle HTTP Serverの動作を強化しています。

詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

オープンソースのApacheソフトウェア・インフラストラクチャの詳細は、Apache Software FoundationのWebサイト(http://www.apache.org/)を参照してください。

5.2 Oracle HTTP Serverディレクティブのチューニングに関する考慮事項

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

Oracle HTTP Serverの構成の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの管理ツールに関する項を参照してください。

Oracle HTTP Serverは、デフォルトで、3種類のMulti-Processing Module(MPM)をサポートしています。サポートされているMPMは次のとおりです。

- Worker: これは、マルチプロセス-マルチスレッド・モデルを採用しており、Microsoft Windowsプラットフォームを除くすべてのプラットフォームのデフォルトMPMです。マルチスレッド・サポートによってシステム・リソースの使用量が減少するため、スケーラビリティが向上し、マルチプロセス・サポートによって安定性が向上します。

- WinNT: このMPMはWindowsプラットフォーム専用です。親プロセスと子プロセスで構成されています。親プロセスは制御プロセスであり、子プロセスはリクエストを処理するスレッドを作成します。

- Prefork: これは、Apache 1.3.x方式に準拠しており、スレッドのかわりにプロセスを使用します。最も効率性の低いMPMとみなされています。

各MPMタイプのディレクティブは、ORACLE_INSTANCE/config/OHSComponent/<ohsname>/httpd.confファイルにあります。デフォルトのMPMタイプはWorker MPMです。別のMPM(Prefork MPMなど)を使用する場合は、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)を参照してください。

表5-1 Oracle HTTP Serverの構成プロパティ

ディレクティブ

説明

ListenBackLog

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「キューの長さ: 最大」フィールドにマップされます。

保留中の接続のキューの最大長を指定します。通常、チューニングは不要です。一部のオペレーティング・システムでは、バックログとして指定した数値そのものが使用されるのではなく、設定値に基づいた数値(通常は設定値より大きい数値)が使用されることに注意してください。

デフォルト値: 511

MaxClients

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「最大リクエスト数」フィールドにマップされます。

このパラメータは、mod_winnt(Microsoft Windows)では使用できませんので注意してください。winntはシングル・プロセスのマルチスレッド・モデルを採用しており、ThreadLimitディレクティブによって制御されます。

稼働しているサーバーの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、ListenBackLogディレクティブで指定した制限に達するまでTCP/IPシステムのキューに入れられます(保留中の接続のキューが満杯になった後は、スレッドが使用可能になるまで、新しいリクエストが発生するたびに接続エラーが生成されます)。

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

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

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

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

MaxClientsの最大値は8192(8K)です。

デフォルト値: 150

StartServers

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

起動時に作成される子サーバー・プロセスの数を指定します。再起動後に急激な負荷が予想される場合は、必要な子サーバーの数に基づいてこの値を設定してください。

次のパラメータは相関関係にあり、UNIXプラットフォーム(worker_mpm)にのみ適用されることに注意してください。

- MaxClients

- MaxSpareThreadsとMinSpareThreads

- ServerLimitとStartServers

Windowsプラットフォーム(mpm_winnt)では、UNIXプラットフォームの場合と同様に、次のパラメータをチューニングすることが重要です。

- ThreadLimit

- ThreadsPerChild

各子プロセスには、実際にリクエストを処理する子スレッドが定義されていることに注意してください。このディレクティブと関連してThreadsPerChildを使用します。

ThreadLimit、ServerLimitおよびMaxClientsは、この値に間接的に影響を与えます。それぞれの注意を読んだうえで、このディレクティブとともに使用してください。

デフォルト値: 2

ServerLimit

このパラメータは、mod_winnt(Microsoft Windows)では使用できませんので注意してください。winntはシングル・プロセスのマルチスレッド・モデルを採用しています。

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

デフォルト値: 16

ThreadLimit

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

デフォルト値:

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

- その他すべて: 64

ThreadsPerChild

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

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

デフォルト値: mpm_winntを使用する場合は64、Worker MPMを使用する場合は25です。

ThreadsPerChildディレクティブは、他のディレクティブと次のように連携します。

起動時に、Oracle HTTP Serverが親プロセスを作成します。親プロセスは、StartServersディレクティブで定義された数の子(サーバー)プロセスを作成します。各サーバー・プロセスは、ThreadsPerChildに指定された数のスレッド(サーバー/ワーカー)と、リスナー・スレッドを作成します。リスナー・スレッドは、リクエストをリスニングし、ワーカー/サーバー・スレッドに制御を渡します。

起動後は、負荷の状態に応じて、システムのサーバー・プロセス数とサーバー・スレッド(サーバー・プロセスの子)数がMinSpareThreads(システムのアイドル・スレッドの最小数)とMaxSpareThreads(システムのアイドル・スレッドの最大数)によって制御されます。システムのアイドル・スレッド数がMaxSpareThreadsを超えている場合、Oracle HTTP Serverは、プロセスの子スレッドがなければ、スレッドとプロセスを終了します。アイドル・スレッド数がMinSpareThreadsを下回っている場合、実行中のプロセスですでにThreadsPerChildの値に達していれば、新しいスレッドとプロセスを作成します。

次のディレクティブは、前述のディレクティブに対する制限を制御します。次のディレクティブを有効にするには、前述のディレクティブより先に定義する必要がありますので注意してください。

- ServerLimit: 作成可能なサーバーの数の上限を定義します。これは、MaxClientsとStartServersに影響を与えます。

- ThreadLimit: ThreadsPerChildの上限を定義します。ThreadsPerChildがThreadLimitより大きい場合、ThreadsPerChildは自動的にThreadLimitの値まで減らされます。

- MaxClients: リクエストを同時に処理可能なサーバー・スレッドの数の上限を定義します。この値は、作成可能な同時接続の数と一致させる必要があります。この値は、ThreadsPerChildの倍数になるようにしてください。MaxClientsがServerLimitにThreadsPerChildを掛けた値より大きい場合、MaxClientsは自動的に、ServerLimitにThreadsPerChildを掛けた値まで減らされます。

MaxRequestsPerChild

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

各子プロセスが終了するまでに処理可能なリクエストの数を指定します。子プロセスは、長期間使用するうちにApache(およびApacheが使用するその他のライブラリ)でメモリーまたはその他のリソースのリークが発生して問題が生じることのないよう、自動的に終了します。ほとんどのシステムでは、これは不要ですが、UNIXシステムの中には、ライブラリで著しいリークが発生するものがあります。このようなプラットフォームについては、MaxRequestsPerChildを10000に設定してください。0に設定すると、リクエストは制限されません。

この値には、各接続の初期リクエストに続くKeepAliveリクエストは含まれません。たとえば、子プロセスが初期リクエストとそれに続く10個のキープ・アライブ・リクエストを処理した場合、この制限の対象となるリクエストは1個とカウントされます。

デフォルト値: 0

注意: Windowsシステムでは、サーバー・プロセスが1つしかないため、MaxRequestsPerChildは常に0(無制限)に設定してください。

MaxSpareThreads

MinSpareThreads

これらのディレクティブは、「パフォーマンス・ディレクティブ」画面の「最大アイドル・スレッド」フィールドおよび「最小アイドル・スレッド」フィールドにマップされます。

これらのパラメータは、mod_winnt(Windowsプラットフォーム)では使用できませんので注意してください。

サーバープールのサイズを制御します。Oracle HTTP Serverは、必要なサーバー・スレッドの数を予測するかわりに、実際の負荷に動的に適応します。サーバーは、現在の負荷を処理するのに十分なサーバー・スレッドに加え、一時的な負荷の増大(単一のブラウザから複数のリクエストを同時に受信した場合など)に備えて、予備のサーバー・スレッドもいくつか保持しておこうとします。

そのために、サーバーはリクエストを待っているサーバー・スレッドの数を定期的にチェックします。それがMinSpareThreadsより少ない場合は、新しい予備のスレッドを作成します。MaxSpareThreadsより多い場合は、予備のスレッドの一部を削除します。

デフォルト値:

MaxSpareThreads: 75

MinSpareThreads: 25

タイムアウト

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「リクエスト・タイムアウト」フィールドにマップされます。

受信および送信がタイムアウトするまでの時間(秒)。

デフォルト値: 300

KeepAlive

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1接続当たりの複数リクエスト」フィールドにマップされます。

永続的な接続(1接続当たり複数のリクエスト)を許可するかどうか。Offに設定すると、無効になります。

デフォルト値: On

MaxKeepAliveRequests

永続的な接続の間に許可するリクエストの最大数。0に設定すると、無制限に許可されます。

長時間にわたるクライアント・セッションがある場合は、この値を大きくすることを検討してください。

デフォルト値: 100

KeepAliveTimeout

このディレクティブは、「パフォーマンス・ディレクティブ」画面の「1接続当たりの複数リクエスト」フィールドの下にある「接続タイムアウト(秒)を許可」フィールドにマップされます。

1つの接続において同じクライアントからの次のリクエストを待つ時間(秒)。

デフォルト値: 5秒

limit

ulimit

オープン・ファイルまたはオープン・ネットワーク・ソケットに対して読取りまたは書込みを行うためにプログラムで使用するオブジェクトの数。使用可能なファイル・ディスクリプタの不足は、オペレーティング・システムのパフォーマンスに影響を与える可能性があります。

ファイル・ディスクリプタ制限をチューニングするには、OHSを起動するシェル・スクリプトで強い制限(ulimit)を構成します。強い制限が設定されると、OHSは弱い制限(limit)を一致するように調整します。

ファイル・ディスクリプタ制限の構成は、プラットフォーム固有であることに注意してください。詳細は、オペレーティング・システムのドキュメントを参照してください。

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

ブラウザが永続的な接続をサポートしている場合、Oracle HTTP ServerのKeepAliveディレクティブを使用すれば、サーバーでも永続的な接続をサポートできます。永続的な接続を使用すると、サーバーのワークロードが減少するため、パフォーマンスが向上します。永続的な接続を有効にした場合、サーバーでは、クライアントへの接続を設定する作業を繰り返す必要がなくなります。

KeepAliveディレクティブのデフォルト設定は次のとおりです。

KeepAlive on
MaxKeepAliveRequests 100
KeepAliveTimeOut 5

これらの設定では、永続的な接続のメリットを享受しながら、デメリットを最小限に抑えることができるように、1接続当たりのリクエスト数とリクエストの間隔が設定されています。これらの値を設定する際には、ご使用のシステムのユーザー数とユーザーの取る行動を考慮する必要があります。たとえば、ユーザー数は多いが、ユーザーからのリクエストが小さく、頻度も低い場合は、KeepAliveディレクティブのデフォルト設定を小さくするか、KeepAliveをoffに設定します。ユーザー数が少なく、サイトのアクセス頻度が高い場合は、設定を大きくします。

KeepAliveオプションは、MaxClientsディレクティブとともに慎重に使用してください。KeepAliveオプションは、タイムアウトするか、リクエスト数がMaxKeepAliveRequestsで指定した制限に達するまで、確立済の接続にワーカー・スレッドを結び付けます。つまり、ListenBacklogキュー内の接続またはユーザーは、キープ・アライブ・ユーザーがワーカーを解放するまで、ワーカーが不足した状態になります。リソースの不足は、ユーザー数がMaxClientsに指定した数より常に多いようなKeepAliveユーザー負荷に対して発生します。

注意:

MaxclientsプロパティはUNIXプラットフォームにのみ適用されます。Windowsでは、ThreadLimitパラメータおよびThreadsPerChildパラメータで同じ機能が実現されます。

MaxClientsを大きくした場合、パフォーマンスに次のような影響が出ます。

- MaxClientsの数値が大きいと、システム・リソースに過負荷がかかり、パフォーマンスの低下につながる可能性があります。

- ユーザー数が多く、リクエストが少ない場合は、リソース不足が起きないように、MaxClientsを大きくしてKeepAlive接続をサポートすることを検討してください。この場合、ユーザーの同時実行性が向上すると、全体的なパフォーマンスに影響が出る可能性がありますので注意してください。システム・パフォーマンスが同時実行性向上の影響を受け、システム障害を引き起こすことがあります。

MaxClientsは常に、システムが安定し、最適なパフォーマンスが得られる(CPU使用率が最大85%)ような値に設定してください。

一般に、ユーザー数が多く、リクエストの頻度が低い場合は、リソース不足が起きないように、KeepAliveオプションをoffにするか、ごく小さい値まで減らすことを検討してください。

KeepAlive接続を無効にした場合、パフォーマンスに次のような影響が出ます。

- リクエストごとに接続を確立するため、コストがかかります。

- 接続を作成してクローズする頻度が高くなると、システム・リソースがある程度使用されます。TCP接続では、ソケット接続およびオープン・ファイル・ディスクリプタをクローズするまでのtime_wait間隔が接続ごとに設定されています。time_waitのデフォルト値は60秒です。つまり、サーバーが接続を解放した後も、各接続をクローズするまでに60秒かかる可能性があります。

警告:

パフォーマンスの問題が発生するのを避けるために、パラメータの値は、必ずワークロードの性質およびシステムのキャパシティを考慮したうえで設定してください。

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

この項では、ロギングのタイプ、ログ・レベル、およびロギングを使用した場合のパフォーマンスへの影響について説明します。

5.3.1 アクセス・ロギング

一般に、アクセス・ログは誰が何にアクセスしたかを追跡する目的で有効にします。ORACLE_INSTANCE/diagnostics/logs/OHS/ohsnameディレクトリにあるaccess_logファイルには、処理されたリクエストごとにエントリが1つ含まれています。このファイルは次第に大きくなるため、ディスク領域を消費する可能性があります。ワークロードの性質によっては、access_logはパフォーマンスにほとんど影響を与えません。パフォーマンスが問題になっていることに気づいた場合、他のプロキシまたはロード・バランサが使用されていて、同じ情報が得られるのであれば、access_logファイルを無効にしてもかまいません。

5.3.2 HostNameLookupsディレクティブの構成

デフォルトでは、HostNameLookupsディレクティブはOffに設定されています。サーバーは、受信リクエストのIPアドレスをログ・ファイルに書き込みます。HostNameLookupsがOnに設定されている場合、サーバーはインターネット上のDNSシステムに問い合せて、各リクエストのIPアドレスに関連付けられているホスト名を特定し、そのホスト名をログに書き込みます。サーバーの負荷およびDNSサーバーへのネットワーク接続によっては、DNS HostNameLookupがパフォーマンスに与える影響が大きくなります。可能であれば、IPアドレスのみをログに記録することを検討してください。UNIXシステムでは、ORACLE_HOME/Apache/Apache/bin/ディレクトリにあるlogresolveユーティリティを使用して、オフラインの状態でIPアドレスをホスト名に解決できます。

5.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レベルなど高いデバッグ・レベルを設定すると、それに伴ってパフォーマンス・コストが発生します。

5.4 Oracle HTTP Serverセキュリティのパフォーマンスに関する考慮事項

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

- Oracle HTTP ServerにおけるSecure Sockets Layer(SSL)のパフォーマンスの問題

- Oracle HTTP Serverポート・トンネリングのパフォーマンスの問題

5.4.1 Oracle HTTP ServerにおけるSecure Sockets Layer(SSL)のパフォーマンスの問題

Secure Sockets Layer(SSL)は、Netscape社によって開発されたプロトコルで、インターネット上での認証および暗号化通信を可能にします。概念的には、SSLはプロトコル・スタックのアプリケーション層とトランスポート層の中間に存在します。SSLは、技術的にはアプリケーションに依存しないプロトコルですが、HTTP経由のセキュリティを提供するための標準となり、すべての主要なWebブラウザでサポートされています。

SSLは、Webベースのアプリケーションのレスポンス能力とスケーラビリティの両方でボトルネックとなる可能性があります。SSLが必要な場合は、プロトコルのパフォーマンスに関する問題を慎重に考慮してください。一般に、SSLプロトコルを使用するうえで最もパフォーマンス・コストがかかるのは、特にセッションの作成や初期化などのセッション管理です。

この項には、SSLのパフォーマンスに関連した次の情報が含まれています。

- 5.4.1.1項「Oracle HTTP ServerのSSLキャッシュ」

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

- 5.4.1.3項「SSLのパフォーマンスのチューニングに関する考慮事項」

関連項目:

Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド

5.4.1.1 Oracle HTTP ServerのSSLキャッシュ

SSL接続が初期化されると、クライアントとサーバーの間でセッションベースのハンドシェイクが発生します。これには、暗号スイートのネゴシエーション、データ暗号化用の秘密鍵の交換、ならびにデジタル署名証明書を介したサーバーおよびクライアント(オプション)の認証が含まれます。

SSLのセッション状態がクライアントとサーバーの間で開始されれば、そのセッション状態を保存して再利用できるので、その後のSSLリクエストでセッション作成のためのハンドシェイクを行う必要はなくなります。Oracle HTTP Serverは、デフォルトでクライアントのSSLセッション情報をキャッシュします。セッション・キャッシュを使用すると、待機時間が長いのはサーバーへの最初の接続時のみになります。

ssl.confのSSLSessionCacheTimeoutディレクティブにより、保存されたSSLセッションをサーバーが保持する期間を指定します(デフォルトは300秒です)。セッション状態は、指定の時間が経過しても使用されない場合は破棄されます。その後のSSLリクエストでは、新しいSSLセッションを確立し、もう一度ハンドシェイクを開始する必要があります。SSLSessionCacheディレクティブでは、SSLセッション情報の保存場所を指定します(デフォルトの場所は次のディレクトリです)。

$ORACLE_INSTANCE/diagnostics/logs/$COMPONENT_ TYPE/$COMPONENT_NAME

保存されたセッション・キャッシュ・ファイルは、複数のOracle HTTP Serverプロセスで使用できることに注意してください。

SSLのセッション状態を保存すると、SSLを使用したアプリケーションのパフォーマンスが大幅に向上します。たとえば、SSL対応のサーバーで接続と切断の簡単なテストを行ったところ、SSLセッション・キャッシュを使用しない場合、5回の接続に要した時間は11.4秒でした。SSLセッション・キャッシュを使用可能にした場合、5回のラウンドトリップに要した時間は1.9秒でした。

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

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

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

Oracle HTTP Serverは、ssl.confで指定されているSSLCipherSuite属性に基づき、クライアントと暗号スイートをネゴシエートします。OHS 11gでは、デフォルトで128ビットの暗号化アルゴリズムが使用されており、それより低いレベルの暗号化はサポートを終了しました。Windowsの場合、旧リリース[10.1.3x]では64ビットの暗号化が使用されていました。UNIXの場合、10.xリリースでは128ビットの暗号化が使用されていました。

関連項目:

サポートされている暗号スイートの使用の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

5.4.1.3 SSLのパフォーマンスのチューニングに関する考慮事項

次の推奨事項は、Oracle HTTP ServerをSSLとともに使用する場合のパフォーマンス要件を決定する際に役立ちます。

1. SSLハンドシェイクは、CPU使用率とレスポンス時間のどちらから見ても、本質的にリソース消費量の多いプロセスです。したがって、SSLは必要な場合にのみ使用しください。アプリケーションの中でセキュリティを必要とする部分と要求されるセキュリティ・レベルを見極め、この部分のみを必要なセキュリティ・レベルで保護します。SSLの使用を控え、可能なかぎりセッション状態を再利用して、SSLハンドシェイクの必要性を最小限に抑えます。たとえば、ページ上に少量の機密データと多量の機密ではないグラフィック画像がある場合、機密データの転送にのみSSLを使用し、画像の転送には通常のHTTPを使用します。アプリケーションでサーバー認証のみが必要とされている場合、クライアント認証は使用しません。アプリケーションのパフォーマンス目標がこの方法のみでは実現できなければ、追加のハードウェアが必要になる場合もあります。

2. SSLを効果的に使用できるようにアプリケーションを設計します。セキュアな操作をグループ化して、SSLセッションおよびSSL接続を再利用します。

3. 可能な場合は永続的な接続を使用して、SSLセッションの再利用のコストを最小限に抑えます。

4. セッション・キャッシュのタイムアウト値をチューニングします(ssl.confのSSLSessionCacheTimeoutディレクティブ)。SSLセッション・キャッシュを維持するコストと、新しいSSLセッションを確立するコストの間には、トレードオフが存在します。一般に、保護されたビジネス・プロセス、つまり概念的にグループ化されたSSL交換は、セッション作成を複数回行わずに完了させる必要があります。SSLSessionCacheTimeout属性のデフォルト値は300秒です。アプリケーションの使い勝手をテストして、この設定のチューニングに役立ててください。

5. 大量のデータがSSLで保護されている場合、使用されている暗号スイートに細心の注意を払ってください。暗号スイートは、ssl.confで指定されているSSLCipherSuiteディレクティブによって制御します。低いレベルのセキュリティでも許容される場合は、小さいサイズの鍵を使用する、暗号強度の低いプロトコルを使用します(これによってパフォーマンスが大幅に向上します)。目的のセキュリティ・レベルを確保するために使用可能な暗号スイートをそれぞれ使用してアプリケーションをテストし、最適な暗号スイートを見つけます。

6. 前述の考慮事項に配慮しても、SSLが引き続きアプリケーションのパフォーマンスおよびスケーラビリティのボトルネックとなる場合は、ハードウェア・クラスタに複数のOracle HTTP Serverインスタンスをデプロイするか、SSLアクセラレータ・カードを使用することを検討してください。

5.4.2 Oracle HTTP Serverポート・トンネリングのパフォーマンスの問題

OracleASポート・トンネリングが構成されている場合、リクエストはすべてOracleASポート・トンネリング・インフラストラクチャを経由して処理されます。したがって、OracleASポート・トンネリングは、Oracle HTTP Serverによるリクエスト処理のパフォーマンスおよびスケーラビリティ全体に大きく影響します。

実行されるOracleASポート・トンネリング・プロセスの数を除き、OracleASポート・トンネリングのパフォーマンスは自動的にチューニングされます。唯一可能なパフォーマンス制御は、より多くのOracleASポート・トンネリング・プロセスを開始することです。これにより、使用可能な接続の数が増え、システムのスケーラビリティが向上します。

OracleASポート・トンネリング・プロセスの数は、必要とされる可用性の度合いや期待される接続数に基づきます。プロセスを追加するたびに、DMZとイントラネットの間のファイアウォールを介して新しいポートをオープンする必要があるため、この数を自動的に決定することはできません。オープンしたポートより多くのプロセスは開始できません。また、オープンしたポートより少ないプロセスも好ましくありません。この場合、プロセスの割り当てられないポートが存在することになります。

OracleASポート・トンネリングのパフォーマンスを測定するには、OracleASポート・トンネリング・インフラストラクチャを経由するサーブレット・リクエストのリクエスト時間を調べます。OracleASポート・トンネリングを使用した場合と使用しない場合のレスポンス時間を比較して、OracleASポート・トンネリングによってパフォーマンス要件が満たされているかどうかを確認する必要があります。

関連項目:

OracleASポート・トンネリングの構成の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

5.5 Oracle HTTP Serverのパフォーマンスに関する考慮事項

次のヒントを利用すると、Oracle HTTP Serverのパフォーマンスに関する問題の回避やデバッグが可能になります。

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

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

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

- Oracle HTTP Serverの監視

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

問題の主な原因となっている箇所を集中的にチューニングできるよう、サーバーがどこでリソースを消費しているかを把握することが重要です。システムを構成する際には、受信リクエストの何パーセントが静的なもので何パーセントが動的なものかを知っておくと役立つ場合があります。

一般に、動的なページは生成のコストが余計にかかるため、動的なページのチューニングに時間をかけてください。また、アプリケーションの監視およびチューニングを行うことで、カタログ・データなどの動的に生成されたコンテンツの多くがキャッシュ可能であり、リソースの使用量を大幅に節減できることも明らかになります。

5.5.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

5.5.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時間を節約してください。

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

使用可能なファイル・ディスクリプタの不足は、必ずしも簡単にオペレーティング・システムのファイル・ディスクリプタ制限まで遡れない様々な症状の原因になる可能性があります。ファイル・ディスクリプタ制限をチューニングするには、OHSを起動するユーザーに対してオペレーティング・システムの強い制限を構成します。構成すると、OHSはオペレーティング・システムの制限と一致するように弱い制限を調整します。

ファイル・ディスクリプタ制限の構成は、プラットフォーム固有です。詳細は、オペレーティング・システムのドキュメントを参照してください。次のコード例は、Linuxのコマンドを示しています。

APACHECTL_ULIMIT=ulimit -S -n `ulimit -H -n`

この制限は、パッチ・セットの適用後に再構成する必要があります。

5.5.5 Oracle HTTP Serverの監視

Oracle Fusion Middlewareでは、Oracle HTTP Serverの実行時のパフォーマンスが絶えず自動的に測定されます。パフォーマンス・メトリックは自動的に有効になります。パフォーマンス・メトリックを収集するためにオプションを設定したり、追加構成を行ったりする必要はありません。アプリケーションの実行に時間がかかる、アプリケーションがハングしている、などの問題が発生した場合は、特定のメトリックを参照して、問題の詳細を確認できます。

注意:

Fusion Middleware Controlにはリアルタイム・データが表示されます。Fusion Middleware Controlを使用してHTTP Serverのパフォーマンス・メトリックを確認する方法の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverのパフォーマンスの監視に関する項を参照してください。

履歴データを参照する必要がある場合は、Grid Controlの使用を検討してください。4.8項「Oracle Enterprise Manager 11g Grid Control」を参照してください。

Fusion Middleware Controlに加えて、Oracle HTTP Serverはあらゆる機能部分のメトリックを収集するDynamic Monitoring Service(DMS)も備えています。これらのメトリックを必要に応じて確認することで、特定の時点におけるシステムの動作を把握できます。Oracle HTTP Serverのすべてのレイヤーについて、メモリー、CPU情報、ならびにリクエスト処理の最小時間、最大時間および平均時間が表示されます。さらに、実際の使用状況に基づいてシステムをチューニングする際に役立つ負荷レベル、スレッド数、アクティブ接続数などの詳細も表示されます。

メトリックを監視するには、Oracle Enterprise Managerまたはスパイ・サーブレットを使用します。第4章「Oracle Fusion Middlewareの監視」を参照してください。OHSのDMSメトリックを確認するもう1つの方法を次の例に示します。

1. cd $INSTANCE_HOME/bin

2. ./opmnctl metric op=query COMPONENT_NAME=<component_name> dmsarg=[name=/OHS/Modules/<module_name>.c
例:

./opmnctl metric op=query COMPONENT_NAME=ohs1 dmsarg=[name=/OHS/Modules/mod_cgi.c

./opmnctl metric op=query COMPONENT_NAME=ohs1 dmsarg=[name=*]

6 Oracle Dynamic Monitoring Serviceのパフォーマンス・チューニング

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

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

- 6.2項「DMSの可用性」

- 6.3項「DMSアーキテクチャの概要」

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

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

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

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

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

6.1 Dynamic Monitoring Service(DMS)について

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

6.1.1 共通のDMSの用語と概念

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

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

- DMSナウン

- DMSセンサー

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

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

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

DMSの用語

定義

条件

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

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

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

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

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

宛先

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

イベント・ルート

イベント・ルートは、フィルタを宛先に接続します。イベント・ルートを有効または無効にできます。特定のフィルタでアクティブにするイベント・トレースは、そのフィルタに1つ以上のイベント・ルートが存在して有効である必要があります。

フィルタ

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

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

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

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

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

リスナー

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

6.1.1.2 DMSナウン

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

ナウン・タイプは、収集対象となるメトリックのセットを表す名前です。

6.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は変更できません。ただし、センサー名およびナウン名は必要に応じて変更可能です。

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

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

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

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

文字

DMSの代替文字

空白文字

アンダースコア: _

ピリオド: .

アンダースコア: _

制御文字

アンダースコア: _

より小さい: <

開きカッコ: (

より大きい: >

閉じカッコ: )

アンパサンド: &

カレット: ^

二重引用符: "

バッククォート: '

一重引用符: '

バッククォート: '

注意:

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

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

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

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

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

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

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

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

6.1.1.3 DMSセンサー

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

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

- 6.1.1.3.1項「DMS PhaseEventセンサー」

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

- 6.1.1.3.3項「DMS状態センサー」

6.1.1.3.1 DMS PhaseEventセンサー

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

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

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

表6-3 DMS PhaseEventセンサーのメトリック

メトリック

説明

sensor_name.time

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

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

sensor_name.completed

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

オプションのメトリック

sensor_name.minTime

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

オプションのメトリック

sensor_name.maxTime

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

オプションのメトリック

sensor_name.avg

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

オプションのメトリック

sensor_name.active

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

オプションのメトリック

sensor_name.maxActive

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

オプションのメトリック

6.1.1.3.2 DMSイベント・センサー

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

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

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

メトリック

説明

sensor_name.count

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

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

6.1.1.3.3 DMS状態センサー

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

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

表6-5 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の最大値を示します。

オプションのメトリック

6.1.1.3.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などの文字列をセンサー名に使用しないでください。表6-3、表6-4および表6-5に示したとおり、これらはセンサー・メトリックの名前であるためです。

6.2 DMSの可用性

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

詳細は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlのOracle Fusion Middlewareの動作保証マトリックスを参照してください。

6.3 DMSアーキテクチャの概要

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

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

- 実行コンテキスト - 実行コンテキストは、Oracleスタック全体の特定のコンテキスト構造のメンテナンスおよび伝播をサポートします。すべてのOracleコードで一貫して使用できるコンテキスト構造を作成すると、診断データのコンポーネント間および製品間の相関関係の潜在性が高まります。詳細は、6.6項「DMS実行コンテキスト」を参照してください。

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

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

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

「図6-1 Oracle Fusion MiddlewareコンポーネントとDMSの相互作用」の説明

6.4 DMSメトリックの表示

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

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

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

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

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

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

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

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

- WSADMIN(IBM WebSphere)を使用したメトリックの表示

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

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

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

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

注意:

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

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

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

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

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

使用するコマンド

操作

displayMetricTableNames

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

displayMetricTables

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

dumpMetrics

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

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

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

- 4.5.1.1項「システム・コンポーネントのWLSTコマンドの使用」

- Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのDMSカスタムWLSTコマンド

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

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

6.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の属性にマップされます。

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

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

6.4.6 WSADMIN(IBM WebSphere)を使用したメトリックの表示

次の内容を表示するため、IBM WebSphereで次のコマンドを使用できます。

使用するコマンド

操作

OracleDMS.displayMetricTableNames()

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

OracleDMS.displayMetricTables()

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

OracleDMS.dumpMetrics()

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

IBM WebSphereの使用の詳細は、Oracle Fusion Middlewareサードパーティ・アプリケーション・サーバー・ガイドのIBM WebSphereのOracle Fusion Middlewareの管理に関する項を参照してください。

6.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 Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。

6.6 DMS実行コンテキスト

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 新しいECID = B5C094FA...BE4AE8

- ルートRID = 0

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

- 同じECID = B5C094FA...BE4AE8

- サブタスクRID = 0:1

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

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

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

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

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

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

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

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

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

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

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

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

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

「図6-2 DMS実行コンテキストの通信プロトコル」の説明

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

Oracle Fusion Middleware 11gリリース1(11.1.1.3.0)以降、DMSは次のイベントを選択的にトレースできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 上記の条件の論理ANDおよびORの組合せ

6.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

6.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コマンド・リファレンスまたはコマンド・ヘルプを参照してください。

6.7.1.2 宛先の追加および編集

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

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

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

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

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

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

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

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

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

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

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

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

6.7.1.4 複合操作

6.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"

6.7.2 宛先の構成

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

- LoggerDestination

- MBean Creatorの宛先

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

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

6.7.2.1 LoggerDestination

説明

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

実装クラス

oracle.dms.trace2.runtime.LoggerDestination

プロパティ

loggerName

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

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

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

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

6.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にログとして記録され、ログの問合せに表示されます。

ロガーの出力の解釈の詳細は、6.7.3項「DMSイベント出力の理解」を参照してください。

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

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

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

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

プラットフォーム

サーバー

場所

Oracle WebLogic Server

AdminServer

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

WAS ND

OracleAdminServer

ORACLE_HOME/Middleware/was_profiles/DefaultTopology/DefaultServer/config/cells/DefaultCell/nodes/<nodename>/servers/OracleAdminServer/fmwconfig/logging.xml

6.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")

6.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 Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使い方』を参照してください。

6.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

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

説明

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

実装クラス

oracle.dms.event.HTTPRequestTrackerDestination

プロパティ

excludeHeaderNames

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

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

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

- URI(/webcenter/homeなど)

- リクエストの開始時間

- ECID

- 問合せ文字列

- HTTPヘッダー

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

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

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

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

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

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

6.7.2.4 JRockitフライト・レコーダの宛先

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

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

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

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

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

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

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

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

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

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

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

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

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

表6-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イベント・タイプに適用されます。

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

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

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

DMS

JRockitフライト・レコーダ(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

ナウン・タイプ:

webcenter_lifecycle

ナウン・パス:

/oracle/webcenter/webcenter/lifecycle

センサー:

ProcessingTime(P)

status(S)

successCount(E)

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

P: フェーズ・センサー

S : 状態センサー

E : イベント・センサー

プロデューサ名: webcenter

イベント・タイプ1

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

フィールド:

- ECID

- RID

- webcenter_lifecycle名

- ステータス

- イベント名

プロデューサ名: webcenter

イベント・タイプ2

イベント・タイプ名: webcenter_lifecycle ProcessingTime

フィールド:

- ECID

- RID

- webcenter_lifecycle名

- ステータス

6.7.3 DMSイベント出力の理解

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

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

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

フィールド番号

名前

説明

すべて

1

バージョン番号

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

例:

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

すべて

2

イベント時間

イベントが発生した時間

例:

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

すべて

3

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

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

- NOUN

- EVENT_SENSOR

- STATE_SENSOR

- PHASE_SENSOR

- EXECUTION_CONTEXT

- HTTP_REQUEST

例:

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

すべて

4

アクション・タイプ

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

- CREATE

- UPDATE

- DELETE

- START

- STOP

- ABORT

例:

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

ナウン

5

ナウン・タイプ

ナウン・タイプの名前

例:

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

6

ナウン・パス

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

例:

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

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

5

ナウン・タイプ

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

例:

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

6

センサー名

センサーの名前

例:

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

7

ナウン・パス

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

例:

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

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

8

開始トークン

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

例:

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

9

停止トークン

フェーズの終了トークン。

例:

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

状態センサー・タイプ

8

状態値タイプ

次の項目を含む状態センサーで保持される値のタイプ

- State.DOUBLE

- State.INTEGER

- State.LONG

- State.OBJECT

- State.ANY

例:

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

9

状態値

文字列形式で表される状態の値。

例:

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

HTTPリクエスト

5

URI

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

例:

v1:1280737382889:HTTP_REQUEST:START:/myWebApp/showEmployees

v1:1280737384058:HTTP_REQUEST:STOP:/myWebApp/showEmployees

実行コンテキスト

5

ECID、RID

カンマで区切られたECIDおよびRIDで構成されるコンテキスト識別子。

実行コンテキスト・イベントでは、4番目のイベント・フィールド・セパレータ(「:」)の後の最初の文字から始まる完全な部分文字列にECIDおよびRID識別子を記録します。コンテキスト識別子に「:」が含まれる可能性があるので、イベント・フィールド・セパレータとして解釈しないようにしてください。

例:

v1:1280737384058:EXECUTION_CONTEXT:STOP:bc4fd0668f79d507:367c127f:12a23f2013c:-8000-0000000000000f73,0

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

表6-9は、ソース・オブジェクト・タイプで実行できるアクション・タイプを示しています。

表6-9 ソース・オブジェクト・タイプで実行されるアクション

作成

更新

削除

開始

停止

中断

ナウン

はい

-

はい

-

-

-

イベント・センサー

はい

はい

はい

-

-

-

フェーズ・センサー

はい

-

はい

はい

はい

はい

状態センサー

はい

はい

はい

-

-

-

実行コンテキスト

-

-

-

はい

はい

-

HTTPリクエスト

-

-

-

はい

はい

-

6.8 DMSベスト・プラクティス

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

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

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

表6-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

表6-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

表6-11に、oracle.dms.clockプロパティでサポートされる値を示します。

表6-12に、oracle.dms.unitsプロパティでサポートされる値を示します。

表6-11 oracle.dms.clockプロパティの値

値

説明

DEFAULT

デフォルト・クロックを使用することを指定します。デフォルト・クロックの場合、DMSはJavaコールjava.lang.System.currentTimeMillisを使用してPhaseEventの時間を取得します。

デフォルト・クロックの単位のデフォルト値は、MSECSです。

HIGHRES

Java HighresクロックはSystem.nanoTime()を使用します(JNIは不要です)。

表6-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は、起動時にプロパティ値をチェックします。表6-11に示されていない値でクロック・プロパティを設定すると、デフォルト・クロックが使用されます。oracle.dms.clockプロパティを設定していない場合も、デフォルト・クロックが使用されます。

- クロック単位のプロパティが表6-12に示されていない値に設定されている場合、指定したクロックのデフォルトの単位が使用されます。

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

この章では、Oracle Metadata Service(MDS)のチューニングのヒントを示します。

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

- 7.2項「データベース・リポジトリのチューニング」

- 7.3項「ドキュメント・バージョン履歴のパージ」

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

- 7.5項「キャッシュ構成のチューニング」

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

- 7.7項「DMSメトリックとその特性の理解」

7.1 Oracle Metadata Services (MDS)について

Oracle Metadata Services(MDS)は、アプリケーション・サーバーであるとともに、ファイルベースのリポジトリ・データ、ディクショナリ表(組込み関数からアクセス)およびメタデータ・レジストリのメタデータが保存されているOracleリレーショナル・データベースでもあります。MDSの主な用途の1つは、Oracleアプリケーションのカスタマイズおよび永続的なパーソナライズの内容を格納することです。Oracle Metadata Services(MDS)は、Oracle WebCenter FrameworkやOracle Application Development Framework(ADF)などのコンポーネントによって、メタデータの管理に使用されます。MDSが管理するメタデータ・オブジェクトには、JSPページおよびページ・フラグメント、ADFページ定義およびタスク・フロー、これらのオブジェクトのカスタマイズ版などがあります。

注意:

Oracle Metadata Service構成パラメータのほとんどは固定であり、特に指定のないかぎり実行時には変更できません。

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

MDS APIのパフォーマンスを最適化するために、MDSリポジトリのデータベース・スキーマはデータベース管理者が監視およびチューニングを行う必要があります。この項では、データベース・リポジトリをチューニングする際の推奨措置を示します。

- 「スキーマ統計の収集」

- 「REDOログ・サイズの拡大」

- 「ディスク領域の解放」

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

データベース・チューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のインスタンスのパフォーマンスの最適化に関する項を参照してください。

7.2.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.2.2 REDOログ・サイズの拡大

REDOログ・ファイルのサイズはパフォーマンスに影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティが増加し、パフォーマンスが低下する可能性があります。

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のREDOログ・ファイルのサイズ指定に関する項を参照してください。

7.2.3 ディスク領域の解放

手動および自動のパージ操作を行うとメタデータの内容がリポジトリから削除されますが、表や索引が保持している領域はただちに解放されない場合があります。その結果、MDSスキーマが消費するディスク領域は増大していきます。データベース管理者は、手動で索引を再作成して表を小さくすることで、パフォーマンスを改善するとともにディスク領域を解放できます。

詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』の未使用領域の解放に関する項を参照してください。

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

データベース管理者は、(Oracleデータベースの自動ワークロード・リポジトリ(AWR)・レポートを生成するなどの方法で)データベースを監視してロックの競合やI/O使用率を観察し、問題解決のための適切な措置を取る必要があります。

詳細は、次のドキュメントを参照してください。

- 『Oracle Databaseパフォーマンス・チューニング・ガイド』の自動ワークロード・リポジトリ・レポートの生成に関する項

- 『Oracle Database管理者ガイド』のパフォーマンスの監視に関する項

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

MDSは、データベースのメタデータ・ストアにドキュメント・バージョン履歴を保持しています。バージョン履歴が蓄積するにつれて、必要なディスク領域が増え、読取り/書込みのパフォーマンスが低下します。ドキュメント・バージョンがアクティブ・ラベルの一部でない場合は、次の2つの方法でバージョン履歴をパージできます。

- 自動パージ

- 手動パージ

注意:

バージョン履歴を手動でパージする場合、最後のパージ以降に行われたメタデータ更新の回数によっては、パフォーマンスに影響が出ることがあります。

7.3.1 自動パージ

自動パージ間隔は、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのAutoPurgeTimeToLive属性にマップされます。アプリケーションでMDSのデータベース・ストアが使用されている場合は、EARをパッケージングする前に、次のエントリをadf-config.xmlに追加することで、自動パージを設定できます。

<persistence-config>
<auto-purge seconds-to-live="T"/>
</persistence-config>

上の例では、自動パージ間隔として指定した時間T(秒)より古いバージョンが削除されます。詳細は、『Oracle Fusion Middleware管理者ガイド』のデプロイ済アプリケーションのMDS構成属性の変更に関する項を参照してください。

ヒント:

自動パージ間隔は、アプリケーションで作成されたドキュメント・バージョンに基づいて調整します。作成されたバージョンの数によっては、パージに長時間かかることがあります。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のMDSキャッシュ・サイズおよびパージ頻度の設定に関する項も参照してください。

7.3.2 手動パージ

データベース領域の不足やパフォーマンスの低下が疑われるときは、WLSTコマンドまたはOracle Enterprise Managerを使用して、既存のバージョン履歴を手動でパージできます。手動でのパージはパフォーマンスに影響を与えることがあるため、メンテナンス期間内やシステムの利用率が低いときにパージを行う計画を立ててください。

バージョン履歴の手動パージの詳細は、『Oracle Fusion Middleware管理者ガイド』のメタデータ・バージョン履歴のパージに関する項を参照してください。

7.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.5 キャッシュ構成のチューニング

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

キャッシュは、デプロイ後にMBeanを介して構成または変更できます。この要素は、MDSAppConfig MBeanのMaximumCacheSize属性にマップされます。詳細は、『Oracle Fusion Middleware管理者ガイド』のデプロイ済アプリケーションのMDS構成属性の変更に関する項を参照してください。

注意:

Enterprise Managerで参照できるMDSメトリックは、MDSキャッシュをチューニングする際に便利です。特に、「MOコンテンツ取得当たりのIO」または「メタデータ・オブジェクト取得当たりのIO」に1より小さい値を指定する必要があります。指定しない場合は、MDSキャッシュのサイズを大きくすることを検討してください。DMSメトリック情報の表示の詳細は、7.7項「DMSメトリックとその特性の理解」を参照してください。

正しいサイズのキャッシュがあれば、メタデータ・オブジェクトを繰り返し読み取る際のスループットを大幅に改善できます。最適なキャッシュ・サイズは、使用されるメタデータ・オブジェクトの数および個々のサイズによって異なります。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)に基づいて行われます。存続時間(TTL)が設定されている場合を除き、MDSキャッシュはmax-size-kbに指定されたサイズのメモリーを占有し続けます。

7.5.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.7項を参照)に1より小さい値を指定する必要があります。指定しない場合は、ドキュメント・キャッシュ・サイズを大きくすることを検討してください。

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

MDSをカスタマイズすると、実行時のパフォーマンスに影響が出ることがあります。カスタマイズの影響は、次のような多くの要因によって変わります。

- 作成したカスタマイズのタイプ(共有か、ユーザー・レベルか)

- システム内でメタデータ・オブジェクトがカスタマイズされている割合。この割合が低ければ、カスタマイズの影響は小さくなります。

- 構成されているカスタマイズ・レイヤーの数とカスタマイズの効率。

カスタマイズは主に2つのタイプに分けられます。

- 共有のカスタマイズ: getCacheHintメソッドがALL_USERSまたはMULTI_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、すべてまたは複数のユーザーに適用されます。共有のカスタマイズは、(共有の)MDSキャッシュにキャッシュされます。

- ユーザー・レベルのカスタマイズ(パーソナライズとも呼びます): getCacheHintメソッドがSINGLE_USERを返すカスタマイズ・クラスに対応するカスタマイズ・レイヤーです。このレイヤーは、1人のユーザーのみに適用されます。ユーザーによるカスタマイズは一般に、ユーザーがログアウトするまで、そのユーザーのセッション(HttpSession)にキャッシュされます。

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

7.7 DMSメトリックとその特性の理解

MDSは、DMSセンサーを使用して、Enterprise Managerで参照可能なチューニングおよび診断の情報を提供しています。この情報は、MDSキャッシュのサイズが十分かどうかを確認する場合などに便利です。

DMSメトリックの情報は、Fusion Middleware Control Consoleコンソールで確認できます。ページ上部の「ヘルプ」をクリックすると、詳しい情報が表示されます。ほとんどの場合、ヘルプ・ウィンドウには現在のページに関するヘルプ・トピックが表示されます。ヘルプ・ウィンドウの「目次」をクリックして、ヘルプ・トピックのリストを参照するか、「検索」をクリックして特定の語句を検索します。

第III部

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

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

- 第8章「Oracle Application Development Frameworkのパフォーマンス・チューニング」

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

- 第10章「Oracle Web Cacheのパフォーマンス・チューニング」

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

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

- 8.1項「Oracle ADFについて」

- 8.2項「Oracle ADFビューのパフォーマンス」

- 8.3項「ADFサーバーのパフォーマンス」

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

- 『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』

- 『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』

- 『Oracle Fusion Middleware Oracle Application Development Framework Java EE開発者ガイド』

8.1 Oracle ADFについて

Oracle Application Development Framework(Oracle ADF)は、Java Platform, Enterprise Edition(Java EE)標準およびオープンソース・テクノロジをベースとするエンドツーエンドのアプリケーション・フレームワークで、サービス指向アプリケーションの実装を簡素化および迅速化します。Oracle ADFは、Web、無線、デスクトップ、Webサービスなどのインタフェースを使用してデータを検索、表示、作成、変更、検証するアプリケーションの構築を目指す企業内開発者に最適です。Web、無線、デスクトップ、Webサービスなどのインタフェースを使用してデータを検索、表示、作成、変更、検証するエンタープライズ・ソリューションを構築する場合は、Oracle ADFで作業を簡素化できます。Oracle JDeveloper 11gとOracle ADFを組み合せて使用すれば、設計からデプロイメントまでの開発ライフサイクル全体をカバーする環境と、ドラッグ・アンド・ドロップによるデータ・バインディング、ビジュアルUI設計およびチーム開発の組込み機能が得られます。

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のOracle ADFの概要に関する項を参照してください。

8.2 Oracle ADFビューのパフォーマンス

Oracle ADF Faces Rich Client(RC)は、Ajax(Asynchronous JavaScript and XML)機能を備えた標準JSFコンポーネントのセットです。

Ajaxが標準のインターネット技術で稼働するリッチ・クライアント型のアプリケーションを実現するのに対し、JSFはサーバーサイド・コントロールを提供します。そのため、一般的なAjaxアプリケーションによく見られる、JavaScriptを多用することへの依存が軽減されます。Apache MyFaces Trinidadを基盤として採用したOracle ADF Faces RCは、JSFアプリケーションにAjaxの機能性を付加し、リッチ・インターネット・アプリケーション(RIA)の機能をもたらします。

ADFアプリケーションの構築、構成およびデプロイを行う前に、最適なパフォーマンスが得られるよう、次のトピックに目を通してください。

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

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

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

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

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

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

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

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

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

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

パラメータ

説明

org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE

ページ状態を圧縮するかどうかを制御します。データのサイズが圧縮されると、待機時間を減らすことができます。このパラメータはTrueに設定してください。

org.apache.myfaces.trinidad.resource.DEBUG

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

oracle.adf.view.rich.CHECK_FILE_MODIFICATION

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

oracle.adf.view.rich.CLIENT_STATE_METHOD

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

oracle.adf.view.rich.LOGGER_LEVEL

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

oracle.adf.view.rich.ASSERT_ENABLED

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

注意:

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

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

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

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

表8-2 ADF Facesの構成パラメータ

構成に関する推奨事項

説明

ページでインラインJavaScriptの使用を避けます。

インラインJavaScriptは、レスポンス・ペイロード・サイズを増加させる可能性があり、ブラウザにまったくキャッシュされないため、ブラウザのレンダリングをブロックすることがあります。インラインJavaScriptを使用するかわりに、すべてのスクリプトをJavaScriptライブラリ内の.jsファイルに入れることを検討し、スクリプトをaf:resourceタグを使用してページに追加してください。

注意: 可能であれば、trh:scriptではなくaf:resourceを使用することを検討してください。

JSPタイムアウト・パラメータを構成します。

JavaServer Pages (JSP)タイムアウト・パラメータを使用すると、web.xmlの次の設定によって使用頻度の低いページがキャッシュからフラッシュされます。

<servlet>
<servlet-name>
oraclejsp
<init-param>
<param-name>
jsp_timeout
</param-name>
<param-value>
600
</param-value>
</init-param>
</servlet-name>
</servlet>

注意: このパラメータは各自のユースケース・シナリオに基づいて設定してください。

ドロップダウン・ポップアップを使用して単一のツールバー項目を作成します。

画面解像度のためにブラウザ・サイズが小さい場合、Internet Explorer 7および8ではメニューバーまたはツールバーのオーバーフロー・ロジックが高コストになります。特に、入力フィールドを持つDOM構造のレイアウトに問題があります。

ドロップダウン・ポップアップを使用して単一のツールバー項目を作成し、すべての入力フィールドをその中に入れます。このポップアップは、子の作成およびcontentDelivery="lazy"を延期します。

不明なrowCountを削除します。

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

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

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

fnd:attachmentコンポーネントは、表にスタンプ設定されると、大量のDOMおよびクライアント・コンポーネントを生成する可能性があります。DOMおよびクライアント・コンポーネントの量は、1セル当たり8Kまでですが、特に速度の遅いブラウザではページ全体のパフォーマンスに影響を与えます。

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

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

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

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

表のスクロール・タイムアウトを増やします。

表は、タイムアウト後、スクロールについてフェッチ・リクエストをサーバーに送信します。タイムアウト(フェッチがサーバーに送信されるまで)は、ユーザーが短いスクロールを行う場合、通常20ミリ秒ですが、ユーザーがさらにスクロールする場合は200ミリ秒に増やすことができます。したがって、ユーザーがページの一番下までスクロールし、表が複数のリクエストをサーバーに送信すると、パフォーマンスに影響が出る可能性があります。

パフォーマンスに影響が出ないようにするには、タイムアウト制限を300ミリ秒に増やすことを検討してください。

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

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

Internet Explorer 8の場合、.xml HTTPリクエストの直後にコールされたimageタグが処理されるように、タイムアウト(10ミリ秒)を使用して_prepareForIncompleteImagesをコールします。これは、Mozilla FirefoxまたはGoogle Chromeの問題ではありません。

GetFirstVisibleRowKeyandRowをキャッシュします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

panelAccordion

panelStretchLayout

panelTabbed

breadCrumbs

navigationPane

panelSplitter

toolbar

toolbox

table

train

注意:

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

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

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

ADF Rich Clientのオーバーフロー機能を使用します。

ADF Rich Clientはオーバーフロー機能をサポートしています。この機能は、ページに収まらない子コンポーネントを、目に見えないオーバーフロー領域に移動するというものです。オーバーフローのサポートが組み込まれているコンポーネントは、panelTabbed、breadCrumbs、navigationPane、panelAccordion、toolbarおよびtrainです。toolbarは、toolboxの中に入れないとオーバーフローを処理できません。

オーバーフローのコストを軽減するために最適化がいくつか行われていますが、オーバーフロー・コンポーネントにおける子コンポーネントの数とそれぞれの複雑さに特に注意を払うことが必要です。オーバーフロー・コンポーネントの初期サイズを十分に大きく設定し、オーバーフローがほとんど発生しないようにすると効果的な場合もあります。

ADF Rich Clientの部分ページ・レンダリング(PPR)を使用します。

ADF Rich Clientは、Asynchronous JavaScript and XML(Ajax)開発手法をベースとしています。Ajaxは、対話型Webアプリケーションを作成するためのWeb開発手法です。Ajaxを使用したアプリケーションでは、Webページ全体をリロードせずに少量のデータを内部的にサーバーと交換するため、Webページのレスポンスが向上します。その結果、Webページの対話性、速度および使い勝手が向上します。

ADF Facesでは、Ajaxの部分ページ・リフレッシュ動作を実現する機能を部分ページ・レンダリング(PPR)と呼びます。PPRを使用すると、ページの小さい領域をリフレッシュすることができ、ページ全体を再描画する必要がなくなります。たとえば、ユーザーが入力コンポーネントで選択または入力した内容を出力コンポーネントに表示したり、コマンド・リンクやコマンド・ボタンからページ上の別のコンポーネントをリフレッシュするといったことが可能です。

2つの主要なAjaxパターンが部分ページ・レンダリング(PPR)によって実装されます。

- ネイティブ・コンポーネント・リフレッシュ

- クロスコンポーネント・リフレッシュ

ネイティブ・コンポーネント・リフレッシュはフレームワークに組み込まれていますが、クロスコンポーネント・リフレッシュは、場合によっては開発者が実装作業を行う必要があります。

クロスコンポーネント・リフレッシュは、アプリケーション開発者が宣言的またはプログラム的に実装します。その際、部分更新をトリガーするコンポーネント、および部分リスナーとして動作する更新対象のコンポーネントを定義します。クロスコンポーネント・リフレッシュを正しく使用し、実装することは、クライアント側のレスポンス時間を改善するための最善の方法です。UIページを設計する際には、ユーザーがコマンド・ボタンをクリックしたときにどのような処理を行うかを常に考えてください。ページ全体のリフレッシュが必要でしょうか。それとも出力テキスト・フィールドのみでよいでしょうか。フィールドの値が更新されたら、どのような処理を行う必要があるでしょうか。詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください)。

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

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

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

前述の手順により、コマンド・ボタンを使用して部分ページ・リフレッシュをトリガーするPPRが実現します。

部分ページ・レンダリングによってパフォーマンスが大幅に向上する主な理由は、ページ全体のリフレッシュが発生せず、フレームワーク・アーティファクト(ADF Rich ClientのJSライブラリやスタイルシートなど)がリロードされるかわりに、ページの小さい部分のみがリフレッシュされることです。そのため、余分なデータのフェッチやジオメトリ管理が一切行われない場合もあります。

ADF Rich Clientは、部分ページ・レンダリングを使用すればクライアント側で最適なパフォーマンスが得られることを実証しています。クライアント側での影響に加えて、サーバー側の処理が高速化され、サーバー側のスループットおよびスケーラビリティが向上します。

ADF Rich Clientのナビゲーションを使用します。

ADF Rich Clientは、ナビゲーションを幅広くサポートしています。一般的なユースケースの1つに、タブ付きナビゲーションがあります。これは現在、xmlMenuModelにバインドして簡単にナビゲーションを定義できるnavigationPaneなどのコンポーネントでサポートされています。

ただし、この方法にはデメリットが1つあります。それは、ユーザーがタブを切り替えるたびにページ全体のリフレッシュが発生することです。1つの選択肢として、panelTabbedをかわりに使用します。panelTabbedには、タブ付きコンテンツの部分ページ・レンダリングのサポートが組み込まれており、開発者の作業は必要ありません。しかし、panelTabbedはナビゲーションにバインドできず、コンテンツをページ内から取得できるようにする必要があるため、応用可能な範囲は限られています。

リソースをキャッシュします。

キャッシュ可能なリソース(イメージ、CSS、JavaScript)には、必ずキャッシュ・ヘッダーを正しく指定しておくことを強くお薦めします。また、サーバーにないリソースに対するクライアント・リクエストはサーバーへのラウンドトリップが増加する原因となります。これを防ぐには、すべてのリソースがサーバーに存在することを確認してください。

ResourceServletを使用してweb.xmlを構成し、リソース・キャッシングを有効にすることを検討してください。

<servlet-mapping>
<servlet-name>resources</servlet-name>
<url-pattern>/js/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>resources</servlet-name>
<url-pattern>/images/*</url-pattern>
</servlet-mapping>

状態トークン・キャッシュのサイズを小さくします。

web.xmlに定義したorg.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENSプロパティにより、トークンベースのクライアント側状態保存において一度に保存するトークンの数を選択します。デフォルト値は15です。これを超えると、表示されてから最も長い時間が経過したページの状態が失われます。「戻る」ボタンを頻繁に使用するユーザーや複数のウィンドウを同時に開くユーザーは、影響を受ける可能性があります。セッションごとの使用中メモリーを減らすには、この値を2に減らすことを検討してください。状態トークン・キャッシュを2に減らした場合、サポートされる「戻る」ボタンのクリック回数は1回になります。「戻る」ボタンがサポートされないアプリケーションについては、この値を1に設定してください。

カスタム・スタイルをページ先頭で定義します。

開発者が共通して行う作業の1つとして、通常のページまたはテンプレート・ページの内部にカスタム・スタイルを定義することがあげられます。ほとんどのブラウザではページの順次読み取りが採用されているため、スタイルが後から指定されると、ページの再計算が必要になります。その結果、ページ・レイアウトのパフォーマンスに影響が出ます。パフォーマンスを改善するには、スタイルをページ先頭で定義し、可能であればADFグループ・タグの内側に入れます。

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

ヘッダーに表示されるコンポーネント(または静的なCDATAコンテンツ)を取得するには、metaContainerファセットを次のように使用します。

<af:document title="#{attrs.documentTitle}" theme="dark">
<f:facet name="metaContainer">
<af:group><![CDATA[
<style type="text/css">
.TabletNavigationGlobal {
text-align: right;
padding-left: 0px;
padding-right: 10px;
white-space: nowrap;
}
HTML[dir=rtl] .TabletNavigationGlobal {
text-align: left;
padding-left: 10px;
padding-right: 0px;
}
</style>
]]>
<af:facetRef facetName="metaContainer"/>
</af:group>
</f:facet>
<af:form ...>
<af:facetRef facetName="body"/>
</af:form>
</af:document>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソースの確認:

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

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

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

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

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

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

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

構成に関する推奨事項

説明

immediate属性を使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

id属性を使用します。

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

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

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

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

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

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

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

- f:attribute

- af:setPropertyListener

- af:clientListener

- af:serverListener

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

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

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

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

構成に関する推奨事項

説明

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

editingMode="editAll"を使用すると、編集可能な値ホルダーの全コンテンツとその子コンポーネントが送信されます。これにより、クライアントのHTTPペイロードおよびDocument Object Model (DOM)コンテンツは大幅に増加します。

editingMode="clickToEdit"に切り替えて送信されるデータ量を削減し、ユーザーとのやり取りを向上させることを検討してください。

可能であれば、fetchSizeを減らします。

af:tableのfetch size属性が大きいほど、処理、サーバーからのフェッチおよびクライアントでの表示が必要なデータが多いことを示します。これは、クライアントで表示されるDOMの量を増やす可能性もあります。

表のフェッチ・サイズを変更します。

表には、1回のラウンドトリップでクライアントに送信される行数を定義したフェッチ・サイズがあります。最適なパフォーマンスを得るには、この数を最低限に抑えます。ただし、表ビューの初期ポートを実行するのに十分な行を確保してください。そうすることで、最適なパフォーマンスを得ながら余分なサーバー・リクエストを排除できます。

また、表のフェッチ・サイズとイテレータの範囲サイズを合せることを検討してください。デフォルトでは、表のフェッチ・サイズはEL式#{bindings.<name>.rangeSize}に設定されており、イテレータ・サイズと同一です。

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

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

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

詳細は、Oracle Fusion Applicationsの開発者ガイドの列の拡大の使用に関する項を参照してください。

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

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

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

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

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

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

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

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

遅延配信(デフォルト)

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

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

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

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

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

即時配信

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

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

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

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

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

構成に関する推奨事項

説明

RangeSize属性を使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

説明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

フェッチ・オプション

説明

フェッチ・モード

デフォルトのフェッチ・オプションは「すべての行」オプションです。この場合、必要に応じて取得(FetchMode="FETCH_AS_NEEDED")するか、一度にすべて取得(FetchMode="FETCH_ALL")するか、適切なほうのオプションを選択します。「必要に応じて」オプションを指定すると、ビュー・オブジェクトに対するexecuteQuery()操作によって、表示される最初のページに必要な数の行のみがまず取得されます。行数は、ビュー・オブジェクトの範囲サイズに基づいて設定されます。

フェッチ・サイズ

「次の単位で」フィールドは、フェッチ・モード・オプションとともに、データベースから同時にフェッチされるレコードの数を制御します(ビュー・オブジェクトのXMLのFetchSize)。デフォルト値は1ですが、この値では、1行のみフェッチされる場合を除き、パフォーマンスに影響を与える可能性があります。推奨構成として、この値をn+1に設定することをお薦めします。nはユーザー・インタフェースに表示される行数です。

DVTオブジェクトについては、フェッチ・サイズをn+1に設定してください。nは、rangeSizeか、rangeSizeが-1の場合は予想される最大行セット・サイズです。

最大フェッチ・サイズ

ビュー・オブジェクトのデフォルト最大フェッチ・サイズは-1です。つまり、ビュー・オブジェクトがフェッチできる行の数に制限はありません。最大フェッチ・サイズを0(ゼロ)に設定すると、ビュー・オブジェクトは挿入専用になります。結果セットにn行のデータのみを含める場合は、「行番号までのみ」オプションを選択して設定するか、setMaxFetchSize(N)をコールしてこれをプログラム的に設定します。この設定を手動で行うには、パラメータMaxFetchSizeをビュー・オブジェクトのXMLに追加します。

ビュー・オブジェクトのWHERE句に単一行を取得することを指定するには、「最大で1行」オプションを設定します。このオプションを設定すると、ビュー・オブジェクトは行がそれ以上返されないことを認識し、その状況における通常のテストを省略します。この場合、SELECT問合せは発行されず、行はフェッチされません。

最大フェッチ・サイズを使用して、何百(または何千)もの行を返す非選択的な問合せが与える影響を抑えることもできます。その場合は、最大フェッチ・サイズを指定することで、フェッチしてメモリーに格納することのできる行の数が制限されます。

順方向専用モード

データ・セットが順方向にのみトラバースされる場合は、順方向専用モードを使用すると、データ・セットを反復する際のパフォーマンスが向上します。これを構成するには、ビュー・オブジェクトに対してsetForwardOnly(true)をプログラム的にコールします。順方向専用に設定すれば、データ・セットのトラバースの際に前の行セットがキャッシュされるのを防ぐこともできます。

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

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

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

構成に関する推奨事項

説明

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

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

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

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

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

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

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

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

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

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

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

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

8.3.3 バッチ処理

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

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

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

8.3.4 RangeSizeのチューニング

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

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

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

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

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

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

-Djbo.load.components.lazily=true

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュールの粒度に関する項およびネストされたアプリケーション・モジュールの定義に関する項を参照してください。

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

アプリケーション・モジュール(AM)・プーリングを使用すると、複数のユーザーが複数のアプリケーション・モジュール・インスタンスを共有できます。AMプールの構成は、予想されるアプリケーションの使用状況によって異なります。様々なAMプール構成の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュール・プールのチューニングに関する項を参照してください。

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

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

構成に関する推奨事項

説明

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

システムレベルで適用されるパラメータは、AMプール単位で適用されます。アプリケーションで複数のAMプールを使用する場合は、AMインスタンス数を表すシステムレベルの値にAMプール数を掛けて、システムで指定されている実際の制限の合計を把握する必要があります。たとえば、アプリケーションが4つの独立したAMプールを使用してアプリケーションにサービスを提供しており、システムレベルの構成によってAMプールの最大サイズが100に制限されている場合、AMインスタンスの最大数は400になります(4つのプール * 最大プール・サイズ100)。目的とするのがアプリケーション全体で最大プール・サイズを100に制限することであれば、システムレベルの構成では最大プール・サイズとして25を指定する必要があります(最大プール・サイズ100 / 4つのプール)。JDevを介して、または直接bc4j.xcfgで各プールを別々に構成すれば、各AMプールの構成をさらにきめ細かく行うことができます。

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

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

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

詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のプール構成パラメータの設定に関する項を参照してください。

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

次のガイドラインは、AMおよびAMプールの動作をチューニングする際の一般的な出発点として使用してください。各パラメータの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。メモリー使用率またはCPU使用率の具体的なチューニングについては、8.3.6.2項「AMプール・サイズの構成」を参照してください。

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

パラメータ

説明

jbo.ampool.initpoolsize

プールの初期化時に作成するアプリケーション・モジュール・インスタンスの数を指定します(デフォルトはゼロです)。初期プール・サイズをゼロ以外に設定すると、アプリケーションの初期化にかかる時間が増えますが、その後、AMインスタンスを必要とする操作のパフォーマンスは向上します。一般的なガイドラインとして、この値は、すべてのユーザーへのサービス提供に必要な同時AMインスタンスの予想数より10%多くなるように構成してください。

jbo.ampool.maxpoolsize

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

jbo.ampool.minavailablesize

リソース・クリーンアップ処理時にプール・モニターがプールに残す、使用可能なアプリケーション・モジュール・インスタンスの最小数を指定します(デフォルトは5です)。この構成の最小値は、AMプールを再作成するコストが発生しないよう、1以上に設定するのが理想的です。ゼロ(0)に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールそのものがクリーンアップされます。

jbo.ampool.maxavailablesize

負荷が異常でない場合に理想的な、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは25です)。プール・モニターは、ウェイクアップしてリソース・クリーンアップを実行する際に、使用可能なアプリケーション・モジュール・インスタンスを削除して、使用可能なインスタンスの総数をこの理想的な最大値まで減らそうとします。アイドル・インスタンスのタイムアウトより長い期間使用されていなかったインスタンスは、この時点でクリーンアップされます。その後、使用可能なインスタンスの数をこのサイズまで下げるために必要な場合は、使用可能なインスタンスがさらに削除されます。

jbo.recyclethreshold

管理状態モードでプールに解放される前に、自身を最後に使用したセッションが次に行うリクエストに備えてセッション・アフィニティを保持しようとする、プール内のアプリケーション・モジュール・インスタンスの最大数を指定します(デフォルトは10です)。参照されるプール・サイズは常に最大プール・サイズ以下になるようにしてください。そうすれば、設定された数の使用可能インスタンスが、管理状態モードで自身を解放した直近のセッションとのアフィニティに従うようになります。一般的なガイドラインとして、この値は、短い思考時間で複数の操作を実行する同時ユーザーの予想数に設定してください。短い思考時間でアプリケーションを使用する予定のユーザーがいない場合は、この値を0(ゼロ)に設定して、アフィニティを解消してもかまいません。

jbo.ampool.timetolive

アプリケーション・モジュール・インスタンスがプール内に存在する時間(ミリ秒)を指定します。この時間が過ぎると、インスタンスは次のリソース・クリーンアップでの削除の候補となります。クリーンアップの結果、プール内のインスタンス数がminavailablesizeを下回るかどうかは関係ありません。デフォルト値は3600000ミリ秒、つまり1時間です。ほとんどのアプリケーションでは、デフォルト値で十分です。

jbo.ampool.maxinactiveage

プール内の非アクティブなアプリケーション・モジュール・インスタンスが次のリソース・クリーンアップでの削除の候補とみなされるまでの時間(ミリ秒)を指定します(デフォルトは600000ミリ秒、つまり10分です)。

jbo.ampool.monitorsleepinterval

プールのリソース・クリーンアップの間隔(ミリ秒)を指定します(デフォルトは600000ミリ秒、つまり10分です)。プール内のアプリケーション・モジュール・インスタンスの数が最大プール・サイズを超えないかぎり、プールからの削除の候補になっている使用可能インスタンスは、アプリケーション・モジュール・プール・モニターが次回ウェイクアップしてそのジョブを実行するまで、クリーンアップされることはありません。

jbo.dofailover

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

注意: アプリケーション・モジュール状態の受動化を有効にしている場合は、接続を強制的にプールに復帰させるようにOracle WebLogic Serverを構成していると障害が発生することがあります。このタイプの障害によって、SQLException (Connection has already been closed)が生成されます。この例外は、サーバー・ログに保存されます。例外は、ユーザー・インタフェースを通してレポートされません。状態の受動化が発生し、変更が保存されるようにするには、weblogic-application.xmlの<connection-check-params> pool-params要素にあるデプロイメント・ディスクリプタ・パラメータinactive-connection-timeout-secondsに適切な値を設定します。デプロイメント・ディスクリプタ・パラメータを数分に設定すると、ほとんどの場合、非アクティブな接続のタイムアウトは強制されず、その結果受動化は失敗します。ご使用の環境に合わせて、この設定値を調整してください。

jbo.locking.mode

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

jbo.doconnectionpooling

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

jbo.txn.disconnect_level

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

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

次のAMプール・サイズ・パラメータは、AMプール・サイズを制御します。次の値を調整して、メモリーまたはCPUの使用率をチューニングすることを検討してください。

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

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

パラメータ

説明

jbo.ampool.initpoolsize

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

jbo.ampool.maxpoolsize

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

jbo.ampool.minavailablesize

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

jbo.ampool.maxavailablesize

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

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

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

パラメータ

説明

jbo.ampool.initpoolsize

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

jbo.recyclethreshold

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

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

次のパラメータは、AMプールのリソース・クリーンアップの頻度および特性に影響を与えます。リソース・クリーンアップの詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

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

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

パラメータ

説明

jbo.ampool.minavailablesize

ゼロ(0)に設定すると、すべてのインスタンスがアイドル・タイムアウトより長い期間アイドルであった場合に、プールにインスタンスが1つも含まれなくなります。ただし、AMプールの再作成のコストが発生しないよう、1に設定するのが一般的です。

jbo.ampool.maxavailablesize

一般に、値を小さくすると、クリーンアップ時にプールから削除されるAMインスタンスが増加します。

jbo.ampool.timetolive

値を小さくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が短くなります。

jbo.ampool.maxinactiveage

値を小さくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが増加します。

jbo.ampool.monitorsleepinterval

これは、リソース・クリーンアップがトリガーされる頻度を制御します。間隔を短く設定すると、メモリーの節約のために非アクティブのAMインスタンスが削除される頻度が高まります。

AMプールを構成して、より多くのAMインスタンスがより長い期間プール内に存在できるようにすることで、CPU処理の必要性を軽減できます。通常、これにはメモリー消費量の増加というコストが伴います。

表8-12 AMプールのリソース・クリーンアップの構成 - CPUに関する考慮事項

パラメータ

説明

jbo.ampool.minavailablesizeとjbo.ampool.maxavailablesize

これらを大きな値に設定すると、プール内に残されるアイドル・インスタンスが増えるため、後でAMインスタンスを再作成する必要がなくなります。ただし、過度に大きな値を設定して、最大負荷時に必要な数より多くのAMインスタンスを保持することは避けてください。

jbo.ampool.timetolive

値を大きくすると、AMインスタンスが次のリソース・クリーンアップ時に削除されるまで存在する期間が長くなります。

jbo.ampool.maxinactiveage

値を大きくすると、次のリソース・クリーンアップでの削除の候補としてマークされるAMインスタンスが減少します。

jbo.ampool.monitorsleepinterval

大きな間隔を設定すると、リソース・クリーンアップの頻度が低下します。

8.3.7 ADFc: リージョンの使用

ページにリージョンを追加すると、アプリケーションが大きく強化されます。ただし、リージョンはページで大量のリソースを消費するコンポーネントでもあります。パフォーマンスを高めるには、特定の機能が必要とされる場合にのみリージョンの使用を検討してください。

8.3.8 タスク・フロー実行の延期

デフォルトでは、ページがロードされると、最初はレンダリングされなくても、タスク・フローはアクティブ化されます。このため、タスク・フローがまったく表示されない場合、不要なオーバーヘッドが発生します。

8.3.9 ポップアップのタスク・フロー

デフォルトでは、ポップアップにアクセスしなくても、ポップアップの下に子コンポーネントが作成されます。このオーバーヘッドを回避するには、次のことを検討してください。

- childCreationをdeferredに設定します。
ポップアップでchildCreation="deferred"を設定します。

タスクフローでactivation="deferred"を設定します。

注意:

この方法は、次のタグのいずれかがポップアップ内に存在する場合、使用できません。

- f:attribute

- af:setPropertyListener

- af:clientListener

- af:serverListener

また、ポップアップが表示される前に、ポップアップの子コンポーネントを参照する必要がある場合にも使用できません。childCreation="deferred"を設定すると、ポップアップの子コンポーネントの作成が延期されるため、ポップアップが表示されるまで子コンポーネントを参照できません。その場合は、次に説明するように、条件付きアクティブ化を使用します。

- 条件付きアクティブ化を使用します。
jsff内のポップアップでプロパティ・リスナーを追加して条件を設定します。

タスクフローでactivation="conditional"を設定します。

タスクフローでactivate=<condition>を設定します。

8.3.10 スイッチャ内のタスク・フローの構成

デフォルトでは、スイッチャの下のタスク・フローは、スイッチャ・ファセットが表示されるときではなく、ページがロードされるとアクティブ化されます。これを回避するには、条件付きアクティブ化を使用し、ファセットが表示されるとtrueを戻す式言語(EL)式に"active"を設定します。

8.3.11 静的データの再利用

アプリケーション全体で再利用可能な静的データがアプリケーションに含まれている場合、共有アプリケーション・モジュールを使用してキャッシュ・データを収集できます。共有アプリケーション・モジュールの作成および使用の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のアプリケーション・モジュール・ビュー・インスタンスの共有に関する項を参照してください。

8.3.12 条件付き検証

エンティティ属性に対してリソース消費量の多い検証を実行するときは、事前条件を使用し、必要な場合にのみ検証を選択して適用することを検討してください。検証のコストを事前条件のコストと比較し、事前条件がパフォーマンス上有益かどうかを判断する必要があります。検証の事前条件を指定する方法の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の検証の事前条件の設定方法に関する項を参照してください。

9 Oracle TopLink(EclipseLink)JPAのパフォーマンス・チューニング

この章では、EclipseLinkに対して使用可能なパフォーマンス・チューニング機能について説明します。EclipseLinkは、Oracle TopLinkとともに使用するオープンソースの永続性フレームワークです。この章の内容は次のとおりです。

- 9.1項「Oracle TopLinkおよびEclipseLinkについて」

- 9.2項「効率的なSQL文およびSQL問合せ」

- 9.3項「キャッシュ構成のチューニング」

- 9.4項「Coherenceとの統合」

- 9.5項「マッピングおよびディスクリプタの構成」

- 9.7項「EclipseLink JPAエンティティのパフォーマンス分析」

注意:

これらの分野におけるパフォーマンス・チューニングの詳細は、次のドキュメントを参照してください。

- 「EclipseLink Performance Tuning」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance)

- 「Performance Monitoring and Profiling」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance/Performance_Profiling)

- 「Introduction to Optimization」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Performance#Identifying_General_Performance_Optimization)

9.1 Oracle TopLinkおよびEclipseLinkについて

Oracle TopLinkには、オープンソースのEclipseLinkがJava Persistence API(JPA)実装として含まれています。Oracle TopLinkは、Oracle Application Serverへの高度な統合によってEclipseLinkを拡張します。

Java Persistence API(JPA)は、Java EEアプリケーションおよびJava SEアプリケーションの永続性に関する仕様です。JPAでは、永続クラスをエンティティと呼びます。エンティティとは、データベースにマップされ、アノテーションまたは永続性XML、あるいはその両方を使用してJPA経由で使用するよう構成されたPlain Old Java Object(POJO)クラスです。この章では、EJB3.0およびJava EE環境に則したJPAのチューニングに焦点を当てます。

この章の内容は、読者がEclipseLinkの基本的な機能を熟知しているものと想定して書かれています。チューニングを始める前に、次のサイトの概論に目を通すことを検討してください。

- 『EclipseLink JPA User's Guide』(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA)

- 「Considering JPA Entity Architecture」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Introduction/Architecture)

- 「Introduction to EclipseLink Queries」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying)

- 「Introduction to Cache」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)

- 「Introduction to Mapping and Configuration」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping)

Oracle TopLinkの詳細は、OTNのTopLinkページ(http://www.oracle.com/technology/products/ias/toplink/index.html)を参照してください。[Oracle TopLinkリリース11gで、旧Toplink APIは非推奨となりました。詳細は、TopLinkのリリース・ノート(http://www.oracle.com/technology/products/ias/toplink/doc/11110/relnotes/toplink-relnotes.html#CHDGAEDJ)を参照してください。

注意:

この章は、Java EE環境に則したJPAのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。この章では、パフォーマンス・チューニングに関する一般的な考慮事項と関連のドキュメント・リソースを示しますが、チューニングが必要な分野をすべて網羅してはいません。

9.2 効率的なSQL文およびSQL問合せ

この項では、効率的なSQL文およびSQL問合せの使用について説明します。表9-1と表9-2に、SQL文およびSQL問合せに関連したチューニング・パラメータとパフォーマンス上の推奨事項を示します。

表9-1 EJB/JPAでの効率的なSQL文およびSQL問合せの使用

チューニング・パラメータ

説明

パフォーマンス上の注意点

パラメータ使用のSQLのバインディング

パラメータ使用のSQLおよびプリコンパイル文のキャッシュを使用すると、コール頻度の高い問合せのSQLがデータベースのSQLエンジンによって解析およびプリコンパイルされる回数が減少し、パフォーマンスが向上します。EclipseLinkでは、パラメータ使用のSQLがデフォルトで有効になります。ただし、データベースやJDBCドライバの中には、このオプションをサポートしないものもあります。Oracle Application ServerにバンドルされているOracle JDBCドライバは、このオプションをサポートしていませんので注意してください。これを構成するには、persistence.xmlの永続性プロパティeclipselink.jdbc.bind-parametersを使用します。

関連項目: 「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)および「Querying」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying)

デフォルト値: PERSISTENCE_UNIT_DEFAULT(デフォルトでtrue)

選択したデータベースやJDBCドライバが前述のオプションをサポートしている場合は、パラメータ使用のSQLのバインディングを有効のままにしてください。

JDBC文キャッシュ

文キャッシュは、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を軽減するために使用します。文キャッシュによって、データベースを使用するアプリケーションのパフォーマンスが向上します。

注意: Java EEアプリケーションには、データ・ソースの文キャッシュを使用します(JB3.0/JPAのEclipseLink文キャッシュは使用しません。例: "eclipselink.jdbc.cache-statements"="true")。

Oracle Weblogicデータ・ソースでこのオプションを設定するには、構成オプション「文キャッシュ・タイプ」および「文キャッシュ・サイズ」を設定します。

『Oracle Fusion Middleware 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.read-onlyを使用して設定します。

@ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定することもできます。

デフォルト値: False

最適なパフォーマンスを得るために、結果オブジェクトが変更されない問合せには読取り専用を使用します。

firstResultとmaxRows

これらは、大規模な問合せのページングに使用するJPA問合せプロパティです。通常、これらのプロパティは、多数の行を返す問合せの結果セット全体が必要ではない場合に使用できます。たとえば、ユーザーが特定の結果を求めて結果セットを(一度に1ページずつ)スキャンし、レコードが見つかってしまえば残りのデータは破棄するような場合です。

大きな結果セットが得られるが、オブジェクトのサブセットのみが必要になるような問合せに対して使用します。

順序番号の事前割当て

順序番号の事前割当てを行うと、一連のIDをデータベースに対して同時に問い合せることができ、挿入のたびにデータベースにアクセスしてIDを取得する必要がなくなります。

デフォルト値: 50

常に順序番号の事前割当てを使用すると、挿入のパフォーマンスが最適化されます。最適なパフォーマンスを得るには、事前割当てが行えないIDENTITY順序付けではなく、SEQUENCE順序付けまたはTABLE順序付けを使用してください。

9.2.1 エンティティ・リレーションシップ問合せパラメータのチューニング

表9-2に、パフォーマンス・チューニング用のエンティティ・リレーションシップ問合せパラメータを示します。

表9-2 EJB3.0エンティティ・リレーションシップ問合せのパフォーマンス・オプション

チューニング・パラメータ

説明

パフォーマンス上の注意点

バッチ・フェッチ

eclipselink.batchヒントは、EclipseLinkにバッチ処理情報を提供します。これにより、関連オブジェクトに対する後続の問合せがバッチ内で最適化されるため、オブジェクトを1つずつ取得したり、大規模な1つの結合読取りで取得したりすることを回避できます。

バッチ・フェッチにはJOIN、EXISTSおよびINの3つのタイプがあります。タイプは、問合せヒントeclipselink.batch.typeを使用して設定します。

バッチ処理は、SELECT句にオブジェクトが1つしかない問合せに対してのみ実行できます。これを構成するための問合せヒントはeclipselink.batchです。バッチ・フェッチは、@BatchFetchアノテーションを使用して設定することもできます。

デフォルト値: Off

必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。

バッチ・フェッチは、重複したデータの読取りを回避できるため、結合より効率的です。したがって、バッチ・フェッチがサポートされている問合せのパフォーマンスを最適化するには、結合読取りではなくバッチ・フェッチを使用することを検討してください。

結合フェッチ

結合フェッチとは、あるクラスの1回の問合せで、そのクラスと関連オブジェクトのインスタンス作成に必要なデータが返されるようにする、問合せ最適化機能です。

この機能は、データベース・アクセスを減らして問合せのパフォーマンスを改善するために使用します。デフォルトでは、リレーションシップに対して結合読取りは行われません。遅延ロードを使用している場合は、各リレーションシップがアクセス時に別々にフェッチされ、遅延ロードを使用していない場合は、別々のデータベース問合せとしてフェッチされます。

結合の使用は、JPQL (JOIN FETCH)で指定するか、問合せヒントeclipselink.join-fetchの中で複数のレベルで設定します。マッピング・アノテーション@JoinFetchで設定することもできます。

結合はJPA仕様の一部ですが、バッチ・フェッチは違います。また、結合の対象となるのは、バッチ・フェッチが行えない問合せです。たとえば、結合は、SELECT句に複数のオブジェクトを含む問合せ、単一の結果を返す問合せ、カーソルおよび最初/最大の結果に対して機能しますが、バッチ・フェッチは機能しません。

関連項目: 「Join Fetch」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying/Query_Hints#Join_Fetch)

デフォルト値: 使用しない

必要な表データへの列マッピングを持つ表の問合せに使用します。バッチ・フェッチまたは結合を使用するのは、すべてのデータにアクセスすることがわかっている場合にかぎります。リレーションシップにアクセスする予定がない場合は、インダイレクションを使用してロードを遅らせてください。SELECTのパフォーマンスを最適化するために、バッチ・フェッチがサポートされていない場合は結合を使用することをお薦めします。

遅延ロード

遅延ロードをOnにしていない場合、永続オブジェクトの取得の際に、そのオブジェクトの参照する従属オブジェクトがすべて取得されます。リレーションシップ・マッピングによってマップされた属性に対して遅延読取り(インダイレクション、遅延ロード、ジャストインタイム読取りとも呼びます)を構成すると、被参照オブジェクトのプレースホルダとしてインダイレクション・オブジェクトが使用されます。

その属性にアクセスするまで、従属オブジェクトの読取りは遅延されます。その結果、アプリケーションにとって重要なのは取得されたオブジェクトの内容のみであり、関連オブジェクトの内容は重要でないという場合は特に、パフォーマンスが大幅に向上します。

関連項目: 「Lazy Loading」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Basic_Mappings/Lazy_Basics)

デフォルト値: コレクション・マッピングの場合はOn(ToManyマッピング、@OneToMany、@ManyToMany)

デフォルト値: 参照の場合はOff(ToOneマッピング、@OneToOne、@ManyToOne)

(@OneToOneおよび@ManyToOneに対して遅延ロードをOnに設定するには、ウィービングが必要です。Java EEの場合、ウィービングはデフォルトでOnになっています。)

すべてのマッピングに対して遅延ロードを使用します。遅延ロードを使用し、バッチ・フェッチまたは結合を使用して被参照オブジェクトを問い合せるほうが、即時ロードより効率的です。

リレーションシップのインスタンス化を問合せで強制できるようにするLoadGroupsとともに最適化されたロードを使用することも検討できます。

9.3 キャッシュ構成のチューニング

この項では、EclipseLinkに付属しているデフォルト内部キャッシュのチューニングについて説明します。Oracle Toplink/EclipseLinkは、Oracle Coherenceとも統合できます。Oracle Coherenceを使用したEclipseLinkエンティティ・キャッシュの構成およびチューニングの詳細は、9.4項「Coherenceとの統合」を参照してください。

EclipseLink永続性マネージャおよびキャッシュとともに使用するEJB3.0/JPAのデフォルト設定は、ロックなし、キャッシュ・リフレッシュなしで、キャッシュの使用方法はDoNotCheckCacheです。(排他的アクセス権限がない場合に)アプリケーションでキャッシュを使用し、失効したデータをキャッシュから読み取らないようにするには、これらの設定に加えて、その他の分離関連の設定を適切に構成する必要があります。表9-3に、キャッシュ構成オプションを示します。

キャッシュ構成の詳細は、「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)を参照してください。

注意:

デフォルトでは、アプリケーションが使用データへの排他的アクセス権限を持つ(つまり、EclipseLink以外の外部アプリケーションがデータを変更することはない)ものと想定されます。アプリケーションがデータへの排他的アクセス権限を持たない場合は、表9-3に示すデフォルト値を一部変更する必要があります。

表9-3 EJB3.0 JPAエンティティとキャッシュ構成オプション

チューニング・パラメータ

説明

パフォーマンス上の注意点

オブジェクト・キャッシュ

EclipseLinkセッションには、オブジェクト・キャッシュが用意されています。EclipseLink永続性マネージャを使用するEJB3.0 JPAアプリケーションでは、このキャッシュをデフォルトで使用するEclipseLinkセッションが作成されます。セッション・キャッシュと呼ばれるこのキャッシュには、データベースとの間で読み書きされたオブジェクトの情報が格納されます。セッション・キャッシュは、EclipseLinkアプリケーションのパフォーマンスを改善するための重要な要素の1つです。

通常、サーバー・セッションのオブジェクト・キャッシュは、そのセッションから取得されたすべてのクライアント・セッションで共有されます。分離セッションは、共有オブジェクト・キャッシュから分離された固有のセッション・キャッシュを備えています。

アノテーション・タイプ@Cacheableは、エンティティをキャッシュするかどうかを指定します。persistence.xmlのキャッシュ要素の値がENABLE_SELECTIVEまたはDISABLE_SELECTIVEの場合、キャッシュは有効です。Cacheableアノテーションの値は、サブクラスによって継承されます。つまり、Cacheableをサブクラスで指定すると上書きできます。

Cacheable(false)は、プロバイダがエンティティとその状態をキャッシュする必要がないことを意味します。

デフォルト値: 有効(sharedがTrue)

一般に、キャッシュは有効にしておくことをお薦めします。常にデータベースから読み取られるオブジェクト(ペシミスティック・ロックの対象となるオブジェクトなど)がある場合は、そのエンティティのキャッシュを無効にしてください。また、アクセス頻度の低いエンティティのキャッシュを無効にすることも検討してください。

問合せ結果セット・キャッシュ

EclipseLinkでは、オブジェクト・キャッシュに加えて、問合せキャッシュもサポートされています。

- オブジェクト・キャッシュでは、主キーによってオブジェクトが索引付けされるため、主キー問合せでキャッシュ・ヒットを取得できます。オブジェクト・キャッシュを使用すれば、オブジェクトがすでに存在する場合に、データ・ソースにアクセスする問合せでオブジェクトとそのリレーションシップを構築するコストが発生しません。

- 問合せキャッシュは、オブジェクト・キャッシュと異なります。問合せキャッシュの索引は、オブジェクトの主キーではなく、問合せおよび問合せパラメータによって作成されます。そのため、同じパラメータで実行したどの問合せでも、問合せキャッシュ・ヒットを取得し、同じ結果セットを返すことができます。

問合せキャッシュの問合せヒントには次のものがあります。

eclipselink.query-cache

eclipselink.query-cache.size

eclipselink.query-cache.invalidation

関連項目: 「Caching」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching)および「EclipseLink JPA Query Hints」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Querying/Query_Hints)

デフォルト値: 使用しない

主キー以外のキーで頻繁に実行される問合せのうち、結果セットがあまり変わらないものに使用します。キャッシュ無効化タイムアウトとともに使用すると、必要に応じてリフレッシュができます。

キャッシュ・サイズ

キャッシュ・サイズは、次の永続性プロパティを使用して構成します。eclipselink.cache.size.<entity>

"eclipselink.cache.size.default"

eclipselink.cache.type.default

関連項目: 「Configuring Persistence Units Using persistence.xml」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Configuration/JPA/persistence.xml)および「Class PersistenceUnitProperties」(http://www.eclipse.org/eclipselink/api/2.3/org/eclipse/persistence/config/PersistenceUnitProperties.html)

デフォルト値: タイプSoftWeak、サイズ100(1エンティティ当たり)。

使用可能なメモリーの量、使用するクラスのインスタンス数、エンティティのアクセス頻度、および失効したデータの許容度に基づいたキャッシュの必要量を基準に、キャッシュ・サイズを設定します。

アクセス頻度の高いインスタンスが多いエンティティや、失効したデータが大した問題にはならないエンティティについては、サイズの大きなキャッシュを作成することを検討してください。

更新頻度が高く、常に最新のデータが必要とされるエンティティや、アクセス頻度の低いエンティティには、小さなキャッシュ・サイズを使用するか、キャッシュをまったく使用しないことを検討してください。

ロック

Oracleでは、表9-4に示すロック・ポリシー(ロックなし、オプティミスティック、ペシミスティック、読取り専用)をサポートしています。

ロックは、JPAの@Versionアノテーションeclipselink.read-onlyを使用して設定します。

「How to Use EclipseLink Locking」(http://wiki.eclipse.org/EclipseLink/Examples/JPA/Locking)

デフォルト値: ロックなし

同時に更新可能なエンティティには、ユーザーが他のユーザーの変更を上書きできないようなロック・ポリシーを使用することを検討してください。読取り専用エンティティのパフォーマンスを最適化するには、エンティティを読取り専用として定義するか、読取り専用の問合せヒントを使用することを検討してください。

キャッシュの使用方法

デフォルトでは、どのタイプの問合せも、まずデータベースを検索してからキャッシュと同期を取ります。問合せにリフレッシュが設定されている場合を除き、キャッシュされたオブジェクトはデータベースからリフレッシュされずに返されます。特定の問合せを、メモリー内キャッシュ、データベース、その両方のうち、いずれに対して実行するかを指定できます。

すでにキャッシュにあるオブジェクトがデータベースで検索されるのを防いでパフォーマンスを向上させるには、検索の際に必要なオブジェクトをまずキャッシュから取得し、オブジェクトがキャッシュに存在しない場合にのみデータ・ソース内を検索するよう構成します。主キーに基づいて単一オブジェクトを検索する問合せについては、問合せヒントeclipselink.cache-usageをCheckCacheByExactPrimaryKeyに設定します。

デフォルト値: DoNotCheckCache

通常はデータがキャッシュにあり、リフレッシュ処理をそれほど必要としない場合に、主キー問合せのパフォーマンスを高速化するには、まず主キー問合せでキャッシュをチェックすることをお薦めします(CheckCacheByExactPrimaryKeyを使用)。

これにより、まずデータベースからオブジェクトを取得した後、すでにキャッシュにあるオブジェクトを検索し、キャッシュされた値(問合せにリフレッシュが設定されている場合を除き、データベース・アクセスによって更新されていない)を返すというデフォルト動作を回避できます。

分離

EclipseLinkを使用するJPAアプリケーションには、特定のデータベース・トランザクションの分離レベルを単独で設定するチューニング・パラメータはありません。

一般的なEJB3.0 JPAアプリケーションでは、データベース・トランザクションの分離レベルが適用されるタイミング、および特定のデータベース・トランザクションを分離できる程度には、次のような様々な要素が影響を与えます。

- ロック・モード

- セッション・キャッシュの使用

- 外部アプリケーション

- データベース・ログイン・メソッドsetTransactionIsolation

関連項目: 「Shared and Isolated Cache」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Shared_and_Isolated)

キャッシュのリフレッシュ

デフォルトでは、EclipseLinkはデータ・ソースから読み取ったオブジェクトをキャッシュします。このオブジェクトに対する後続の問合せではキャッシュへのアクセスが行われるため、データ・ソースへのアクセスが減るとともに、オブジェクトとそのリレーションシップを再構築するコストも発生せず、パフォーマンスが向上します。問合せでデータ・ソースにアクセスする場合でも、返されたレコードに対応するオブジェクトがキャッシュに存在すれば、キャッシュ内のオブジェクトが使用されます。このデフォルトのキャッシュ・ポリシーは、失効したデータがアプリケーション内に生じる原因となります。

リフレッシュは、エンティティ・レベル(alwaysRefreshまたはrefreshOnlyIfNewerとexpiry)および問合せレベル(eclipselink.refresh問合せヒントを使用)で有効にできます。また、disableHitsを使用して、問合せが必ずデータベースに送られるようにすることも可能です。失効したデータや競合するデータがデータベースにコミットされないようにするには、適切なロック・ポリシーを使用するしかありません。

詳細は、9.3.1項「キャッシュ・リフレッシュのシナリオ」を参照してください。

関連項目: 「Caching Overview」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Caching_Overview)

デフォルト値: キャッシュのリフレッシュなし

エンティティ・レベルでのキャッシュのリフレッシュはできるかぎり避け、かわりに次の構成を検討してください。

- 問合せごとのキャッシュのリフレッシュ

- キャッシュの有効期限

- 分離キャッシュ

9.3.1 キャッシュ・リフレッシュのシナリオ

キャッシュでのデータのリフレッシュに関して、考慮すべきシナリオがいくつかあります。これらのシナリオはいずれも、パフォーマンスに影響を与えます。

- キャッシュされたデータではなく、最新のデータが常に必要な場合は、分離キャッシュ(Shared=False)を使用することを検討してください。これに当てはまるのは、アプリケーション内の特定のデータが頻繁に変更されるため、競合が検出されたときにのみデータをリフレッシュするのではなく、常にデータをリフレッシュすることが望ましいような場合です。

- 失効したデータは使用したくないが、失効したデータを取得することになっても大した問題ではないという場合は、解決策としてキャッシュ失効ポリシーを使用することをお薦めします。この場合は、ロック・エラー発生時に失効したオブジェクトを自動的にリフレッシュする、オプティミスティック・ロックも使用してください。オプティミスティック・ロックを使用する場合は、エンティティの@Cache属性であるalwaysRefreshおよびrefreshOnlyIfNewerをさらに有効にすると、データベースにアクセスする問合せで、返された失効オブジェクトをリフレッシュできるとともに、無効なオブジェクトが変更されていない場合はリフレッシュしないようにできます。また、リフレッシュされたデータが必要であることがわかっている場合に、特定の問合せ操作に対してリフレッシュを有効にしたり、クライアントから取得したデータをリフレッシュするオプション(リフレッシュ問合せをコールするもの)を提供したりすることもできます。

- データが失効していても問題ない場合は、オプティミスティック・ロックを使用してください。そうすると、ロック・エラーの際にキャッシュ内の失効したオブジェクトが自動的にリフレッシュされます。

9.3.2 ロック・モード

表9-4に示すロック・モードを、EclipseLinkのキャッシュ使用方法および問合せリフレッシュのオプションとともに使用すると、JPAを使用するEJBエンティティのデータ一貫性が保証されます。どの組合せも機能とパフォーマンスの両面に影響を与えますが、これらのオプションの設定は、たとえパフォーマンスのコストが発生したとしても、データを最新で一貫した状態に保つための機能上の要件を優先して決めるのが一般的です。

詳細は、「Locking」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking)を参照してください。

表9-4 ロック・モード・ポリシー

ロック・オプション

説明

パフォーマンス上の注意点

ロックなし

ユーザーが別のユーザーの変更内容を上書きできます。これはデフォルトのロック・モードです。エンティティが同時に更新されることがない場合や、read-committedセマンティクスによる同じ行の同時読取りおよび更新で十分な場合は、このモードを使用します。

デフォルト値: ロックなし

通常はロックなしのほうが高速ですが、データ一貫性のニーズには対応できない場合があります。

オプティミスティック

すべてのユーザーがデータへの読取りアクセス権限を持ちます。ユーザーが変更を加えようとした場合、そのユーザーがデータを読み取った後にデータが変更されていないか、アプリケーションによってチェックされます。

関連項目: 「Optimistic Locking」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping/Locking/Optimistic_Locking)

同じ行に対する同時更新を頻繁には実行しないと予想される場合、オプティミスティック・ロックを使用すれば、最適なパフォーマンスを得ながら、データの一貫性も保証することができます。

ペシミスティック

更新目的でデータにアクセスした最初のユーザーによって、更新処理が完了するまでデータがロックされます。

同じ行に対して頻繁に同時更新を実行することが予想される場合、同時アクセスの例外および再試行が多数発生するオプティミスティック・ロックより、ペシミスティック・ロックのほうが高速になることがあります。

エンティティ・レベルでペシミスティック・ロックを使用する場合は、最適なパフォーマンスを得るために、分離キャッシュ(Shared=False)を併用することをお薦めします。

読取り専用

EJB3.0 JPAエンティティを読取り専用に設定すると、そのエンティティは変更できなくなり、作業ユニットのパフォーマンスが最適化されます。

@ReadOnlyクラス・アノテーションを使用して、エンティティ・レベルで設定します。問合せヒントeclipselink.read-onlyを使用して、問合せレベルで設定することもできます。

エンティティを読取り専用として定義すると、読取り専用として定義されていないが、挿入、更新または削除を行わないエンティティよりも、パフォーマンスが向上します。これは、作業ユニットのパフォーマンスが最適化されるためです。すべての読取り専用操作に対して、常に読取り専用を使用してください。

9.4 Coherenceとの統合

Oracle Toplinkは、Oracle Coherenceと統合できます。この統合は、Oracle TopLink Grid機能によって実現されます。TopLink Gridを使用したEclipseLink JPAとの統合には、いくつかの種類があります。

例:

- EclipseLinkのデフォルトL2キャッシュをCoherenceに置き換えます。こうすることで、クラスタ・ノード全体をカバーする非常に大きなL2キャッシュがサポートされます。EclipseLinkのデフォルトL2キャッシュは、Java EEでホストされたマルチスレッド・アプリケーションが単一のJVMで稼働する場合のパフォーマンスを高めます。これをクラスタ全体で使用する場合は、特殊なキャッシュ調整機能を構成する必要があります。

- データベースではなく、Coherenceのデータ・グリッド内で問合せを実行するよう、エンティティを構成します。こうすると、クラスタ化されたアプリケーション・デプロイメントを、データベースがボトルネックとなるような操作を越えて拡張できます。

EclipseLink JPAとCoherenceキャッシュの併用の詳細は、グリッド上のJPA手法に関する項(http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/tlgug003.htm)を参照してください。

Oracle ToplinkとOracle Coherenceとの統合の詳細は、Oracle TopLinkとCoherenceグリッドとの統合ガイド(http://www.oracle.com/technology/products/ias/toplink/doc/11110/grid/toc.htm)を参照してください。

9.5 マッピングおよびディスクリプタの構成

EclipseLinkでは、オブジェクト表現とデータ・ソース固有の表現との間でデータのトランスフォーメーションを実行できます。このトランスフォーメーションをマッピングと呼びます。マッピングは、EclipseLinkプロジェクトの中核をなしています。

マッピングはそれぞれ、ドメイン・オブジェクトの単一データ・メンバーに対応しています。マッピングによって、オブジェクト・データ・メンバーをそのデータ・ソース表現と関連付け、オブジェクトとデータ・ソースの間の双方向変換を実行する手段を定義します。

マッピングの詳細は、「Configuring Mappings」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Mapping)を参照してください。

9.6 データのパーティション化

EclipseLinkでは、@Partitionedアノテーションを使用してデータのパーティション化を構成できます。パーティション化すると、アプリケーションはクラスタ・データベースなどの複数のデータベース間で情報を増減できます。@Partionedおよびその他のパーティション・ポリシー・アノテーションの使用方法の詳細は、「Data Partitioning」(http://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Advanced_JPA_Development/Data_Partitioning)を参照してください。

9.7 EclipseLink JPAエンティティのパフォーマンス分析

この項では、JPAアプリケーションのパフォーマンス分析に役立つEclipseLinkの機能をいくつか示します。

- パフォーマンスの監視の詳細は、『EclipseLink User's Guide』の「Performance Monitoring」を参照してください。このツールは、マルチスレッド化されたサーバー環境の情報をプロファイルおよび監視することを目的としています。

- パフォーマンスのプロファイリングについては、『EclipseLink User's Guide』の「Measuring EclipseLink Performance with the EclipseLink Profiler」を参照してください。このツールは、シングルスレッドの限定的なユースケースでの使用を想定しています。

- パフォーマンスの問題のデバッグおよびテストを行う場合、EclipseLinkから生成されたSQLを確認できます。SQLを確認するには、ロギング用のEclipseLink JPA拡張機能を使用して、ロギング・レベルをFINEに上げます。
最適なパフォーマンスを得るために、プロファイリングまたはデバッグが終了したら、必ずロギング・レベルをデフォルト・レベルに戻してください。

10 Oracle Web Cacheのパフォーマンス・チューニング

この章では、Oracle Web Cacheのパフォーマンスを改善するためのガイドラインを示します。

- 10.1項「Oracle Web Cacheについて」

- 10.2項「ハードウェア・リソースの最適化」

- 10.3項「ネットワーク接続の最適化」

- 10.4項「プラットフォームでの接続の最適化」

- 10.5項「キャッシュ・ヒット率の向上」

- 10.6項「レスポンス時間の最適化」

- 10.7項「Oracle ADFに対するパフォーマンスの最適化」

10.1 Oracle Web Cacheについて

Oracle Web Cacheは、Web層で使用されるコンテンツ認識型のサーバー・アクセラレータ(リバース・プロキシ)です。

Oracle Web Cacheは、Oracle Fusion Middlewareで提供される主要なキャッシュ・メカニズムです。キャッシュ機能は、頻繁にアクセスされるURLをメモリーに格納することによって、Oracle Fusion Middlewareで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性を改善します。また、Oracle HTTP ServerやOracle WebLogic Serverといった任意のWebサーバーまたはアプリケーション・サーバーで稼働するWebサイトのパフォーマンス、スケーラビリティおよび可用性も改善できます。

詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

10.2 ハードウェア・リソースの最適化

- ハードウェア・リソース

- メモリー構成

10.2.1 ハードウェア・リソース

Oracle Web Cacheは、非常に強力なCPU 1つ、またはCPU 2つで、最適なパフォーマンスを発揮します。Oracle Web Cacheはメモリー内キャッシュであるため、CPUサイクルの制限をほとんど受けません。CPUを追加しても、パフォーマンスが大幅に向上することはありません。ただし、プロセッサの速度は重要なので、できるだけ高速なCPUを使用してください。Web Cacheが他のOracleアプリケーション・サーバー・コンポーネントや他のアプリケーションとシステムを共有している場合は、使用するCPUを増やします。

Oracle Web Cacheは割当て可能なメモリー量によって制限されることに注意してください。メモリーを増やすと、パフォーマンスおよびスケーラビリティが改善します。必要なメモリーの量の詳細は、10.2.2項「メモリー構成」を参照してください。

Oracle Web Cacheには2つのプロセスがあります。1つは管理サーバー用、もう1つはキャッシュ・サーバー用です。

- 管理サーバー・プロセスは、Oracle Web Cacheの構成および監視に使用されます。このプロセスが消費するCPU時間はごくわずかです。ただし、Oracle Web Cache Managerで統計ページを表示する際、管理サーバー・プロセスは、キャッシュ・サーバー・プロセスに問い合せて、該当するメトリックを取得する必要があります。統計ページに頻繁にアクセスする、つまり統計ページのリフレッシュ頻度を高く設定すると、キャッシュ・サーバーのパフォーマンスに影響が出ることがあります。

- キャッシュ・サーバー・プロセスは、3つのスレッドを使用します。1つ目はフロントエンド・アクティビティの管理用、2つ目はバックエンド・アクティビティの管理用、3つ目はリクエストの処理用です。

Oracle Web Cacheをコスト効率よく使用するには、大量のメモリーを搭載した、高速な2 CPUのコンピュータ上で実行します。様々なデプロイメント・シナリオの詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

複数のOracle Web Cacheインスタンスが存在するWebサイトでは、各インスタンスをキャッシュ・クラスタの一部、またはスタンドアロン・インスタンスとして別の2 CPUノードにインストールすることを検討してください。Oracle Web Cacheインスタンスが別のノードにある場合、特にネットワーク・スループットの点で、オペレーティング・システムの制限を受けることが少なくなります。たとえば、2つの別々の2 CPUノード上に2つのキャッシュがある場合、1つの同じ4 CPUノード上に2つのキャッシュがある場合よりもオペレーティング・システムの制限を受けにくくなります。

他のリソースがCPUの使用をめぐってOracle Web Cacheと競合している場合、必要なCPUの数を決める際には、もちろんこれらのリソースの要件を考慮してください。最もよいのはOracle Web Cacheを別のノードに分けることですが、Oracle Web CacheをアプリケーションWebサーバーの残りの部分と同じノード上で実行したとしても、パフォーマンス上の大きな利点を得ることができます。

10.2.2 メモリー構成

スワッピングによってドキュメントがキャッシュから出し入れされるのを回避するには、キャッシュ用に十分なメモリーを構成します。一般に、Oracle Web Cacheのメモリー量(最大キャッシュ・サイズ)は512MB以上に設定する必要があります。アプリケーションのメモリー要件は、ドキュメント・サイズ、ドキュメント数、返されるHTTPヘッダーの数、ESIが存在するかどうかなどの要因によって変わります。必要なメモリーの最大量を厳密に見積るには、次に示す式を使用します。アプリケーションでESIを使用する場合は、TotalDocsおよびAvgDocSizeを計算する際に、テンプレートとドキュメント・フラグメントをすべて含める必要があります。

推定キャッシュ・サイズ(バイト) = 1.25 *(TotalDocs * ((AvgDocSize/8192+1) *8192+ 16384))

- 0.25は、実行時のメモリー使用率を表します。Web Cacheのアクション制限は、デフォルトでWeb Cacheの最大サイズより5%小さく設定されます。また、キャッシュできないアクセス・ミスを最適化するために、合計キャッシュ・サイズの5%が割り当てられます。

- TotalDocsは、Web Cacheに格納するドキュメントの総数を表します。

- AvgDocSizeの意味は、その名のとおりです。

- 式から返されるバイト単位の推定キャッシュ・サイズを変換することを念頭に置いてください。

前述のメモリー計算式を、実際に測定されたメモリー使用量に対して検証したところ、次の表に示すように、きわめて近い結果が得られました。

キャッシュされた数

ドキュメント・サイズ

測定されたキャッシュ

式から求めた結果

ドキュメント

バイト

サイズ(MB)

サイズ(MB)

3300.00

102400

499.61

499.51

5525.00

51200

499.27

499.08

11050.00

51200

998.54

998.17

6600.00

102400

999.22

999.02

13200.00

102400

1998.44

1998.05

22100.00

51200

1997.07

1996.34

3300.00

102400

499.61

499.51

10.2.2.1 Web Cacheメモリーの構成

Oracle Web Cacheを起動したとき、キャッシュは空です。監視を有効なものとするため、キャッシュが満杯になっていることを確認してください。つまり、指定した数のドキュメントがキャッシュされるように、キャッシュが十分な数のリクエストを受け取っていることを確認します。

Oracle Web Cacheの「統計」ページ(「監視中」→「Web Cache統計」)には、現在のメモリー使用量、最大のメモリー使用量、および現在Oracle Web Cacheに存在するドキュメントの総数についての情報が表示されます。キャッシュ概要表の次のメトリックに注意してください。

- キャッシュ内のドキュメントのサイズは、キャッシュの現在の論理サイズを示します。これは、キャッシュ内の有効なドキュメントのサイズです。たとえば、3KBと50KBの2つのドキュメントがキャッシュに格納されている場合、キャッシュ内のドキュメントのサイズは、2つのサイズを合計した53KBです。

- 構成済の最大キャッシュ・サイズは、「リソース制限」ページで指定した最大キャッシュ・サイズを示します。

- 現在の割当て済メモリーには、キャッシュの物理サイズが表示されます。これは、キャッシュの保存および処理用にOracle Web Cacheによって割り当てられたデータ・メモリーの量です。この数は、オペレーティング・システム統計の示すプロセス・サイズより常に小さくなります。これは、Oracle Web Cacheプロセスが他のユーザー・プロセスと同様に、指示記憶域、スタック・データ、スレッド、ライブラリ・データといった他の方法でもメモリーを消費するためです。

- 現在のアクション制限は、構成済の最大キャッシュ・サイズの95%です。通常、この数は現在の割当て済メモリーより大きくなります。

現在の割当て済メモリーが現在のアクション制限より大きい場合、Oracle Web Cacheは割り当てられているが使用されていないメモリーを使用し始めます。また、メモリーを解放するためにガベージ・コレクションを開始する場合もあります。ガベージ・コレクションの実行中、Oracle Web Cacheは、使用頻度が低く、有効性の低いドキュメントをキャッシュから削除し、頻繁に使用される有効なドキュメントはそのまま保持します。これにより、最大キャッシュ・サイズを超えずに、新しいHTTPレスポンス用の領域を確保することができます。

現在の割当て済メモリーが現在のアクション制限に近いか、それより大きい場合は、最大キャッシュ・サイズを増やし、スワッピングによってドキュメントがキャッシュから出し入れされるのを回避します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheシステム・コンポーネントのプロパティの指定に関する項を参照してください。

10.3 ネットワーク接続の最適化

- ネットワーク帯域幅

- ネットワーク接続

- ネットワーク関連パラメータ

10.3.1 ネットワーク帯域幅

Oracle Web Cacheを使用する際は、スループットの負荷に対応するための十分なネットワーク帯域幅が各システムにあることを確認してください。そうでないと、ネットワークが飽和状態になっても、Oracle Web Cacheの容量にまだ余裕があるという状況が発生します。たとえば、アプリケーションで1秒間に100メガビット以上のデータが生成される場合、10/100 Megabit Ethernetでは飽和状態になる可能性があります。

ネットワークが飽和状態になった場合は、10/100 Megabit Ethernetではなく、Gigabit Ethernetを使用することを検討してください。Gigabit Ethernetは、ネットワークでの衝突、再送信および帯域幅の不足を回避するための最も効率的なデプロイメント・シナリオを提供します。さらに、2つの異なるネットワーク・カードを使用することも検討してください。1つは受信クライアント・リクエスト用、もう1つはキャッシュからアプリケーションWebサーバーへのリクエスト用です。

ネットワーク帯域幅の使用状況を示すネットワーク監視ユーティリティを使用します。ネットワークが十分に活用されておらず、スループットが予想より低い場合は、CPUが飽和状態に達していないかを確認してください。

10.3.2 ネットワーク接続

Oracle Web Cacheサーバーの最大接続数制限には、妥当な数を指定することが重要です。設定した数が大きすぎると、パフォーマンスに影響を与え、レスポンス時間が長くなります。設定した数が小さすぎると、処理できるリクエストの数が減ります。レスポンス時間と同時に処理するリクエストの数のバランスを取ってください。

妥当な数を決定するには、次の要因を考慮します。

- ある時点で同時に処理するクライアントの最大数。

- ドキュメントの平均サイズと1ドキュメント当たりの平均リクエスト数。

- ネットワーク帯域幅。一度に送信できるデータの量は、ネットワーク帯域幅によって制限されます。

- キャッシュ・ミスの割合。キャッシュ・ミスは、アプリケーションWebサーバーに転送されます。これらのリクエストは、ネットワーク帯域幅をさらに消費します。その結果、キャッシュ・ミスとなったリクエストの割合が高い場合は特に、レスポンス時間が長くなります。

- ドキュメントの処理速度。ドキュメントの処理速度を測定するには、ttcpやLoadRunnerなどのネットワーク監視ユーティリティを使用します。

- キャッシュ・クラスタ環境がある場合のキャッシュ・クラスタ・メンバーの容量。容量は、他のキャッシュ・クラスタ・メンバーからの着信接続の数を表しています。クラスタ・メンバーの容量は、Oracle Web Cache Managerの「クラスタリング」ページ(「プロパティ」→「クラスタリング」)を使用して設定します。

警告:

前述の値は、無理に大きな値に設定しないでください。Oracle Web Cacheでは、メモリーなどの一部のリソースが各接続用に確保されます。これらの値を変更すると、パフォーマンスに悪影響を与える可能性があります。

オペレーティング・システムやOracle Web Cacheなどに付属している様々なツールを使用して、最大接続数を決定します。たとえば、netstat-aコマンドを使用すると、確立されている接続の数を確認できます。また、ttcpユーティリティでは、ドキュメントの処理速度を測定できます。Oracle Web Cache Managerには、ヒットおよびミスの統計が表示されます。

着信接続の最大数を設定する手順の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheシステム・コンポーネントのプロパティの指定に関する項を参照してください。

10.3.3 ネットワーク関連パラメータ

ネットワーク接続数に加えて、Oracle Web Cache、アプリケーションWebサーバー、およびオペレーティング・システムのその他のネットワーク関連パラメータもレスポンス時間に影響を与えます。ほとんどの場合、デフォルトの設定で十分です。

レスポンス時間が長い場合は、この項の説明に従って、接続に影響を与えるOracle Web Cache、アプリケーションWebサーバー、およびオペレーティング・システムのパラメータをチューニングしてください。

Oracle Web Cacheについては、次の設定の値を確認します。

- キープ・アライブのタイムアウト
Oracle Web Cacheがブラウザにレスポンスを送信した後、ネットワーク接続をオープンしておく時間。キープ・アライブを使用すると、HTTPクライアントは同じネットワーク接続を使用して、複数のリクエストをOracle Web Cacheに送信することができます。デフォルトでは、接続は5秒間オープンのままになります。これは通常、ブラウザが同じ接続を使用して後続のリクエストをOracle Web Cacheへ送信するのに十分な時間です。

ブラウザとOracle Web Cacheとの間のネットワークが遅い場合は、タイムアウトを増やすことを検討してください。まず10秒で、次に20秒で試し、最大30秒まで増やします。

次のエラーが表示された場合は、Oracle Web Cacheの最大着信接続数を増やすか、キープ・アライブのタイムアウトを小さくします。

11313: The cache server reached the maximum number of allowed incoming connections. Listening is temporarily suspended.

ストレス・テスト中など負荷が大きい場合に、クライアントがリクエストを1つ送信すると接続が切れる状態が続くときは、キープ・アライブのタイムアウトを0に設定します。この値の場合、Oracle Web Cacheはリクエストが完了するとすぐに接続をクローズし、リソースを解放します。

キープ・アライブのタイムアウトの値は、ネットワーク・タイムアウト・ページ(「プロパティ」→「ネットワーク・タイムアウト」)で設定します。

- オリジナル・サーバー・タイムアウト
アプリケーションWebサーバーがOracle Web Cacheへのレスポンスを生成するための時間。アプリケーションWebサーバーまたはプロキシ・サーバーがこの時間内にレスポンスを生成できない場合、Oracle Web Cacheはブラウザにネットワーク・エラー・ページを送信します。

通常、この値は、アプリケーションWebサーバーで処理された最も遅いドキュメントのレスポンス時間と一致させる必要があります。値が小さすぎると、実行時間の長いリクエストはレスポンスが完了する前にタイムアウトになります。値が大きすぎると、アプリケーションWebサーバーがなんらかの理由でハングしたときに、Oracle Web Cacheが別のアプリケーションWebサーバーにフェイルオーバーするまで時間がかかります。

この値は、ネットワーク・タイムアウト・ページ(「プロパティ」→「ネットワーク・タイムアウト」)で設定します。

アプリケーションWebサーバーについては、アプリケーションWebサーバーの構成ファイル(httpd.conf)で次の設定の値を確認します。(次に示すパラメータの名前はOracle HTTP Server固有のものです。)

- KeepAlive
永続的な接続を許可するかどうか。永続的な接続を使用すると、クライアントは同じ接続を通じて複数の連続したリクエストを送信できます。

KeepAliveが有効になっていることを確認してください。これにより、接続を一度確立すれば、同じクライアントからの後続のリクエストを受信できるよう接続がオープンのままになるので、パフォーマンスが向上します。

- KeepAliveTimeout: 同じクライアントからの次のリクエストを待って接続をオープンしておく時間。リクエストが主にOracle Web Cacheからの場合、この値はかなり大きく設定できます。妥当な値は30秒です。

- MaxKeepAliveRequests: 永続的な接続の間に許可するリクエストの最大数。0に設定すると、リクエストは無制限に許可されます。

- MaxClients: アプリケーションWebサーバーに同時に接続できるクライアントの最大数。

KeepAliveがアプリケーションWebサーバーに対して有効になっている場合、必要な同時httpdサーバー・プロセスが増える可能性があります。また、MaxClientsディレクティブを大きな値に設定することが必要になる場合もあります。

クライアント・リクエストのレスポンス時間が短い場合は、MaxClientsを小さい値に設定することで、パフォーマンスを改善できる可能性があります。ただし、MaxClientsの値に達すると、プロセスをそれ以上作成できなくなるため、他のリクエストが失敗します。アプリケーションWebサーバーのMaxClients制限には、Oracle Web Cache Managerで設定したアプリケーションWebサーバーの容量以上の値を設定してください。

オペレーティング・システムについては、TCPの待機時間設定を確認します。この設定は、オペレーティング・システムがポートを保持し、新しい接続がその同じポートを使用できないようにする時間を制御します。

Linuxオペレーティング・システムでは、/proc/sys/net/ipv4/tcp_fin_timeoutの値を確認します。Solarisオペレーティング・システムでは、次のコマンドを使用してtcp_time_wait_intervalの設定を確認します。

ndd -get /dev/tcp tcp_time_wait_interval.

Windowsでは、次のレジストリ・キーのTcpTimeWaitDelayの値を確認します。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

通常、この設定が問題となるのは、ストレス・テスト中に、1つのクライアント・コンピュータから常に多くのTCP/IP接続をオープンする場合のみです。そのような状況では、TCPの待機時間設定を小さくします。実際のデプロイメントでは、単一クライアントが多数の接続を生成することはほとんどないので、これが問題になることはまれです。

10.4 プラットフォームでの接続の最適化

- UNIXでの接続

- Windowsでの接続

10.4.1 UNIXでの接続

ほとんどのUNIXプラットフォームでは、クライアント接続ごとに別々のファイル・ディスクリプタが必要です。Oracle Web Cacheサーバーは、起動時に最大数のファイル・ディスクリプタを確保しようとします。root権限がある場合は、この数を増やすことができます。たとえば、Linuxオペレーティング・システムでは、/etc/security/limits.confでOracle Web Cacheのユーザー・ファイル・ディスクリプタ制限を変更することで、ファイル・ディスクリプタの最大数を増やすことができます。

たとえば、ユーザーWC_USERに4092の接続を許可するには、/etc/security/limits.confファイルに次のエントリを追加します。

WC_User soft nofile 4092
WC_User hard nofile 4092

/etc/sysctl.confファイルのfs.file-maxパラメータを増やして、ホスト上のすべてのプロセスが適切な数のファイル・ディスクリプタを使用できるようにしてください。

Solarisオペレーティング・システムでは、rlim_fd_maxパラメータを設定することで、ファイル・ディスクリプタの最大数を増やすことができます。webcachedがrootとして実行されていないと、Oracle Web Cacheサーバーは起動に失敗し、エラー・メッセージがログに記録されます。

10.4.2 Windowsでの接続

Windowsでは、ファイル・ハンドルおよびソケット・ハンドルの数(ページングされたプールおよびページングされていないプールのサイズ)は、使用可能なカーネル・リソースのみによって制限されます。ただし、アクティブなTCP/IP接続の数は、システムでオープン可能なTCPポートの数によって制限されます。

接続の確立の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のリソース制限およびネットワークしきい値の設定に関する項を参照してください。

10.5 キャッシュ・ヒット率の向上

キャッシュ・ヒットとは、キャッシュに保存されているドキュメントで対応可能な、Webブラウザによるリクエストです。キャッシュ・ミスとは、キャッシュに保存されているドキュメントでは対応できず、アプリケーションWebサーバーに転送する必要のある、Webブラウザによるリクエストです。

キャッシュ・ミスに対するキャッシュ・ヒットの比率が低い場合は、次の方法でキャッシュ・ヒット率を上げることを検討してください。

- CookieおよびURLパラメータを使用してキャッシュ・ヒット率を上げます。
Oracle Web Cacheでは、Cookieまたはヘッダーのリクエストに基づいて、同じURLを持つドキュメントの異なるバージョンをキャッシュできます。この機能を使用するには、ドキュメントを区別するCookieまたはヘッダーの作成など、簡単な変更をアプリケーションに加える必要があります。

アプリケーションに無意味なURLパラメータが含まれているために、同じコンテンツが異なるURLで表される場合があります。完全なURLでドキュメントをキャッシュすると、キャッシュ・ミスに対するキャッシュ・ヒットの比率は非常に低くなります。区別の不要なURLパラメータ値を無視するようOracle Web Cacheを構成すれば、単一のドキュメントが異なるURLに対してキャッシュされるようになり、キャッシュ・ヒット率が大幅に向上します。

一連のドキュメントのコンテンツがほとんど同一の場合もあります。たとえば、ドキュメント内のハイパーリンクが、セッション固有の異なる値を持つ同一のURLパラメータで構成されている場合や、ウェルカム・メッセージ、ショッピング・カートの合計などのパーソナライズされた文字列がドキュメントのテキストに含まれている場合などです。埋込みURLパラメータやパーソナライズされた文字列のプレースホルダを含むドキュメントを1つ保存しておき、そのドキュメントをクライアントに提供する際、正しい値をプレースホルダに動的に代入するように、Oracle Web Cacheを構成できます。

複数のバージョンのドキュメント、セッション、URLパラメータ値の無視、および単純なパーソナライズの詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のOracle Web Cacheの管理の概要に関する項を参照してください。

- リダイレクションを使用してエントリ・ドキュメントをキャッシュします。
一般にセッションの確立を必要とする、使用頻度の高いサイトのエントリ・ドキュメント(/など)の場合、セッションが確立されると、そのドキュメントはセッションを持たないすべての新しいユーザーに対して、事実上キャッシュ不可になります。確立されたセッションを保持したまま、このドキュメントをキャッシュするには、次のいずれかを実行します。

- すべての初期リクエストに対してセッションを確立して、使用頻度の高い実際のドキュメントにリダイレクトする、空白のドキュメントを作成します。使用頻度の高いドキュメントにリダイレクトされる後続のリクエストでセッションを指定すれば、そのドキュメントをキャッシュから取得できます。

- JavaScriptを使用して、使用頻度の高いドキュメントに対するセッションCookieを設定します。

注意:

セッションの確立を必要とするドキュメントのキャッシュ・ルールを構成する方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のコンテンツのキャッシュおよび圧縮に関する項を参照してください。

- 可能な場合はページの部分的なキャッシュを使用します。
OracleAS Portalによって生成されるページなど、多くのWebドキュメントは、一意のキャッシュ・プロパティを持つフラグメントで構成されています。このようなページの場合、ページ全体をキャッシュするのは不可能です。ただし、Oracle Web Cacheには、Edge Side Includes(ESI)を使用してページを部分的にキャッシュする機能があります。ESIを使用すれば、各Webページをテンプレートと複数のフラグメントに分割し、それをテンプレートと下位レベルのフラグメントにさらに分割することができます。各フラグメントまたはテンプレートは個別に保存および管理され、リクエストに応じて基礎となるフラグメントからページ全体が組み立てられます。異なるテンプレートでフラグメントを共有できるため、共通のフラグメントが何度もキャッシュされてキャッシュ領域が無駄になることはありません。フラグメントを共有することで、フラグメントの期限が切れたときに必要な更新の回数も大幅に削減できます。

アプリケーションによっては、フラグメントを更新するほうが、ページ全体を更新するよりコストがかかりません。さらに、各テンプレートまたはフラグメントに、期限切れ、検証、無効化などの独自のキャッシュ・ポリシーを設定できます。そうすることで、キャッシュされないフラグメントやキャッシュされる期間の短いフラグメントがある場合にも、完全なWebページの各フラグメントが可能なかぎりキャッシュされます。

- ESI変数を使用して、パーソナライズされたページのキャッシュ・ミスに対するキャッシュ・ヒットの比率を改善します。
パーソナライズされた情報がWebページに表示され、そのページが各ユーザーに固有のWebページになることがよくあります。たとえば、多くのWebページには、アプリケーション・セッションIDを埋め込んだハイパーリンクが何十、何百と含まれています。これを解決するには、変数を指定したESIページを作成します。変数は、リクエスト情報やレスポンス情報の様々な部分に解決できるため、テンプレートおよびフラグメントの一意性が大幅に軽減されます。その結果、キャッシュ・ミスに対するキャッシュ・ヒットの比率が向上します。

10.6 レスポンス時間の最適化

アプリケーションWebサーバーまたはキャッシュを正しく構成していない場合、レスポンス時間が予想より長くなることがあります。この項には、この章で説明した内容の大部分が要約されています。

アプリケーションWebサーバーのレスポンスが予想より遅い場合や、アプリケーションWebサーバーが容量に達したためにキャッシュからのリクエストに応答しない場合は、アプリケーションWebサーバーおよびOracle Web Cacheの設定を確認します。

まず、次の項目を確認します。

- キャッシュ・ルール: 適切なオブジェクトをキャッシュしていることを確認します。使用頻度の高いオブジェクトをキャッシュする必要があるのに、実際にはキャッシュしていない、ということはありませんか。「ポピュラーなリクエスト」ページ(「監視中」→「ポピュラーなリクエスト」)を使用して、最もよく使用されているリクエストのリストを調べ、それらのオブジェクトがキャッシュされているかどうかを確認します。

- キャッシュ・ルールの優先順位ランキング: 頻繁にアクセスされるキャッシュ不可のドキュメントには、キャッシュ可能なドキュメントより高い優先順位を指定します。頻繁にアクセスされるキャッシュ可能なドキュメントには、最も低い優先順位を指定します。多数のルールを定義すると、キャッシュ・ルールの解析時に大量のリソースを消費する可能性がありますので注意してください。

- 圧縮: ネットワークがクライアントのボトルネックになっている場合、キャッシュ時にドキュメントを圧縮すると、圧縮されたドキュメントはサイズが小さくなるため、ネットワーク上の輻輳が軽減されます。

さらに、次の項目を確認します。

アプリケーションWebサーバーの構成、特にMaxClients、KeepAlive、KeepAliveTimeoutおよびMaxKeepAliveRequestsの設定。

アプリケーションWebサーバーのMaxClients制限には、Oracle Web Cache Managerで設定したアプリケーションWebサーバーの容量以上の値を設定してください。

Oracle Web Cache Managerの「オリジナル・サーバー」ページ(「オリジナル・サーバー、サイトおよびロード・バランシング」→「オリジナル・サーバー」)を使用して設定したアプリケーションWebサーバーの容量。アプリケーションWebサーバーの容量を設定する方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

アプリケーションWebサーバーの負荷がまだ予想より高い場合は、キャッシュがリクエストを処理できず、アプリケーションWebサーバーにルーティングされるリクエストが増えている可能性があります。Oracle Web Cache Managerで次のOracle Web Cache設定を確認します。

- キャッシュ接続の数。「リソース制限」ページ(「プロパティ」→「リソース制限」)で、最大着信接続数を確認します。

- キャッシュのメモリー・サイズ。「リソース制限」ページ(「プロパティ」→「リソース制限」)で、最大キャッシュ・サイズを確認します。

- キャッシュ・クラスタの容量。キャッシュ・クラスタでは、クラスタの容量が小さすぎると、キャッシュが、指定された間隔でピア・キャッシュから所有コンテンツに対するレスポンスを受信できない可能性があります。その結果、リクエストはアプリケーションWebサーバーに送信されます。「クラスタリング」ページ(「プロパティ」→「クラスタリング」)で、容量を確認します。詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』を参照してください。

アプリケーションWebサーバーおよびOracle Web Cacheの設定は正しいが、レスポンス時間がまだ予想より長い場合は、システム・リソースを確認します。特に次の項目を確認してください。

- ネットワーク帯域幅

- CPU使用率

10.7 Oracle ADFに対するパフォーマンスの最適化

Oracle ADF Rich Clientアプリケーションに対するOracle Web Cacheのパフォーマンスを最適化するには、次の構成オプションを検討してください。

- Oracle Web Cache Managerの「リソース制限」ページで「最大キャッシュ・サイズ」設定を構成した後、シミュレーションした負荷または実際の負荷を使用してキャッシュを監視し、実際に使用されるメモリーの量を確認します。メモリー使用量が増加した結果、ホストでディスクへのメモリー・スワッピングが発生していないかチェックします。メモリー・スワッピングが発生すると、パフォーマンスに影響が出ます。

- すべてのサイトに適用されるパーソナライズおよび圧縮のルールには、次のものがあります。

- イメージは、キャッシュするが圧縮は行いません。

- CSSファイルは、すべてのリクエスト・タイプについてキャッシュと圧縮の両方を行います。

- JSファイルは、すべてのリクエスト・タイプについてキャッシュと圧縮の両方を行います。

- HTMLファイルは、キャッシュと圧縮の両方を行います。

- SWFファイルは、キャッシュするが圧縮は行いません。

- すべてのGETおよびPOSTSについて.jspxファイルを圧縮する(キャッシュはしない)ルールを追加します。

- すべてのGETおよびPOSTSについて\.jspx.*$ファイルを圧縮する(キャッシュはしない)ルールを追加します。

- すべてのリクエスト・タイプについてadw\.jspxを圧縮する(キャッシュはしない)ルールを追加します。

- すべてのリクエスト・タイプについてprofiling.jsを圧縮する(キャッシュはしない)ルールを追加します。

キャッシュおよび圧縮のルールを設定する方法の詳細は、『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』のコンテンツのキャッシュおよび圧縮に関する項を参照してください。

第IV部

SOA Suiteコンポーネント

この部では、パフォーマンスの向上を目的とするOracle Service-Oriented Architecture(SOA)Suiteコンポーネントの構成について説明します。Oracle SOA Suiteは、Oracle Fusion Middlewareのコンポーネントです。Oracle SOA Suiteは、SOAコンポジット・アプリケーションの設計、デプロイおよび管理を目的とするサービス・インフラストラクチャ・コンポーネント一式を備えています。次の図は、Oracle SOAプラットフォームを示しています。

図soa_arch.gifの説明

Oracle SOA Suiteでは、サービスを作成して管理し、SOAコンポジット・アプリケーションに組み込むことが可能です。コンポジットを使用すれば、複数のテクノロジ・コンポーネントを組み合せて1つのSOAコンポジット・アプリケーションを簡単に作成できます。SOAコンポジット・アプリケーションは次のもので構成されています。

- サービス・コンポーネント: サービス・コンポーネントは、SOAコンポジット・アプリケーションの基本的な構成要素です。サービス・コンポーネントは、SOAコンポジット・アプリケーションのビジネス・ロジック全体のうち、一部分を実行します。サービス・コンポーネントの例としては、BPELプロセス、Oracle Mediator、ヒューマン・タスク・フロー、意志決定サービスなどがあります。

- バインディング・コンポーネント: バインディング・コンポーネントは、SOAコンポジット・アプリケーションを外部のサービス、アプリケーションおよびテクノロジに結び付けます。バインディング・コンポーネントは2つのグループに分けられます。

- サービス: 外部の世界からSOAコンポジット・アプリケーションへの入り口となります。サービスのWSDLファイルは、サービスの機能を外部アプリケーションに公開します。サービス・バインディングには、SOAコンポジット・サービスを呼び出す方法(SOAPを使用するなど)が定義されています。

- 参照: SOAコンポジット・アプリケーションから外部サービスへのメッセージの送信を可能にします(たとえば、パートナ・リンクがBPELプロセスに提供するのと同じ機能を、それより高いSOAコンポジット・アプリケーション・レベルで提供するなど)。

SOA Suiteコンポーネントについては、次の章で説明します。

- 第11章「SOA Suiteコンポーネントの一般的なチューニング」

- 第12章「Oracle Business Rulesのパフォーマンス・チューニング」

- 第13章「Oracle BPEL Process Managerのパフォーマンス・チューニング」

- 第14章「Oracle Mediatorのパフォーマンス・チューニング」

- 第15章「Oracle Business Process Managementのパフォーマンス・チューニング」

- 第16章「Oracle Human Workflowのパフォーマンス・チューニング」

- 第17章「Oracleアダプタのパフォーマンス・チューニング」

- 第18章「Oracle Business Activity Monitoringのパフォーマンス・チューニング」

- 第19章「User Messaging Serviceのパフォーマンス・チューニング」

- 第20章「Oracle B2Bのパフォーマンス・チューニング」

11 SOA Suiteコンポーネントの一般的なチューニング

この章では、複数のSOA Suiteアプリケーションに適用可能なチューニング構成について説明します。

- 11.1項「SOA Suiteの構成プロパティについて」

- 11.2項「SOAインフラストラクチャの構成」

- 11.3項「SOA構成パラメータの変更」

- 11.4項「JVMチューニング・パラメータ」

- 11.5項「データベースの設定」

SOA Suiteアプリケーションの詳細は、第IV部「SOA Suiteコンポーネント」でアプリケーション別セクションのリストを参照してください。

注意:

その他のSOAのチューニング推奨事項は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「大規模ドキュメントおよび多数のインスタンスの管理」を参照してください。

11.1 SOA Suiteの構成プロパティについて

SOAアプリケーションの構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

11.2 SOAインフラストラクチャの構成

SOAインフラストラクチャの構成パラメータは、SOAインフラストラクチャ全体に影響を与えます。次の構成は、SOA-INFRAコンポーネントを通じて変更します。

- SOAインフラストラクチャ監査レベルの表示および設定

- SOAコンポジット・アプリケーション・インスタンスの状態のキャプチャ

- 受信メッセージのペイロード検証の有効化

- コールバック・サーバーURLおよびサーバーURLの指定

- UDDIレジストリ・プロパティの設定

- データ・ソースのJNDIロケーションの表示

- 致命的でない接続の再試行回数の設定

- Webサービス・バインディング・プロパティの設定

SOA構成の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のSOAインフラストラクチャ・プロパティの構成に関する項を参照してください。

11.2.1 監査レベル

「監査レベル」プロパティを使用すると、メッセージ・トラッキング・インフラストラクチャによって収集する情報のレベルを選択できます。この情報は、SOAインフラストラクチャに関連付けられたインスタンス・データ・ストア(データベース)に収集されます。この設定は、ログ・ファイルに書き込まれる内容には影響を与えません。

値

説明

オフ

コンポジット・インスタンスのトラッキングおよびペイロードのトラッキングに関する情報は収集されません。ロギングは実行されません。Oracle Enterprise Manager Fusion Middleware Controlコンソールでロギングもインスタンスの表示も行わなければ、インスタンス処理のパフォーマンスがわずかに向上することがあります。インスタンスは作成されますが、表示されません。

本番

コンポジット・インスタンスのトラッキングは収集されますが、Oracle Mediatorサービス・エンジンではペイロード詳細が収集されず、プロセス・サービス・エンジンではassignアクティビティのペイロード詳細が収集されません(その他のアクティビティのペイロード詳細は収集されます)。このレベルは、通常の本番操作に最適です。

開発

コンポジット・インスタンスのトラッキングとペイロード詳細のトラッキングの両方を有効にします。ただし、この設定はパフォーマンスに影響を与える可能性があります。このレベルは主に、テストおよびデバッグの際に便利です。

11.2.2 コンポジット・インスタンスの状態

CompositeInstanceStateEnabledプロパティを使用すると、SOAコンポジット・アプリケーション・インスタンスの状態を構成できます。ただし、このオプションを有効にした場合、インスタンス処理中のパフォーマンスに影響が出ることがあります。このオプションによって、実行中のインスタンスを個別にトラッキングできます。すべてのインスタンスが実行中または停止中としてキャプチャされます。この情報は後で、SOAインフラストラクチャおよびSOAコンポジット・アプリケーションのコンポジット・インスタンス表の「状態」列に表示されます。有効な状態は、実行中、完了、フォルト、「リカバリが必要、失効、終了、一時停止および状態なしです。

11.2.3 instanceTrackingAuditTrailThreshold

このパラメータは、監査証跡の作成時にそのサイズを制限するのに使用します。デフォルト値は1MBです。監査証跡がinstanceTrackingAuditTrailThresholdサイズ(デフォルトでは1MB)を超えると、例外がスローされ、監査証跡は完全には作成されません。値はバイト単位であるため、デフォルト値は1024*1024です。このパラメータは、監査証跡が作成されるSOAサーバーで大量のまたはすべての使用可能なメモリーが膨大な監査証跡によって消費されないようにするため、パフォーマンスに影響を与える可能性があります。そのため、様々な意味で安全な抑制手段として機能します。ただし、Enterprise Managerから監査証跡を取得しているときに、instanceTrackingAuditTrailThresholdを超えたことを示す例外を受けとった場合、デフォルト値の増加が必要になることがあります。

11.2.4 ロギング・レベル

デフォルトのロギング・レベルはNOTIFICATIONです。ストレス・テスト用の環境や本番環境では、可能なかぎりERRORやWARNINGなどの最低限のロギング・レベルを使用することを検討してください。

アプリケーションのロギング・レベルを設定する方法の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のログ・ファイルの構成に関する項を参照してください。

11.3 SOA構成パラメータの変更

SOA soa-infraレベルの構成は、Oracle Enterprise Managerを使用して設定できます。

詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「Oracle SOA SuiteおよびOracle BPM Suiteの管理の開始」を参照してください。

11.4 JVMチューニング・パラメータ

JVMパラメータは、SOAのパフォーマンスに影響を与える可能性があります。SOAコンポーネントのパフォーマンスに影響を与える主な要因は、ヒープ・サイズに関することです。JVMのパフォーマンス・チューニングの詳細は、2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。

11.5 データベースの設定

データベース構成をチューニングすると、SOA Suiteアプリケーションにも効果が現れることがあります。構成および個々の設定は、ユースケースによって異なります。データベース・プロパティのチューニングの詳細は、ご使用のデータベースの管理マニュアルを参照してください。

データベース・チューニングに関するその他の基本的なガイドラインは、2.6項「データベース・パラメータのチューニング」を参照してください。

11.5.1 SOAのデータ・ソースの構成

SOAでは、アプリケーション・サーバーで管理されているデータ・ソースを使用して、データベース接続を取得します。SOAのデータ・ソースは、WebLogic Serverコンソールを使用して構成できます。WebLogic Serverコンソールの使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

パフォーマンスが問題になっている場合は、次のデータ・ソース構成を検討してください。

- データ・ソースを構成する際には、接続プールに十分な数の使用可能な接続があることを確認します。

- 文キャッシュを使用すると、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を解消できます。文キャッシュを使用することで、アプリケーション・サーバーとデータベース・サーバーの間の通信がパフォーマンスに与える影響も軽減できます。

- 不要な接続テストおよびプロファイリングは無効にします。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のJDBCストアのチューニングに関する項を参照してください。

11.5.2 表および索引の管理

データがレンジ・パーティション化に適しておらず、パフォーマンスおよび管理の容易性を目的にパーティション化を行う場合に、表および索引でハッシュ・パーティション化を使用することを検討してください。ハッシュ・パーティション化では、指定された数のパーティションにデータを均等に分配する方法が提供されます。パーティション・キーのハッシュ値に基づいて、行がパーティションにマッピングされます。ハッシュ・パーティションを作成および使用すると、データ配置が非常にチューニングしやすくなります。これは、これらの均等なサイズのパーティションをI/Oデバイス間で分散(ストライプ化)することにより、可用性およびパフォーマンスに影響を与える可能性があるためです。

パフォーマンスを向上するには、次の表および索引でハッシュ・パーティション化を使用することを検討してください。

パーティション化される表名

パーティション・タイプ

数値

AUDIT_COUNTER

AC_PK索引のハッシュ・パーティション化

なし

CUBE_INSTANCE

パーティション化および逆引きキー索引CI_CREATION_DATE

なし

CUBE_SCOPE

ハッシュによるパーティション(CIKEY)

パーティション数 = 200

MEDIATOR_CASE_INSTANCE

ハッシュによるパーティション("ID")

パーティション数 = 200

XML_DOCUMENT

ハッシュによるパーティション(document_id)

パーティション数 = 200

ハッシュ・パーティション化される索引

COMPOSITE_INSTANCE_CREATED

BRDECISIONINSTANCE_INDX3

MEDIATOR_INSTANCE_INDEX2

MEDIATOR_INSTANCE_INDEX5

MEDIATOR_INSTANCE_INDEX6

MEDIATOR_INSTANCE_INDEX1

MEDIATOR_INSTANCE_INDEX3

MEDIATOR_CASE_INSTANCE_INDEX2

MEDIATOR_CASE_DETAIL_INDEX1

REFERENCE_INSTANCE_CO_ID

CI_NAME_REV_STATE

DOC_DLV_MSG_GUID_INDEX

STATE_TYPE_DATE

11.5.3 Weblogic Serverのパフォーマンス・チューニング

Weblogic Serverの完全なパフォーマンス・チューニングについては、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』を参照してください。

12 Oracle Business Rulesのパフォーマンス・チューニング

Oracle Business Rulesテクノロジは、ビジネス・ルールの自動化、およびJavaコードやBPELプロセスといった手続き型ロジックからのビジネス・ルールの抽出を可能にします。

この章の内容は次のとおりです。

- 12.1項「Oracle Business Rulesについて」

- 12.2項「チューニングに関する基本的な考慮事項」

12.1 Oracle Business Rulesについて

Oracle Business Rulesを使用すると、パフォーマンスが高く使いやすい形でビジネス・ルール・テクノロジを実装できます。使いやすいオーサリング環境、および推論機能を持つきわめて高パフォーマンスなルール・エンジンを備えています。Oracle Business Rulesは、Oracle Fusion Middlewareスタックの一部であり、多くのOracle製品(ミドルウェアとアプリケーションの両方を含む)のコア・コンポーネントとなります。

12.2 チューニングに関する基本的な考慮事項

ほとんどの場合、ルールを記述する際にパフォーマンスに注意を払う必要はありません。ただし、どのテクノロジにも言えることですが、パフォーマンスを最大化するのに役立つヒントやコツがありますので、必要に応じて利用してください。考慮事項の大半は、データ・モデルの初期構成に関するものです。

- 12.2.1項「Java Beansの使用」

- 12.2.2項「複数の逆参照を使用するかわりに子ファクトをアサート」

- 12.2.3項「ルール条件における副作用の回避」

- 12.2.4項「ルール条件における高コストの操作の回避」

- 12.2.5項「パターンの順序の検討」

- 12.2.6項「ルール条件におけるテストの順序の検討」

- 12.2.7項「AssertXPathおよびSupports XPathのかわりに関数を使用」

12.2.1 Java Beansの使用

ルール・エンジンの効率が最も高いのは、推論するファクトがJava Beans(またはRLクラス)であり、関連付けられたテストにBeanプロパティが含まれている場合です。Beanでは、各Beanプロパティのgetメソッドおよびsetメソッド(setが使用可能な場合)を公開する必要があります。Java Beansでアプリケーション・データを直接利用できない場合は、そのデータをフラット化して、ファクトとしてアサートされる(さらにルールで使用される)Java Beansのコレクションにします。

12.2.2 複数の逆参照を使用するかわりに子ファクトをアサート

Account.Contact.Addressのような式には、オブジェクトの逆参照が複数含まれています。ルール条件では、これは単独の逆参照を含む式ほど効率的ではありません。ベスト・プラクティスとして、ファクト・タイプは可能なかぎりフラット化してください。ファクト・タイプが階層構造を伴う場合は、assertXPathまたはその他の方法で、オブジェクト階層をアサートすることを検討してください。つまり、前述の例では、AccountとContactの両方をファクト・タイプとしてアサートします。

12.2.3 ルール条件における副作用の回避

ルール条件では、値や状態の変更といった副作用を持つメソッドまたは関数を使用しないでください。ルール・エンジンがReteネットワークを構築したときに行われる最適化、ならびにファクトとして実行されるReteネットワーク操作がアサート、変更(および再アサート)または取り出されたときに行われる最適化により、ルール条件内のテストが評価される回数は、手続き型プログラムに比べて多くなったり、少なくなったりします。メソッドまたは関数に副作用がある場合、その副作用が発生する回数は予測できません。

12.2.4 ルール条件における高コストの操作の回避

ルール条件では、コストの高い操作を避けてください。コストの高い操作とは、I/O(ディスクまたはネットワーク)や大量の計算処理を伴う操作です。一般に、I/OやDBMSにルール・エンジンから直接アクセスするのは避けることを検討してください。このような操作は、ルール・エンジンの外部で行います。コストの高いその他の操作や計算については、計算処理を実行し、その結果をJavaファクトまたはRLファクトとしてアサートすることを検討してください。これらのファクトは、コストの高い操作ではなく、ルール条件で使用されます。

12.2.5 パターンの順序の検討

ルール・パターンの順序を変更すると、時間またはメモリー使用量、あるいはその両方の点でルール評価のパフォーマンスが向上します。ルール条件内のファクト句(パターン)の順序を決定する際には、主なガイドラインとして次の2点に従ってください。

- あるファクトがルール評価中に変更されない(頻繁には変更されない)と予想される場合は、そのファクト句を、頻繁に変更されるファクト句より前に配置します。つまり、予想される変更頻度が低いものから高いものへとファクト句を並べます。このようにファクト句を並べると、ルール評価のパフォーマンス(所要時間)が向上します。

- あるファクト句(そのファクトのみを伴うテストを含む)の一致するファクトが、ルール条件内の他のファクト句より少ないと予想される場合は、そのファクト句を他のファクト句より前に配置します。つまり、限定性が最も高い(一致するファクトが最も少ない)ものから低いものへとファクト句を並べます。こうすることで、ルール評価中に使用されるメモリーの量が減少します。また、パフォーマンスが向上することもあります。

この2つのガイドラインは対立することがあります。その場合は、いろいろと試したうえで最適な順序を見つけてください。

12.2.6 ルール条件におけるテストの順序の検討

ファクト句と同様に、ルール条件内のテストは、限定性の高いものが限定性の低いものより前に来るように並べてください。そうすれば、ルール条件を満たさないファクトに必要な計算処理の量を減らすことができます。限定性の度合いが不明な場合や、一連のテストの限定性が同程度になる予想される場合は、単純なテストをコストの高いテストより前に配置してください。

12.2.7 AssertXPathおよびSupports XPathのかわりに関数を使用

ルール・エンジンが行う作業のほとんどは、アサート、取出しまたは変更の操作中に実行されます。その中でも、assertXPathは非常に便利ですが、パフォーマンスに影響を与えることがあります。このメソッドには、1つのコールで階層全体をアサートするだけでなく、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());
}

assertXPathのパフォーマンスを改善するには、Rule Authorの「ディクショナリ・プロパティ」ページで、「パフォーマンスのために改善されたassertXPathサポートを有効化」チェック・ボックスを選択します。この機能を利用するには、次の条件を満たす必要があります。

- XPath式//*のみを使用してassertXPathを呼び出すこと。他のXPath式を使用すると、RLIllegalArgumentExceptionが発生します。

- XLinkファクトはアサートされないため、XLinkファクトをルール条件で使用しないこと。

13 Oracle BPEL Process Managerのパフォーマンス・チューニング

Oracle Business Process Execution Language(BPEL)Process Managerには、コンポジット、ファブリック、アプリケーション、サーバーの各レベルでパフォーマンスを最適化するために構成可能なプロパティ設定がいくつか用意されています。この章では、各プロパティ設定について説明し、プロパティ設定の使用方法に関する推奨事項を示します。

この章の内容は次のとおりです。

- 13.1項「BPEL Process Managerについて」

- 13.2項「チューニングに関する基本的な考慮事項」

- 13.3項「コンポジット内で設定するBPELプロパティ」

- 13.4項「インスタンス・データ増大の影響を受ける表」

13.1 BPEL Process Managerについて

BPELとは、一連の独立したサービスを集めてエンドツーエンドのプロセス・フローを組み立てるための標準です。BPELを使用すれば、プロセス統合の取組みのコストおよび複雑さを大幅に軽減できます。Oracle BPEL Process Managerは、BPELビジネス・プロセスの作成、デプロイおよび管理を目的とした、包括的で使いやすいインフラストラクチャを提供します。

詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「BPELプロセスのサービス・コンポーネントとエンジンの構成」と『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「BPELプロセス・サービス・コンポーネントの使用」を参照してください。

13.2 チューニングに関する基本的な考慮事項

この項では、BPELエンジン・レベルでのパフォーマンス・チューニング・プロパティについて説明します。これらのプロパティは、Oracle Enterprise Managerを使用して構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のBPELプロセス・サービス・エンジン・プロパティの構成に関する項を参照してください。

注意:

この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

13.2.1 BPELスレッド・モデル

ディスパッチャは、実行するディスパッチャ・メッセージをスケジュールする際に、そのメッセージをスレッド・プールにエンキューすることができます。各ディスパッチャ・セットには、スレッド・プール(java.util.concurrent.ThreadPoolExecutor)が1つ含まれます。実装されたBPELスレッド・プールでは、メッセージがエンキューされるとスレッドに通知し、適切な数のスレッドがプール内でインスタンス化されるようにしています。

注意:

dspMinThreads、dspMaxThreads、dspInvokeAllocRatioの各構成プロパティは、Oracle 11gでは推奨されていません。また、Oracle 11gでは呼出しスレッドが専用のプールを持つため、dspInvokeAllocRatioは不要になりました。

13.2.1.1 ディスパッチャ・システム・スレッド

dspSystemThreadsプロパティには、システム・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。システム・ディスパッチャ・メッセージとは、通常はサーバーで迅速に処理される一般的なクリーン・アップ・タスク(ステートフル・メッセージBeanを元のプールへ解放するなど)です。一般に、実行時に生成される数のシステム・ディスパッチャ・メッセージは、ごく少数のスレッドで処理できます。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は2です。1スレッド未満の値は、デフォルト値に変更されます。

13.2.1.2 ディスパッチャ呼出しスレッド

dspInvokeThreadsプロパティには、呼出しディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。呼出しディスパッチ・メッセージは、受信したペイロードごとに生成されるもので、新規インスタンスのインスタンス化を目的としています。エンジンによって処理されるリクエストの大部分が(インスタンス・コールバックではなく)インスタンス呼出しである場合は、呼出しスレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もあります。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は20スレッドです。1スレッド未満の値は、デフォルト値に変更されます。

13.2.1.3 ディスパッチャ・エンジン・スレッド

dspEngineThreadsプロパティには、エンジン・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。エンジン・ディスパッチャ・メッセージは、アクティビティを非同期に処理する必要がある場合に必ず生成されます。デプロイされたプロセスの大部分が永続的で、多数のデハイドレーション・ポイント(プロセス途中のreceive、onMessage、onAlarmおよびwaitアクティビティ)がある場合は、エンジン・スレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もありますので注意してください。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は30スレッドです。1スレッド未満の値は、デフォルト値に変更されます。

13.2.1.4 ディスパッチャ最大リクエスト深さ

dspMaxRequestDepthプロパティには、同じリクエストの中で処理するメモリー内アクティビティの最大数を設定します。Oracle BPEL Process Managerは、アクティビティ・リクエストを処理した後、リクエストの有効性を損わずに後続のアクティビティをできるだけ多く処理しようとします。連続したアクティビティ処理がこの深さに達すると、インスタンスはデハイドレーションされ、次のアクティビティが別のトランザクションで実行されます。

リクエストの深さが大きすぎると、合計リクエスト時間がアプリケーション・サーバーのトランザクション・タイムアウト制限を超えることがあります。このプロセスは、永続プロセスに適用されます。

デフォルト値は600アクティビティです。

注意:

各スレッド・プールの最小スレッド数は1です。dsp*Threadsを0や負の数に設定することはできません。

13.2.2 監査

次のプロパティには、監査レベルを設定できます。

13.2.2.1 AuditLevel

auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_trail表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。

監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。監査レベルの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の監査レベル設定の優先順位の概要に関する項を参照してください。

値

説明

継承

インフラストラクチャ・レベルから監査レベルを継承します。

オフ

監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。

最小

すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。

エラー

管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。

本番

すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。

開発

すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。

13.2.2.2 AuditDetailThreshold

auditdetailthresholdプロパティには、監査証跡詳細文字列の最大サイズ(KB)を設定します。これを超えると、監査証跡詳細文字列が監査証跡とは別に格納されるようになります。監査証跡詳細文字列がしきい値設定より大きい場合、監査証跡詳細文字列は、監査証跡が最初に取得されたときに即座にロードされません。詳細文字列のサイズとともにリンクが表示されます。しきい値設定より大きな文字列は、audit_trail表ではなくaudit_details表に格納されます。

通常、詳細文字列にはBPEL変数の内容が含まれています。変数が非常に大きい場合は、変数を監査証跡に記録すると、パフォーマンスに重大な影響を与える可能性があります。

デフォルト値は50000(50KB)です。

13.2.2.3 AuditStorePolicy

このプロパティは、BPEL監査データを保持するための方針を指定します。

値

説明

syncSingleWrite (デフォルト)

監査証跡およびデハイドレーションは、1つのトランザクションでDBに対して保持されます。

syncMultipleWrite

監査証跡およびデハイドレーションは、同じスレッドの別個のトランザクションで保持されます。

async

監査証跡およびデハイドレーションは、別個のスレッドおよび別個のトランザクションによって保持されます。

デフォルトでは、監査メッセージはBPELメイン・トランザクションの一部として格納されます。BPELインスタンスは、フローがデハイドレーションに達するまで監査メッセージを保持し続けます。ユースケースによっては、たとえば、大規模なループがあり、デハイドレーション・ポイントがループ内にない場合、大量の監査ログがたまってしまいます。このため、メモリー不足問題が発生して、BPELメイン・トランザクションでタイムアウト・エラーが発生する可能性があります。syncMultipleWriteまたはasyncを使用して、監査メッセージをメイン・トランザクションとは別個に格納することを検討してください。

syncMultipleWriteおよびasync auditStorePolicyを使用する場合に、検討する必要がある他のプロパティがいくつかあります。次の各項を参照してください。

13.2.2.4 AuditFlushByteThreshold

このプロパティは、エンジンが監査イベントをフラッシュする頻度を制御します。基本的に現行バッチにイベントを追加した後に、エンジンは現行バッチのバイト・サイズがこの値より大きいかどうかを確認します。

asyncまたはsyncMultipleWriteの監査方式を使用している場合は、このプロパティのチューニングを検討してください。このサイズは、アプリケーションに基づいてチューニングする必要があります。

13.2.2.5 AuditFlushEventThreshold

このプロパティは、エンジンが監査イベントをフラッシュする頻度を制御します。基本的にイベント数がこの制限に達すると、エンジンはストア・コールをトリガーします。

asyncまたはsyncMultipleWriteの監査方式を使用している場合は、このプロパティのチューニングを検討してください。このサイズは、アプリケーションに基づいてチューニングする必要があります。

13.2.3 OneWayDeliveryPolicy

oneWayDeliveryPolicyは、Oracle 10gの構成プロパティdeliveryPersistencePolicyが基になっています。

新しい構成プロパティ名はbpel.config.oneWayDeliveryPolicyです。

警告:

このプロパティをasync.cacheに設定した場合に、システム障害が発生すると、メッセージが失われる可能性があります。詳細は、『Oracle BPEL Process Manager管理者ガイド』を参照してください。

oneWayDeliveryPolicyプロパティは、Oracle BPEL Serverに入るメッセージのデータベース永続性を制御します。デフォルトでは、受信リクエストは配信サービス・データベース表dlv_messageに保存されます。保存されたリクエストは、後でOracle BPEL Serverのワーカー・スレッドによって取得され、ターゲットのBPELプロセスへ配信されます。このプロパティは、配信メッセージを永続化するものであり、永続プロセスに適用されます。

oneWayDeliveryPolicyプロパティをasync.cacheに設定すると、一方向メッセージの到着頻度がOracle BPEL Serverによる配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。また、システムが過負荷の状態になり(メッセージがスケジュール済キューにたまり)、メモリー不足エラーが発生することもあります。各自のユースケース・シナリオを検討し、この設定が適切かどうかを判断してください。

一方向呼出しメッセージは、配信されるまで、配信キャッシュに格納されます。一方向メッセージの到着頻度がOracle BPEL Serverによる配信の頻度よりかなり高い場合や、サーバー障害が発生した場合には、メッセージが失われる可能性があります。

値

説明

async.persist(デフォルト)

配信メッセージはデータベースに保存されます。この設定の場合、信頼性は確保されますが、データベースのパフォーマンスに多少の影響が出ます。システムの全体的なパフォーマンスに影響が出ることもあります。

async.cache

受信した配信メッセージはメモリー内キャッシュにのみ保存されます。信頼性よりパフォーマンスを優先する場合は、この設定を検討してください。

sync

Oracle BPEL Serverに、呼出しキューのメッセージのスケジューリングをバイパスするよう指示し、BPELインスタンスを同期的に呼び出します。この設定は、データベースのパフォーマンスに影響を与えることがあります。

13.2.4 MaximumNumberOfInvokeMessagesInCache

このプロパティは、メモリー内キャッシュに保持できる呼出しメッセージの数を指定します。エンジンがこの制限に達すると、メモリー内キャッシュのディスパッチャにメッセージをプッシュし、かわりにDBにメッセージを保存するため、これらの保存されたメッセージはリカバリ・ジョブを使用してリカバリできます。無効にするには、値-1を使用します。

デフォルト値は100000です。

13.2.5 StatsLastN

StatsLastNプロパティには、最近処理されたリクエスト・リストのサイズを設定します。リクエストが終了するたびに、リクエストの統計がリクエスト・リストに保存されます。0以下の値を指定すると、統計収集が無効になります。パフォーマンスを最適化するには、統計収集が不要であれば無効にすることを検討してください。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

デフォルト値は-1です。

13.2.6 LargeDocumentThreshold

largedocumentthresholdプロパティには、大きなXMLドキュメントの永続性しきい値を設定します。これは、BPEL変数の最大サイズ(KB)です。これを超えると、BPEL変数が他のインスタンス・スコープ・データとは異なる表に格納されるようになります。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

インスタンス処理を行う必要が生じるたびに、大きなXMLドキュメントの読込みおよび書出しが絶えず行われる場合は、Oracle BPEL Server全体のパフォーマンスに影響が出ます。

デフォルト値は10000(100KB)です。

13.2.7 ValidateXML

validateXMLプロパティには、送受信するXMLドキュメントを検証するかどうかを指定します。Trueに設定すると、Oracle BPEL Process Managerは送受信するXMLドキュメントにスキーマ検証を適用します。スキーマに準拠しないペイロード・データが捕捉され、フォルトとして表示されます。

この設定は、SOAコンポジット・アプリケーションおよびSOAインフラストラクチャのペイロード検証レベルの設定に依存しません。ペイロード検証がサービス・エンジンとSOAインフラストラクチャの両レベルで有効な場合、データは2回チェックされます。1回目は、データがSOAインフラストラクチャに入るとき、2回目は、データがサービス・エンジンに入るときです。

注意: XMLペイロード検証を有効にすると、パフォーマンスに影響が出る可能性があります。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

デフォルト値はFalseです。

13.2.8 SyncMaxWaitTime

SyncMaxWaitTimeプロパティには、プロセス結果レシーバが戻るまでに結果を待つ最大時間を設定します。非同期BPELプロセスからの結果は、Oracle BPEL Serverからの結果を待つレシーバによって同期的に取得されます。

デフォルト値は45秒です。

13.2.9 InstanceKeyBlockSize

InstanceKeyBlockSizeプロパティは、インスタンスIDの範囲サイズを制御します。Oracle BPEL Serverは、指定された値を使用して、インスタンス・キー(プロセス・インスタンスIDの範囲)をバッチ形式で作成します。このメモリー内IDの範囲が作成されると、次の範囲が更新されて、ci_id_range表に保存されます。

たとえば、instanceKeyBlockSizeが100に設定されている場合、Oracle BPEL Serverはメモリー内にインスタンス・キーの範囲(100個のキー。これは後でcube_instance表にcikeyとして挿入される)を作成します。最適なパフォーマンスを確保するには、ブロック・サイズがci_id_range表に対する更新の数より大きくなるようにします。

デフォルト値は10000です。

13.2.10 MaxRecoverAttempt

リカバリ可能な同じインスタンス内で発行する自動リカバリ試行の数を構成できます。入力した値によって、起動メッセージおよびコールバック・メッセージがリカバリされる最大回数が指定されます。1つのメッセージに対するリカバリ試行の数が、指定された値を超過すると、そのメッセージにはリカバリ不能のマークが付けられます。

BPELインスタンスがinvokeMessageを使用して別のサーバーへのコールを作成し、サーバー停止、検証エラーまたはセキュリティ例外のためにそのコールが失敗すると、invokeMessageはリカバリ・キューに入れられ、BPELはそれらのメッセージを再試行しようとします。大量のメッセージがあり、大部分が同じターゲットに送信されている場合、そのターゲットはオーバーロードになる可能性があります。MaxRecoveryAttemptの適切な値を設定して、BPEL Webサービス・コールからターゲットのサーバーに対する過剰な負荷を防ぎます。

13.3 コンポジット内で設定するBPELプロパティ

この項では、デプロイメント・ディスクリプタの一部のセクションの構成プロパティを示します。各構成プロパティ・パラメータ、および各パラメータを変更した場合に予想されるエンジンの動作について説明します。

この項で設定するプロパティはすべて、BPELプロセスを含むコンポーネントの動作にのみ影響を与えます。各BPELプロセスは、コンポジットのコンポーネントとして作成できます。これらのプロパティは、composite.xmlまたはOracle Enterprise Manager Fusion Middleware ControlのシステムMBeanブラウザで変更できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。

13.3.1 コンポーネント・プロパティ

次のコンポーネント・プロパティをチューニングすることでパフォーマンスを改善できます。

13.3.1.1 inMemoryOptimization

このプロパティは、処理対象のプロセスが一時プロセスであり、インスタンスのデハイドレーションが必要ないことをOracle BPEL Serverに示します。Trueに設定すると、completionPersistPolicyを使用して永続性動作が判断されます。このプロパティをTrueに設定できるのは、一時プロセス、またはreceive、wait、onMessage、onAlarmなどのアクティビティのようにデハイドレーション・ポイントを含まないプロセスに対してのみです。inMemoryOptimizationプロパティは、BPELコンポーネント・レベルで設定します。Falseに設定すると、デハイドレーションが無効になり、一部のユースケースのパフォーマンスを向上できます。

値:

このプロパティは次の値を取ります。

- False(デフォルト): インスタンスは完全に永続化され、デハイドレーション・ストア・データベースに記録されます。

- True: completionPersistPolicyを使用して永続性動作が判断されます。13.3.1.2項を参照してください。

13.3.1.2 completionPersistPolicy

このプロパティでは、インスタンス・データの保存方法を構成します。BPELコンポーネント・レベルでのみ設定できます。completionPersistPolicyプロパティを使用できるのは、inMemoryOptimizationがTrue(一時プロセス)に設定されている場合のみです。このパラメータは、データベースの増大およびスループットに影響を与える可能性があります(I/Oが減少するため)。

値

説明

On(デフォルト)

完了したインスタンスは通常どおり保存されます。

遅延

完了したインスタンスは、異なるスレッドで、別のトランザクション内に保存されます。

フォルト

失敗したインスタンスのみが保存されます。

注意: 未処理フォルトが発生すると、これらのフラグにかかわらず、インスタンスの監査情報はcube_instance表内で維持されます。

オフ

このプロセスのインスタンスは保存されません。

13.3.1.3 auditLevel

BPELプロセス・サービス・コンポーネントに監査レベルを設定できます。この設定は、SOAインフラストラクチャ、サービス・エンジンおよびSOAコンポジット・アプリケーション・レベルでの監査レベルより優先されます。

次の例に示すように、bpel.config.auditLevelプロパティに、SOAプロジェクトのcomposite.xmlファイルでの該当する値を設定します。

<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

値

説明

継承

インフラストラクチャ・レベルから監査レベルを継承します。

オフ

監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。

最小

すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。

エラー

管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。

本番

すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。

開発

すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。

13.3.2 パートナ・リンク・プロパティ

パートナ・リンクは、実行時にBPELで動的に構成できます。これは、BPELによって呼び出されるターゲット・サービスが実行時まで不明な場合に便利です。次のパートナ・リンク・プロパティをチューニングすることでパフォーマンスを改善できます。

13.3.2.1 idempotent

idempotentアクティビティとは、再試行可能なアクティビティ(assignアクティビティやinvokeアクティビティなど)です。Oracle BPEL Serverは、非idempotentアクティビティの後にインスタンスを保存します。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

値:

このプロパティは次の値を取ります。

- False: アクティビティは実行直後にデハイドレーションされ、デハイドレーション・ストアに記録されます。idempotentをFalseに設定すると、フェイルオーバーによる保護は強化されますが、BPELプロセスがデハイドレーション・ストアに頻繁にアクセスする場合はパフォーマンスに影響が出ることがあります。

- True(デフォルト): Oracle BPEL Serverに障害が発生した場合、再起動後にアクティビティが再度実行されます。これは、アクティビティの呼出し直後にサーバーがデハイドレーションされず、アクティビティの実行が記録されていないためです。このプロパティをTrueに設定できる例としては、読取り専用サービス(CreditRatingServiceなど)や、インスタンスのトランザクションを共有するローカルのEJB/WSIF呼出しなどがあります。

13.3.2.2 nonBlockingInvoke

デフォルトでは、Oracle BPEL Process Managerはブランチをパラレルではなく順番に実行することによって、単一のスレッドで処理を実行します。このプロパティをTrueに設定すると、各ブランチのinvokeアクティビティをパラレルに実行するための新しいスレッドが作成されます。このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

複数のflowブランチやflow nブランチにinvokeアクティビティが存在する場合は、このパラメータをTrueに設定することを検討してください。これは、パラレルのinvokeアクティビティが双方向の際には特に有効ですが、パラレルの一方向呼出しに対しても効果的な場合があります。

注意:

同じパートナ・リンクへの呼出しは、パラレルではなく順番に発生します。nonBlockingInvokeをTrueに設定して、毎回異なるパートナ・リンクを呼び出すと、すべてのパートナ・リンクが同じソースを指し示している場合でも、各リンクはパラレルで機能します。

値:

- True: Oracle BPEL Serverは、呼出しを実行するための新しいスレッドを生成します。

- False(デフォルト): Oracle BPEL Serverは、単一のプロセス・スレッドでinvokeアクティビティを実行します。

13.3.2.3 validateXML

メッセージ境界の検証を有効にします。検証を追加すると、CPUおよびメモリーのリソースが余分に消費されて、パフォーマンスに影響を与えることがありますので注意してください。

値:

- True: Trueに設定すると、このパートナ・リンクの<receive>および<invoke>中に、XMLメッセージがXMLスキーマに対して検証されます。XMLメッセージが無効な場合は、bpelx:invalidVariablesランタイムBPELフォルトがスローされます。これは、ドメイン・レベルのvalidateXMLプロパティに優先します。

- False(デフォルト): XML検証が無効になります。

13.4 インスタンス・データ増大の影響を受ける表

インスタンス・データは、Oracle BPEL Process Managerのスキーマ表の領域を占有します。監査やデハイドレーションによってデータが増大すると、データベースのパフォーマンスおよびスループットに大きな影響を与える可能性があります。監査構成は、13.2.2項「監査」を参照してください。また、デハイドレーション構成は、13.3.1.1項「inMemoryOptimization」を参照してください。次の表は、インスタンス・データ増大の影響を受ける表をまとめたものです。各表について簡単に説明しています。

表13-1 インスタンス・データ増大の影響を受ける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

ヘッダーおよびプロパティの情報を格納します。

14 Oracle Mediatorのパフォーマンス・チューニング

この章では、Oracle Mediatorをチューニングして最適なパフォーマンスを得る方法について説明します。内容は次のとおりです。

- 14.1項「Oracle Mediatorについて」

- 14.2項「チューニングに関する基本的な考慮事項」

- 14.3項「イベント配信ネットワーク(EDN)のチューニング」

14.1 Oracle Mediatorについて

Mediatorは、Oracle SOAのコンポーネントです。選択的ルーティング、トランスフォーメーション、検証などの仲介機能を備え、同期、非同期、イベントのパブリッシュ、イベントのサブスクリプションといった様々なメッセージ交換パターンに対応しています。Oracle Mediatorは、サービスおよびイベントの各種プロバイダとコンシューマを仲介するフレームワークを提供します。メディエータ・サービス・エンジンは、SOAサービス・インフラストラクチャのJava EEアプリケーションと連携して動作します。

関連項目:

SOA Suiteの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

Oracle Mediatorの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者』の「Oracle Mediatorのサービス・コンポーネントとエンジンの管理」を参照してください。

14.2 チューニングに関する基本的な考慮事項

ほとんどのビジネス環境では、顧客データは、取引先、レガシー・アプリケーション、エンタープライズ・アプリケーション、データベース、カスタム・アプリケーションなど、様々なソースに点在しています。こうしたデータを効率的に統合するという課題は、Oracle Mediatorを使用することで解決できます。Oracle Mediatorは、同じデータの更新やその他の処理を共通して行うすべてのアプリケーションに対して、リアルタイムのデータ・アクセスを実現します。

注意:

Oracle Mediatorプロパティのチューニングを始める前に、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のOracle Mediatorに関する章を必ず読み、内容を理解しておいてください。

この項では、よく使用される次のOracle Mediatorプロパティの設定について詳しく説明します。

- metricsLevel

- ドメイン値マップ

- 遅延ルーティング・ルール

- エラー・パラメータおよび再試行パラメータ

- 監査レベル

- 再シーケンサ

14.2.1 metricsLevel

このプロパティは、DMSメトリックの追跡レベルを制御します。デフォルトでは、DMSメトリックの収集は有効になっています。DMAメトリック・データを収集する必要がない場合は、metricsLevelをDisabledに設定してパフォーマンスを改善することを検討してください。

14.2.2 ドメイン値マップ

パフォーマンスが問題になっている場合は、XSLトランスフォーメーション内でデータベース参照のかわりにドメイン値マップを使用し、ファイルI/Oを最小限に抑えることを検討してください。

ドメイン値マップの使用の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のドメイン値マップの使用に関する項を参照してください。

14.2.3 遅延ルーティング・ルール

次のパフォーマンス構成パラメータは、パラレル・ルーティング・ルールを指定したコンポーネントのチューニングに使用できます。

- DeferredWorkerThreadCount: メッセージをパラレルに処理する遅延ディスパッチャの数を指定します。負荷が高い場合は、このパラメータの値を大きくして、DeferredWorkerThreadsの1つによって各パラレル・ルールが処理されるときに遅延処理を行うアウトバウンド・スレッドの数を増やすことを検討してください。デフォルト値は4スレッドです。

- DeferredMaxRowsRetrieved: メディエータ・ルーティング・ルールのタイプが「パラレル」に設定されている場合、DeferredMaxRowsRetrievedには、メディエータ・ストア表(処理の対象となるパラレル・ルーティング・ルールのメッセージが格納される)から取得する最大行数(パラレル・ルーティング・ルールを処理するための最大メッセージ数)を設定します。このバッチで取得される各メッセージは、一度に1つのワーカー・スレッドによって処理されることに注意してください。デフォルト値は200行です。

- DeferredLockerThreadSleep: パラレル・ルーティング・ルールを処理するため、Oracle Mediatorには、メディエータ・ストア・データベースからメッセージを取得してロックするデーモン・ロッカー・スレッドが用意されています。このスレッドは、データベースに対してポーリングを行い、パラレル処理のメッセージを取得します。メッセージがない場合、ロッカー・スレッドはDeferredLockerThreadSleepに指定された時間だけスリープし、データベースへのラウンドトリップを防止します。デフォルト値は2秒です。パフォーマンスを改善するには、この値を大きくすることを検討してください。一部のユースケース・シナリオでは、3600秒(60分)の「スリープ」を利用できます。
指定した時間の間は、次のいずれの場合もパラレル・ルーティングのメッセージを取得できません。

- パラレル・ルーティング・ルールを指定したMediatorコンポーネントがデプロイされていない場合。

- パラレル・ルーティング・ルールを指定したMediatorコンポーネントがデプロイされているが、それらのコンポーネントに対して連続的な受信メッセージが存在しない場合。

注意:

Oracle Mediatorコンポーネントの優先度をJDeveloper Mediatorデザイナで指定できます。このプロパティを使用して、パラレル・ルーティング・ルールを指定した複数のOracle Mediatorコンポーネント間の優先度を設定します。

詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のメディエータ・ルーティング・ルールの作成に関する項を参照してください。

14.2.4 エラー・パラメータおよび再試行パラメータ

データベースへのラウンドトリップの回数を減らさないためには、ErrorLockerThreadSleepパラメータの値を大きくすることを検討してください。

ErrorLockerThreadSleepパラメータは、パラレル処理でエラーになったメッセージがない場合に、エラーになったメッセージを次に取得するまでのアイドル時間を指定します。時間の単位は秒です。デフォルト値は5秒です。パフォーマンスを改善するには、この値を大きくすることを検討してください。一部のユースケース・シナリオでは、3600秒(60分)のアイドル時間を利用できます。

ルーティングの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のメディエータ・ルーティング・ルールの作成に関する項を参照してください。

14.2.5 監査レベル

auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、すべてのメディエータ・コンポーネントに適用されます。このプロパティが制御するのは、メディエータ・コンポーネントによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_trail表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからメディエータ・コンポーネントの状態を確認する目的でのみ使用されます。

監査情報を保存しない場合は、Off値を使用します。この値を使用すると、一部のユースケースのパフォーマンスを改善できます。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。監査レベルの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の監査レベル設定の優先順位の概要に関する項を参照してください。

値

説明

継承

インフラストラクチャ・レベルから監査レベルを継承します。

オフ

監査イベント(フロー実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。

本番

すべてのイベントがログに記録されます。監査イベントごとにペイロードの詳細は保持されません。

開発

すべての監査イベントがログに記録されます。監査イベントごとにペイロードの詳細も保持されます。

14.2.6 再シーケンサ

リシーケンサは、関連性はあるが順序が正しくないメッセージのストリームを再配置して順序どおりに戻すために使用します。ランダムな順序で到着した受信メッセージを順序付けしてから、ターゲット・サービスに正しい順序で送信します。

リシーケンサの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』のメッセージのリシーケンスに関する項を参照してください。

「メディエータ・サービス・エンジン・プロパティ」ページの次のプロパティの値を設定して、再シーケンサを微調整できます。

- ResequencerWorkerThreadCount: ワーカー・スレッド数を指定します。デフォルトは4です。

- ResequencerMaxGroupsLocked: 繰返しごとにロックされるグループの最大数を指定します。デフォルトは4です。

- ResequencerLockerThreadSleep: ロッカー・スレッドの秒単位のスリープ間隔を指定します。デフォルトは10です。

14.3 イベント配信ネットワーク(EDN)のチューニング

イベント配信ネットワーク(EDN)は、Oracle Mediator、Oracle BPEL Process Managerコンポーネント、およびOracle Application Development Frameworkエンティティ・オブジェクトなどの外部パブリッシャによってパブリッシュされたイベントを配信します。

イベント配信ネットワークのパフォーマンスを改善するには、スレッド数(デフォルトは3)を増やすことを検討してください。このプロパティは、WLSTを使用して変更できます。詳細は、11.3項「SOA構成パラメータの変更」を参照してください。

15 Oracle Business Process Managementのパフォーマンス・チューニング

Oracle Business Process Management(BPM) Suiteでは、設計時および実装からランタイムおよびアプリケーション管理まで、アプリケーション開発ライフサイクルの全ステージをシームレスに統合します。

この章の内容は次のとおりです。

- 15.1項「Oracle Business Process Managementについて」

- 15.2項「チューニングに関する基本的な考慮事項」

- 15.3項「Oracleワークスペースおよびワークリスト・アプリケーションのチューニング」

- 15.4項「Process Analyticsのチューニング」

15.1 Oracle Business Process Managementについて

Oracle BPM Suiteは、ビジネス・プロセスを中心にしたビジネス・アプリケーションを開発、管理および使用するための統合環境を提供します。BPMは、Oracle SOA Suite上に存在し、統合の実現にBusiness Rules、Human WorkflowおよびOracle Adapter Frameworkを含む多くの同じ製品コンポーネントを共有します。

BPMの使用の詳細は、『Oracle Fusion Middleware Oracle Business Process Managementユーザーズ・ガイド』を参照してください。

他のOracle Fusion MiddlewareコンポーネントによるOracle BPMのチューニングの詳細は、第2章「主なパフォーマンス分野」を参照してください。

15.2 チューニングに関する基本的な考慮事項

この項では、次の基本的なBPMパフォーマンス・チューニング・プロパティについて説明します。

- 監査レベル

- LargeDocumentThreshold

- ディスパッチャ・システム・スレッド

- ディスパッチャ・エンジン・スレッド

- ディスパッチャ呼出しスレッド

注意:

この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

15.2.1 監査レベル

auditLevelプロパティには、監査証跡のロギング・レベルを設定します。この構成プロパティは、永続プロセスと一時プロセスの両方に適用されます。このプロパティが制御するのは、プロセスによってログに記録される監査イベントの量です。監査イベントを記録すると、audit_trail表へのデータベース挿入が増えるため、パフォーマンスに影響が出ることがあります。監査情報は、Oracle Enterprise Managerコンソールからプロセスの状態を確認する目的でのみ使用されます。

監査情報を保存しない場合は、Off値を使用します。監査レベルは、常にビジネス要件およびユースケースに従って選択してください。監査レベルの設定の詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の監査レベル設定の優先順位の概要に関する項を参照してください。

値

説明

継承

インフラストラクチャ・レベルから監査レベルを継承します。

オフ

監査イベント(アクティビティ実行情報)は保持されず、ロギングは実行されません。この場合、インスタンス処理のパフォーマンスがわずかに向上する可能性があります。

最小

すべてのイベントがログに記録されます。ただし、監査詳細(変数の内容)は記録されません。

エラー

管理者がただちに対処する必要があり、製品のバグ以外が原因の重大な問題のみログに記録します。このレベルを使用すると、パフォーマンスを向上できます。

本番

すべてのイベントがログに記録されます。assignアクティビティの監査詳細は記録されませんが、それ以外のすべてのアクティビティの詳細が記録されます。

開発

すべてのイベント、およびすべてのアクティビティのすべての監査詳細がログに記録されます。

15.2.2 LargeDocumentThreshold

largedocumentthresholdプロパティには、大きなXMLドキュメントの永続性しきい値を設定します。これは、BPMNデータ・オブジェクトの最大サイズ(KB)です。これを超えると、BPMNデータ・オブジェクトが他のインスタンス・スコープ・データとは異なる場所に格納されるようになります。

このプロパティは、永続プロセスと一時プロセスの両方に適用されます。

インスタンス処理を行う必要が生じるたびに、大きなXMLドキュメントの読込みおよび書出しが絶えず行われる場合は、Oracle BPMランタイム全体のパフォーマンスに影響が出ます。

デフォルト値は10000(100KB)です。

15.2.3 ディスパッチャ・システム・スレッド

dspSystemThreadsプロパティには、システム・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。システム・ディスパッチャ・メッセージとは、通常はサーバーで迅速に処理される一般的なクリーン・アップ・タスク(ステートフル・メッセージBeanを元のプールへ解放するなど)です。一般に、実行時に生成される数のシステム・ディスパッチャ・メッセージは、ごく少数のスレッドで処理できます。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は2です。1スレッド未満の値は、デフォルト値に変更されます。

15.2.4 ディスパッチャ・エンジン・スレッド

dspEngineThreadsプロパティには、エンジン・ディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。エンジン・ディスパッチャ・メッセージは、アクティビティを非同期に処理する必要がある場合に必ず生成されます。デプロイされたプロセスの大部分が永続的で、多数のデハイドレーション・ポイント(プロセス途中のreceive、onMessage、onAlarmおよびwaitアクティビティ)がある場合は、エンジン・スレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もありますので注意してください。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は30スレッドです。1スレッド未満の値は、デフォルト値に変更されます。

15.2.5 ディスパッチャ呼出しスレッド

dspInvokeThreadsプロパティには、呼出しディスパッチャ・メッセージの処理に割り当てるスレッドの総数を指定します。呼出しディスパッチ・メッセージは、受信したペイロードごとに生成されるもので、新規インスタンスのインスタンス化を目的としています。エンジンによって処理されるリクエストの大部分が(インスタンス・コールバックではなく)インスタンス呼出しである場合は、呼出しスレッド数を増やすことでパフォーマンスを改善できる可能性があります。スレッド数が多くなると、コンテキスト切替えのコストが高くなるため、CPU使用率が増加する場合もあります。

このスレッド・プールの最小スレッド数は1です。0や負の数に設定することはできません。

デフォルト値は20スレッドです。1スレッド未満の値は、デフォルト値に変更されます。

15.3 Oracleワークスペースおよびワークリスト・アプリケーションのチューニング

次の設定を使用して、Oracleワークスペースおよびワークリスト・アプリケーションをチューニングできます。

パラメータ

説明

HTTPセッション・タイムアウト

リソースの使用状況を管理するには、web.xmlファイルでセッション・タイムアウト値(分)を調整します。

次に示すのは、web.xmlのサンプル・スニペットです。

<session-config>
<session-timeout>
5
</session-timeout>
</session-config>

注意: デプロイメント後にこのプロパティを変更する必要がある場合、web.xmlを手動で編集してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のweb.xmlプロパティの編集に関する項を参照してください。

ADFクライアント状態トークン

この設定では、ユーザーが情報を失わずにブラウザの「戻る」ボタンで移動可能なページの数を制御できます。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>

注意: デプロイメント後にこのプロパティを変更する必要がある場合、web.xmlを手動で編集してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のweb.xmlプロパティの編集に関する項を参照してください。

Compress_View_Stateトークン

この設定は、ページ状態を圧縮するかどうかを制御します。圧縮により、セッション・オブジェクトのページ状態で使用されるメモリーを大幅に削減しました。

次に示すのは、web.xmlのスニペットです。

<param-name>org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE</param-name>
<param-value>true</param-value>

DISABLE_CONTENT_COMPRESSION

デフォルトでは、レンダリングされたスタイル・クラスは、ページ・サイズを小さくするために圧縮されます。本番環境では、必ずDISABLE_CONTENT_COMPRESSIONパラメータをweb.xmlファイルから削除するか、FALSEに設定してください。

次に示すのは、web.xmlのスニペットです。

<param-name>org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION</param-name> <param-value>false</param-value>

15.4 Process Analyticsのチューニング

Process Analyticsのチューニングの内容は、次のとおりです。

15.4.1 プロセス測定

Process Analyticsは測定イベントを使用して、プロセスをサンプリングし、登録されたコンシューマに測定を公開します。BPMN構成の「センサーの無効化」を使用して、これらの測定を無効にできます。BPMN構成の「アクションの無効化」を使用して、これらの測定の特定のコンシューマを無効にできます。詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

注意:

有益なデータのみが公開されます。プロセス設計では、どのデータ(ディメンション、メジャー、カウンタ)をどの時点で公開するかを指定します。有益でないデータが生成される場合、不要な負荷がシステムに加わっている可能性があります。

測定イベントは、JMSトピックのMeasurementTopicで公開され、登録されたアクションMDBで消費されます。測定するためにJMSをチューニングするには、大規模な環境で必要に応じて次の値を変更することを検討してください。

- MeasurementTopic
最大バイト数 800MB

最大メッセージ 1000000

- MeasurementTopicConnectionFactory
送信タイムアウト 240000

- BPMJMSServer
MessageBufferサイズ 100000

BPMJMSServerは、ページング・ファイルおよびJMSファイル・ストアを使用します。

15.4.2 プロセス・キューブのチューニング

プロセス・キューブは、ワークロード情報を計算する定期的な集計を実行します。これらの計算の頻度は、BPMNConfig MBeanのCubeUpdateFrequencyパラメータで決定され、Oracle Enterprise Managerコンソールから変更できます。大規模な環境では、リソースの計算を保存する場合などにこのパラメータを適切な12時間などの高い値に変更することを検討してください。

注意:

ワークロード・スナップショットの作成は、パフォーマンスに影響を与える可能性があります。Oracle Fusion Middleaware Controlのプロパティを使用して、ワークロード・スナップショットの頻度および存続時間(TTL)をチューニングすることを検討してください。Fusion Middleware Contolの使用方法の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

プロセス・キューブ・アグリゲータは、BPM_CUBE_AUDITINSTANCE表を使用して、ワークロードおよびパフォーマンス情報を計算します。BPM_CUBE_AUDITINSTANCE表の不要なレコードは、SOAパージ・スクリプトの一部としてパージされます。また、プロセス・キューブの計算のパフォーマンスを改善するには、次の削除スクリプトを定期的に実行してBPM_CUBE_AUDITINSTANCE表の不要なレコードをパージすることを検討してください。

DELETE FROM BPM_CUBE_AUDITINSTANCE A
WHERE EXISTS
(SELECT 1 FROM BPM_CUBE_AUDITINSTANCE B
WHERE A.COMPONENTINSTANCEID = B.COMPONENTINSTANCEID AND
B.OPERATION='INSTANCE_CREATED' AND
B.ACTIVITYSTATUS='PROCESSED')

16 Oracle Human Workflowのパフォーマンス・チューニング

この章では、Oracle Human Workflowをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle Human Workflowは、次の分野のチューニングが可能です。

- 16.1項「Oracle Human Workflowについて」

- 16.2項「チューニングに関する基本的な考慮事項」

- 16.3項「サーバーのパフォーマンスの向上」

- 16.4項「ワークフロー完了の迅速化」

- 16.5項「アイデンティティ・プロバイダのチューニング」

- 16.6項「データベースのチューニング」

16.1 Oracle Human Workflowについて

Oracle Human Workflowは、Oracle SOAサービス・インフラストラクチャ内で稼働するサービス・エンジンです。これを使用すると、対話型の人的プロセスを実行できます。ヒューマン・ワークフローは、プロセスの内部または外部で行われる承認処理、却下処理、再割当て処理といった人間のやり取りに対応しています。Human Workflowサービスは、ビジネス・プロセスと人間とのやり取りの様々な側面を処理する多くのサービスからなります。

詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のヒューマン・ワークフロー・サービス・コンポーネントの使用に関する項を参照してください。

Oracle Human WorkflowのWebサイト(http://www.oracle.com/technology/products/soa/hw/index.html)も参照してください。

16.2 チューニングに関する基本的な考慮事項

この項では、パフォーマンスの問題に対応するための様々な方法について説明します。

- クライアント側のレスポンス時間の最小化

- 適切なワークフロー・サービス・クライアントの選択

- 厳密なフィルタを使用した該当タスクの絞込み

- 該当タスクのサブセットの取得(ページング)

- 該当タスクに必要な情報のみのフェッチ

- 返される問合せ列の数の削減

- 集計APIを使用したタスク統計のチャート化

- カウントAPIメソッドを使用したタスク数のカウント

- フレックスフィールドの索引のオンデマンド作成

- doesTaskExistメソッドの使用

16.2.1 クライアント側のレスポンス時間の最小化

ワークフロー・クライアント・アプリケーションが対話型の場合、クライアント側の最適なレスポンス時間を維持することが重要です。レスポンス時間に影響を与える要素としては、サービス・コールのパフォーマンスの影響、リクエストに該当するタスク・セットを特定するための問合せ時間、該当タスクごとに取得される追加情報の量などがあります。

16.2.2 適切なワークフロー・サービス・クライアントの選択

ワークフロー・サービスは、主にSOAPクライアントとEJBクライアントの2種類のクライアントをサポートしています。EJBクライアントは、さらにローカルEJBクライアントとリモートEJBクライアントに分けられます。

クライアント・アプリケーションが.Netテクノロジをベースとしている場合は、SOAPワークフロー・サービスしか使用できません。一方、クライアント・アプリケーションがJava EEテクノロジをベースとしている場合は、ユースケース・シナリオを基に、使用するクライアントを検討してください。選択肢を次に示します。

- リモート・クライアント: ほとんどの場合、パフォーマンスの点ではこれが最善の選択肢です。クライアントがワークフロー・サービスと同じJVMで稼働している場合(soa-infraアプリケーション)、APIコールはリモート・メソッド呼出し(RMI)の必要がないように最適化されます。クライアントが別のJVMに存在する場合は、RMIが使用されます。このとき、APIメソッド間でデータのシリアライズおよびデシリアライズが行われるため、パフォーマンスに影響が出ることがあります。

- SOAPクライアント: Webサービスに基づいた標準化を行うにはこの選択肢のほうが望ましいのですが、リモート・クライアントでリモート・メソッド呼出し(RMI)を使用する場合と比べて、パフォーマンス面の考慮事項が増えます。Webサービス・テクノロジによって追加の処理が行われるため、XML間でAPIメソッド引数の整列化および非整列化が発生します。

詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

16.2.3 厳密なフィルタを使用した該当タスクの絞込み

厳密なフィルタを使用することは、レスポンス時間を短縮するうえで最も重要な要素の1つです。タスク・リストを取得する際に、データベース・レベルで最大限のフィルタ処理を行えるよう、問合せをできるだけ厳密なものにする必要があります。

たとえば、ユーザーの受信ボックス表示がリクエストされた場合、タスクは主に、現在のユーザーまたはユーザーの属するグループに割り当てられているかどうかを基準にフィルタ処理されます。受信ボックス表示に述語フィルタを追加指定すれば、該当するタスクの数が減るため、問合せの総レスポンス時間を短縮できます。

あるいは、述語フィルタを指定してビューを定義することもできます。こうすれば、該当するタスクの数が減るため、ビューの総レスポンス時間は短くなります。問合せAPIに渡される述語(またはビューで定義された述語)はすべて、データベース・レベルのSQL問合せに直接プッシュされます。この情報を基に、データベース・オプティマイザが最善の索引を使用して最適な実行計画を作成します。追加するフィルタは、タスクの属性に基づくものでも、プロモートされたフレックスフィールドに基づくものでもかまいません。たとえば、発注承認タスクをすべてリストするかわりに、優先度、日付、カテゴリ、金額範囲のいずれかに基づいてユーザーにタスクを提示するようビューを定義できます。

例: 優先度=1のユーザーに割り当てられたタスクをすべて取得するには、次のAPIコールを使用します。

Predicate pred = new Predicate(TableConstants.WFTASK_STATE_COLUMN,
Predicate.OP_EQ,
IWorkflowConstants.TASK_STATE_ASSIGNED);
pred.addClause(Predicate.AND,
TableConstants.WFTASK_PRIORITY_COLUMN,
Predicate.OP_EQ,

1);
List tasks = querySvc.queryTasks(ctx,
queryColumns,
null,
ITaskQueryService.AssignmentFilter.MY ITaskQueryService.AssignmentFilter.MY,
null,
pred,
null,
startRow,
endRow);

16.2.4 該当タスクのサブセットの取得(ページング)

前の項で説明したように、特定の条件に合せてタスク・リストを絞り込んだら、今度はユーザーに提示するタスクの数を基準に、次のレベルのフィルタ処理を行います。必要以上に多くの行をフェッチするのは避ける必要があります。フェッチされる行が多すぎると、問合せに時間がかかるだけでなく、アプリケーションの処理時間が長くなり、クライアントに返されるデータの量も増えるためです。問合せAPIには、ユーザーに返される該当行の数および開始行を制御するページング・パラメータが用意されています。

たとえば、次のようなqueryTasksメソッドがあるとします。

List tasks = querySvc.queryTasks(ctx,
queryColumns,
null,
ITaskQueryService.AssignmentFilter.MY,
null,
pred,
null,
startRow,
endRow);

startRowパラメータおよびendRowパラメータを、返される一致レコードの数を制限するような値に設定することを検討してください。

16.2.5 該当タスクに必要な情報のみのフェッチ

queryTaskサービスを使用する際は、リスト内のタスクごとに取得するオプション情報の量を減らすことを検討してください。そうすることで、追加のSQL問合せやJavaロジックがパフォーマンスに与える影響を軽減できます。

たとえば、次のqueryTasksメソッドでは、グループ・アクションの情報のみが取得されます。添付ファイルおよびペイロードの情報を直接リストに取得することもできますが、パフォーマンスに影響が出る可能性があります。

List<ITaskQueryService.OptionalInfo> optionalInfo
= new ArrayList<ITaskQueryService.OptionalInfo>();
optionalInfo.add(ITaskQueryService.OptionalInfo.GROUP_ACTIONS);
// optionalInfo.add(ITaskQueryService.OptionalInfo.ATTACHMENTS);
// optionalInfo.add(ITaskQueryService.OptionalInfo.PAYLOAD);
List tasks = querySvc.queryTasks(ctx,
queryColumns,
optionalInfo,
ITaskQueryService.AssignmentFilter.MY,
null,
pred,
null,
startRow,
endRow);

まれに、ペイロード全体が必要になることもありますが、その場合はペイロード情報をリクエストできます。通常は、タスク・リストを表示するためにペイロード・フィールドの一部が必要になるだけです。たとえば、発注関連のタスクで、発注額の列を表示する必要があるとします。ペイロードを追加情報としてフェッチしてから、xpath式を使用して金額を取得し、リストに表示するかわりに、金額の列をペイロードからフレックスフィールドにマップすることを検討してください。そうすれば、SQL問合せの中でフレックスフィールドを直接取得でき、処理時間が大幅に短縮されます。

同様に、添付ファイルの名前がリストに表示され、ドキュメント自体は外部リポジトリに格納されるようなケースでは、ペイロード内の添付ファイル名を取得してフレックスフィールドにマップすることを検討してください。そうすることで、処理時間が最適化されます。リスト情報を構成する際には、該当するフレックスフィールドをフェッチすれば、添付ファイルへのリンクを構成できます。

16.2.6 返される問合せ列の数の削減

queryTaskサービスを使用する際は、問合せ列の数を減らして、SQLの実行時間を短縮することを検討してください。また、一般的な列を使用するよう努めてください。一般的な列は索引が作成される可能性が高く、SQLの実行時間の短縮につながるためです。

たとえば、次のqueryTasksメソッドでは、TASKNUMBER列およびTITLE列のみが返されます。

List queryColumns = new ArrayList();
queryColumns.add("TASKNUMBER");
queryColumns.add("TITLE");
...
List tasks = querySvc.queryTasks(ctx,
null,
ITaskQueryService.AssignmentFilter.MY,
null,
pred,
null,
startRow,
endRow);

16.2.7 集計APIを使用したタスク統計のチャート化

タスク情報を要約したチャートや統計を表示することが必要になる場合があります。問合せAPIを使用してすべてのタスクをフェッチし、クライアント・レイヤーで統計を計算するかわりに、新しい集計APIを使用して、データベース・レベルで統計を計算することを検討してください。

たとえば次のコールは、APIを使用して、ユーザーに割り当てられたタスクの状態を基に要約された統計を取得する方法を示しています。

List taskCounts = querySvc.queryAggregatedTasks(ctx,
Column.getColumn(WFTaskConstants.STATE_COLUMN),
ITaskQueryService.AssignmentFilter.MY,
keyWordFilter,
filterPredicate,
false,
false);

16.2.8 カウントAPIメソッドを使用したタスク数のカウント

特定の条件に一致するタスクの数をカウントするだけでよい場合があります。queryTasks APIメソッドをコールして返されたリストのサイズを調べるかわりに、countTasks APIメソッドをコールすれば、条件に一致するタスクの数のみが返されます。タスク数が返される場合のパフォーマンスへの影響は、タスク・オブジェクトのリストが返される場合よりはるかに小さくなります。

たとえば次のコールは、APIを使用して、ユーザーに割り当てられたタスクの総数を取得する方法を示しています。

int numberOfTasks = querySvc.countTasks(ctx,
ITaskQueryService.AssignmentFilter.MY,
keyWordFilter,
filterPredicate);

16.2.9 フレックスフィールドの索引のオンデマンド作成

ワークフロー・スキーマ表WFTASKには、フレックスフィールド属性列がいくつか含まれています。これらを使用すると、ワークフロー・スキーマにタスク・ペイロード値を格納できます。列の数が多く、列の使用はオプションであるため、インストール済のスキーマにはこれらの列の索引は含まれていません。特定のマップ済フレックスフィールド列が問合せの述語で頻繁に使用されるようなユースケースでは、これらの列に索引を作成するとパフォーマンスが向上します。

たとえば、TEXTATTRIBUTE1列に索引を作成するには、次のSQLコマンドを実行します。

create index WFTASKTEXTATTRIBUTE1_I on WFTASK(TEXTATTRIBUTE1);

注意:

必要になる索引そのものは、使用するフレックスフィールド属性列、および実行する問合せの性質によって異なります。索引を作成したら、WFTASK表の統計を再計算して、フラッシュする必要があります。

16.2.10 doesTaskExistメソッドの使用

特定の問合せ条件に一致するタスクが存在するかどうかを確認することが必要になる場合があります。countTasksメソッドをコールして、返された数がゼロかどうかを確認するかわりに、doesTaskExistを使用することを検討してください。doesTaskExistメソッドは、指定された条件に一致する行が存在するかどうかを確認するだけの、最適化された問合せを実行します。このメソッドを使用すれば、countTasksをコールする場合より優れた結果が得られる可能性があります。

たとえば次のコールは、APIメソッドを使用して、ユーザーがタスク・インスタンスを所有しているかどうかを特定する方法を示しています。

boolean userOwnsTask = querySvc.doesTaskExist(ctx, ITaskQueryService.AssignmentFilter.OWNER,null,null);

16.3 サーバーのパフォーマンスの向上

負荷の高い状況でのシステムのスケーラビリティは、サーバーのパフォーマンスによって事実上決まります。16.2.1項「クライアント側のレスポンス時間の最小化」では、適切な量の情報をフェッチすること、および問合せに伴うパフォーマンスへの影響を軽減することによって、クライアント側のレスポンス時間を最小化する手法をいくつか取り上げています。これらの手法には、データベースおよびサービス・ロジックがサーバー側のパフォーマンスに与える影響を軽減し、サーバーのパフォーマンスを改善する効果もあります。その他、次のような構成変更を行うとサーバーのパフォーマンスが向上します。

- 完了したインスタンスの定期的なアーカイブ

- 適切なワークフロー・コールバック機能の選択

- 通知がパフォーマンスに与える影響の最小化

- クラスタ・ノードのデプロイ

16.3.1 完了したインスタンスの定期的なアーカイブ

システムのデータベース・スケーラビリティは、システム内のデータ量によって大きく変わります。ビジネス・プロセスおよびワークフローは本来一時的なものであるため、処理が終われば、頻繁に問い合せられることはありません。完了したインスタンスがシステムに多数存在すると、システムの処理速度が低下する原因となります。アーカイブ手法を使用して、完了したインスタンスを別のシステムへ定期的に移動し、そこで履歴データの問合せに役立てることを検討してください。アーカイブを行う際には、孤立したタスク・インスタンスが発生しないよう注意する必要があります。

16.3.2 適切なワークフロー・コールバック機能の選択

ワークフロー・コールバック機能を使用すると、タスクの割当てや完了といった重要なワークフロー・イベントの後、外部システムに対して問合せや更新を行うことができます。この機能は非常に便利ですが、パフォーマンスに影響を与えないよう正しく実装する必要があります。

パフォーマンスの重要性が高い場合は、各ワークフロー・イベントの後ではなく、タスクの完了後に外部システムを更新するための十分なリソースがあることを確認してください。たとえば、コールバックを使用するかわりに、タスクの完了後にサービスを1回呼び出します。コールバックが避けられない場合は、BPELコールバックではなくJavaコールバックを使用することを検討してください。Javaコールバックでは、コールバック・メソッドが同じスレッド内で実行されるため、BPELコールバックで発生するようなパフォーマンスへの影響は生じません。これに対し、BPELコールバックは、BPELエンジンへメッセージを送信する際に、パフォーマンスに影響を与える可能性があります。そのため、メッセージが正しいプロセス・インスタンスへ配信されるように、メッセージの関連付けが必要になります。ワークフロー・サービスは、サービスの呼出し後にBPELエンジンによってコールする必要があります。

16.3.3 通知がパフォーマンスに与える影響の最小化

通知は、実行すべきタスクがあることをユーザーに知らせるのに便利です。ほとんどの承認が電子メール経由で行われる環境では、アクション可能な通知が特に有効です。この場合、ワークリストの使用状況の点ではそれほど負荷がかかっていないとも言えます。ただし、ほとんどのユーザーがワークリストを通じてやり取りし、通知には二次的な意味しかないという場合は、通知を慎重に使用する必要があります。ワークフロー・イベントごとに通知を送信するかわりに、タスクが割り当てられたことをユーザーに知らせる目的に絞って、通知を最小限に抑えることを検討してください。また、タスクの内容も通知に含めて送信すると、パフォーマンスに影響が出る可能性があります。影響を最小限に抑えるには、通知のセキュリティを確保し、タスクの内容そのものではなく、タスクへのリンクのみを通知に含めて送信することを検討してください。

16.3.4 クラスタ・ノードのデプロイ

ワークフロー・インスタンスおよび状態情報はすべて、デハイドレーション・データベースに格納されます。ワークフロー・サービスはステートレスです。つまり、ノードのクラスタ上で複数のワークフロー・サービスを同時に使用できます。パフォーマンスの重要性が高く、スケーラビリティに優れたシステムが必要な場合は、クラスタ環境を使用してワークフローをサポートすることが可能です。クラスタ・アーキテクチャの詳細は、29.2項「Oracle Fusion Middlewareでのクラスタの使用」を参照してください。

16.4 ワークフロー完了の迅速化

ワークフローの完了に要する時間は、ワークフローに指定されたルーティング・タイプによって異なります。ワークフロー機能には、ワークフローの完了に要する時間を短縮するための手段が用意されています。この項では、そうした手段の一部を説明します。

- ワークフロー・レポートを使用した進捗状況の監視

- エスカレーション・ルールの指定

- ユーザー・ルールおよびグループ・ルールを指定した自動割当て

- タスク・ビューを使用した作業の優先順位付け

16.4.1 ワークフロー・レポートを使用した進捗状況の監視

監視および予防的な問題解決を容易にするワークフロー・レポート(および対応するビュー)がいくつか用意されています。これらのレポートのごく一部を次に示します。

- 不参加タスク・レポート: まだユーザーが獲得して処理していないため、注意が必要なグループ・タスクのリストです。

- タスクのサイクル・タイム・レポート: 特定のタイプのワークフローが完了するまでの時間を把握できます。

- タスクの生産性レポート: 様々なユーザーのタスクのインフローおよびアウトフローを示します。

- 割当て先時間分布レポート: 各ユーザーがタスクのライフ・サイクルの中で費やした時間(タスクがユーザーによって獲得されるまで待機したアイドル時間を含む)を詳細にドリルダウンできます。

これらのレポートはすべて、問題を解決するうえで効果を発揮します。不参加タスク・レポートを確認して、長期間キューに入っているタスクを特定のユーザーに割り当てることができます。サイクル・タイム、その他の統計を監視して、負担の大きいグループや完了まで時間がかかるグループのスタッフを増員することができます。このように、レポートを効果的に使用すれば、ワークフローの完了を確実に迅速化できます。

16.4.2 エスカレーション・ルールの指定

タスクが特定のユーザーの下で止まってしまうことのないよう、エスカレーション・ルールを指定できます。たとえば、タスクが処理されずに一定の時間が経過した場合は、そのタスクをマネージャへ進めることができます。別のルーティング・ロジックに基づいて他のユーザーへタスクをエスカレートする必要がある場合は、カスタム・エスカレーション・ルールを組み込むことも可能です。適切なエスカレーション・ルールを指定することで、ワークフローの完了に要する時間を短縮できます。

16.4.3 ユーザー・ルールおよびグループ・ルールを指定した自動割当て

タスクを他のユーザーやグループの他のメンバーに手動で再割当てするかわりに、ユーザー・ルールおよびグループ・ルールを使用して自動再割当てを実行できます。こうすると、ワークフローにタイミングよくユーザーの注意を向けることができます。たとえば、特定のタイプのワークフローや特定のフィルタ条件に一致するワークフローを、指定した期間内に別のユーザーに自動的に再割当てするようなユーザー・ルールを設定します。同様に、グループ・ルールを使用すれば、異なるルーティング条件(ラウンド・ロビンや最も生産性の高い箇所など)に基づいて、ワークフローをグループのメンバーに自動的に再割当てすることができます。このように、ルールを使用することでワークフローの待ち時間が大幅に短縮され、ワークフロー完了の迅速化につながります。

16.4.4 タスク・ビューを使用した作業の優先順位付け

ユーザーの受信ボックスには、様々な期日が設定された様々なタイプのタスクが格納されます。ユーザーは、手動でタスクを選別したり並べ替えたりして、次に処理するタスクを決める必要があります。タスクが期日や優先度に基づいてフィルタ処理されるようなタスク・ビューを作成すれば、作業の優先順位付けが自動的に行われるため、処理するタスクを決めるのに無駄な時間を費やさずに済み、タスクの完了に専念できるようになります。これも、ワークフロー完了の迅速化につながります。

16.5 アイデンティティ・プロバイダのチューニング

ワークフロー・サービスでは、SQL問合せを構成する際、アイデンティティ・プロバイダの情報を使用して、ユーザーのロールやグループのメンバーシップを基にそのユーザーに該当するタスクを特定します。アイデンティティ・プロバイダに対しては、ロール情報を調べてユーザーがタスク詳細をフェッチする際の権限を特定したり、ユーザーがタスクに対して実行できるアクションを特定する目的でも、問合せが行われます。アイデンティティ・プロバイダへのリクエストを迅速化するには、いくつかの方法があります。

- アイデンティティ構成ファイル内の検索ベースをできるだけ細かくノードに設定します。理想的なのは、ワークフロー関連のグループを単一ノードに集めて、検索および参照のためのトラバースを最小限に抑えることです。これは常に可能であるとはかぎりません。たとえば、既存のグループを使用して、他のノードのグループにメンバーシップを付与する必要が生じる場合もあります。フィルタを指定して検索対象のノードを絞り込むことが可能であれば、アイデンティティ構成ファイルにフィルタを指定してください。

- アイデンティティ・プロバイダの重要な属性(dnやcnなど)のすべてに索引を作成します。そうすることで、検索や参照の際に、ツリー全体ではなくノードのサブセットのみがトラバースされるようになります。

- キャッシュをサポートするアイデンティティ・プロバイダを使用します。LDAPプロバイダの中にはキャッシュをサポートしないものもありますが、Oracle Internet Directoryはキャッシュをサポートしているため、参照および検索の問合せが高速化されます。

16.6 データベースのチューニング

Human Workflowスキーマでは、すべての表の最も重要な列にいくつかの索引があらかじめ定義されています。ユーザーのタスク・リストをフェッチするため、リクエストのタイプに応じて異なるSLQ問合せが生成されます。データベース・オプティマイザは、様々な計画(全表スキャン、索引による表アクセスなど)のコストを評価して、よりコストの低い計画を決定します。オプティマイザが正しく機能するよう、索引統計を常に最新の状態に維持してください。データベースの使用方法を問わず、最大限のパフォーマンスを得るには、データベース統計を定期的に更新し、その他のチューニング可能なパラメータ(メモリー、表領域、パーティションなど)を効果的に使用することが重要です。

データベースのチューニングの詳細は、2.6項「データベース・パラメータのチューニング」を参照してください。

17 Oracleアダプタのパフォーマンス・チューニング

この章では、Oracleアダプタをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle SOA SuiteアプリケーションのコンポーネントであるOracleアダプタは、データへの統一的な視点を提供し、複数のアプリケーションの統合を可能にします。

この章の内容は次のとおりです。

- 17.1項「Oracleアダプタについて」

- 17.2項「Oracle JCA Adapter for Files/FTP」

- 17.3項「Oracle JCA Adapter for Databaseのチューニング」

- 17.4項「Oracleソケット・アダプタのチューニング」

- 17.5項「Oracle SOA JMSアダプタのチューニング」

- 17.6項「Oracle AQアダプタのチューニング」

- 17.7項「Oracle MQアダプタのチューニング」

17.1 Oracleアダプタについて

Oracleテクノロジ・アダプタは、Oracle Application ServerおよびOracle Fusion Middlewareのコンポーネント(Oracle BPEL Process Manager(Oracle BPEL PM)やOracle Mediatorのコンポーネントなど)をファイルシステム、FTPサーバー、データベース・キュー(アドバンスト・キュー(AQ))、Java Message Services(JMS)、データベース表およびメッセージ・キュー(MQ Series)に統合します。

Oracleアダプタの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』を参照してください。

17.2 Oracle JCA Adapter for Files/FTP

この項では、Oracleファイル/FTPアダプタのスケーラビリティおよびパフォーマンスをチューニングする際に使用できる様々な機能について説明します。Oracleファイル/FTPアダプタには、インバウンド操作およびアウトバウンド操作を調整するためのパラメータが用意されています。また、アウトバウンド操作のパフォーマンス・チューニングに使用できるパラメータもあります。Oracleファイル/FTPアダプタのパラメータについては、次の項で説明します。

- インバウンド調整のベスト・プラクティス

- アウトバウンド調整のベスト・プラクティス

- アウトバウンド・パフォーマンスのベスト・プラクティス

注意:

Oracleファイル/FTPアダプタを使用するコンポジットが大量の同時メッセージを消費するよう設計されている場合は、オペレーティング・システムのオープン・ファイル数パラメータを大きな値に設定する必要があります。たとえば、Linuxのオープン・ファイル数パラメータを8192に設定するには、ulimit -n 8192コマンドを使用します。

17.2.1 インバウンド調整のベスト・プラクティス

Oracleファイル/FTPアダプタには、インバウンド操作の調整に使用できるパラメータが用意されています。次の表で、インバウンド調整の方法について説明します。

パラメータ

タイプ

値

説明

MaxRaiseSize

JCA

<property name="MaxRaiseSize" value="100"/>

デフォルト: 10000

このパラメータでは、インバウンド・アダプタが各ポーリング・サイクルで処理のために発行するファイルの最大数を定義します。たとえば、インバウンド・ディレクトリに1000個のファイルがあり、MaxRaiseSizeが100に設定されている場合、ファイル数は各ポーリング・サイクルで最大100まで増加します。

インバウンドJCAファイルで定義します。

SingleThreadModel

JCA

<property name="SingleThreadModel" value="true"/>

デフォルト: False(この場合、グローバル・メモリー内キューが使用されます)。

値がtrueの場合、ポーラーはファイルのリスト表示、トランスレーションまたはパブリッシュを同じスレッドで行います。つまり、パブリッシュの際にグローバル・メモリー内キューを使用しません。

インバウンドJCAファイルで定義します。

ThreadCount

JCA

<property name="ThreadCount" value="10"/>

デフォルト: -1(この場合、グローバル・スレッド・プールおよびグローバル・メモリー内キューが使用されます)。

このパラメータを指定した場合、Oracleファイル/FTPアダプタは、エンキューされたファイルを処理する際に、プロセッサ・ワーカー・スレッドのグローバル・プールを使用せず、専用のプロセッサ・スレッドを作成します。また、メモリー内キューが分割され、各コンポジット・アプリケーションが専用のメモリー内キューを取得します。

ThreadCountが0に設定されている場合、スレッド動作はシングル・スレッド・モデルと同じになります。ThreadCountが-1に設定されている場合、グローバル・スレッド・プールが有効になります。これは、デフォルトのスレッド・モデルと同じです。ThreadCountに設定できる最大値は40です。

インバウンドJCAファイルで定義します。

17.2.2 アウトバウンド調整のベスト・プラクティス

Oracleファイル/FTPアダプタには、アウトバウンド操作の調整に使用できるパラメータが用意されています。次の表で、アウトバウンド調整の方法について説明します。

パラメータ

タイプ

値

説明

ConcurrentThreshold

JCA

<property name="ConcurrentThreshold" value="100"/>

デフォルト: 20(この場合、特定のアウトバウンド・シナリオで発生するトランスレーションは20回までです。)

このパラメータには、特定のアウトバウンド・シナリオで並行して開始できるトランスレーション・アクティビティの最大数を指定します。アウトバウンド操作中のトランスレーション・ステップはCPUへの負荷が高く、他のアプリケーションやスレッドが停止する原因となるため、監視する必要があります。最大値は100です。

アウトバウンドJCAファイルで定義します。

17.2.3 アウトバウンド・パフォーマンスのベスト・プラクティス

Oracleファイル/FTPアダプタには、アウトバウンド操作のパフォーマンス・チューニングに使用できるパラメータが用意されています。次の表で、アウトバウンド・パフォーマンス・パラメータについて説明します。

パラメータ

タイプ

値

説明

UseStaging

JCA

<property name="UseStaging" value="true"/>

デフォルト: True

このパラメータがtrueに設定されている場合、アウトバウンドのOracleファイル/FTPアダプタは、トランスレーションを行ったデータをステージング・ファイルに書き込み、そのステージング・ファイルを後からターゲット・ファイルにストリーミングします。このパラメータがfalseに設定されている場合、アウトバウンドのOracleファイル/FTPアダプタは、中間ステージング・ファイルを使用しません。

アウトバウンドJCAファイルで定義します。

serializeTranslation

エンドポイント・プロパティ

<reference name="PurchaseOrderOut"> <interface.wsdl interface="...."/> <binding.jca config="PurchaseOrderOut_ftp.jca"/> <property name="serializeTranslation" type="xs:string" many="false" source="" override="may">true</property> </reference>

デフォルト:

- True(UseStagingの値がTrueに設定されている場合)

- False(UseStagingの値がFalseに設定されている場合)

Trueの場合、トランスレーション・ステップはセマフォを使用してシリアライズされます。セマフォ(トランスレーション・ステップを監視)の許可数は、ConcurrentThresholdパラメータ(前の表を参照)から導出されます。トランスレーション・ステップはCPUへの負荷が高いため、他のアプリケーションやスレッドが停止するのを防ぐために、デフォルト値Trueを使用します。

Falseの場合、トランスレーション・ステップはセマフォ外で行われます。

composite.xmlで参照できるようにBindingプロパティで定義します。

inMemoryTranslation

バインディング・プロパティ

<reference name="PurchaseOrderOut"> <interface.wsdl interface="...."/> <binding.jca config="PurchaseOrderOut_ftp.jca"/> <property name="inMemoryTranslation" type="xs:string" many="false" source=""override="may">false</property> </reference>

デフォルト: False

このパラメータは、UseStagingがFalseの場合にのみ適用されます。

Trueの場合、トランスレーション・ステップはメモリー内で行われます(つまり、メモリー内バイト配列が作成されます)。

Falseの場合、アダプタはターゲット・ファイル(FTP、FTPSおよびSFTPを含む)への出力ストリームを作成し、トランスレータにストリームのトランスレーションおよびストリームへの直接書込みを許可します。

composite.xmlで参照できるようにBindingプロパティで定義します。

17.3 Oracle JCA Adapter for Databaseのチューニング

Oracleデータベース・アダプタは事前構成済であり、様々な点でパフォーマンスが最適化されています。ただし、次の項で説明する変更を加えれば、データベースへのラウンドトリップの回数を減らすことができます。

- JCAアダプタのチューニングに関する基本的な考慮事項

- 存在チェック

注意:

この章であげているチューニングの考慮事項は、単なる例です。チューニング・パラメータはデプロイメントごとに異なります。現在の使用状況およびパフォーマンスの問題を確認し、パフォーマンスの向上につながるチューニングの考慮事項はどれかを判断してください。

17.3.1 JCAアダプタのチューニングに関する基本的な考慮事項

アダプタのパフォーマンスは、データベースへのラウンドトリップの回数、および各トリップのネットワーク・コストに直接関係しています。パフォーマンスが問題になっており、デプロイメントに変更を加えてもよい場合は、次のパラメータをチューニングすることを検討してください。

- 索引の使用
索引を使用すると、選択、更新および削除のパフォーマンスが向上します。ポーリングの際には、主キーやLogicalDeletePollingStrategyのMarkReadFieldなど、問合せの対象となるすべてのフィールドに索引を付けます。MarkReadFieldには、NULL以外のMarkUnreadValueを指定します。注意: NULL値を多数含む列に索引を作成すると、全表スキャンに戻ってしまう可能性があります。

- OptimizeMergeの無効化
OptimizeMergeパラメータを使用すると、値が指定されていないXML要素を検出できます。関連する列は、挿入および更新から除外されます。このパラメータを無効にすると、通常はパフォーマンスが向上しますが、悪影響が生じるケースもあります。複数の行が単一のXMLとして渡され、各行が異なる列セット(ユーザーが多数のオプション・フィールドを指定して入力)を持つ場合は、挿入や更新がそれぞれ異なるため、バッチ書込みの利点は得られません。

- MaxRaiseSizeの増加
MaxRaiseSizeパラメータは、BPELエンジンへ一度に発行できるXMLレコードの最大数を示します。たとえば、MaxRaiseSize = 10と設定すると、10個のデータベース・レコードが同時に発行されます。インバウンド読取りでは、たとえばMaxRaiseSize = 0(バインドなし)と設定すると、1000行を読み取った場合に1000個の要素を持つXMLを1つ作成できます。これらの要素は、単一のOracle BPEL Process Managerインスタンスを通じて渡されます。その後、アウトバウンド側のマージで1000個すべてが1つのグループにまとめられ、バッチ書込みによってすべて一度で書き込まれます。大きなペイロードをパブリッシュする際には、MaxRaiseSizeパラメータを使用します。

- MaxTransactionSizeの増加
このプロパティは、各スレッドによって1回のトランザクションで処理されるレコードの数を制御します。1000などの大きな値に設定した場合に、UseBatchDestroyオプションをオンにすると、パフォーマンスに悪影響を与えることがあります。大きなMaxTransactionSizeや小さなMaxRaiseSizeを設定した場合も、パフォーマンスに悪影響を与える可能性があります。同期シナリオでは、最大10:1の比率を保つことを検討してください。理想的なのは、1:1の比率になるまでMaxRaiseSizeを大きくすることです。

- UseBatchDestroyの有効化
このプロパティは、処理されたレコードの更新方法を制御します(たとえば、DeletePollingStrategyの場合はDeleted、LogicalDeleteStrategyの場合はMarkedProcessed)。設定すると、そのトランザクションの一部となるすべての行に対して更新/削除が1回だけ実行されます。トランザクションの行数は、MaxTransactionSizeオプションで制御します。このパラメータを設定しても、改善が見られるとはかぎりませんので注意してください。これは、デフォルトでバッチ書込みが使用されており、バッチ書込みの場合もデータベースへのラウンドトリップは1回で済むためです。

- バッチ読取りの有効化
1対他関係および1対1関係のバッチ読取りがデフォルトでオンになっています。1対1関係の結合読取りをかわりに使用することもできます。その場合、わずかな改善が見られる可能性があります。

- 削除ポーリング方法の無効化
削除ポーリング方法は、各行を個別に削除することが必要になるため、避けてください。順序付けポーリング方法では、ヘルパー表の1回の更新で1000行を破棄できます。論理削除も削除より優れています。これは通常、削除より更新のほうが高速であるためです。ただし、パフォーマンスを確保するため、必ず表に索引を作成しておいてください。索引を作成していない場合は、削除を使用すると行の総数を少なく保つことができます。全表スキャンのコストがごくわずかであるために、削除のほうが高速になる場合もあります。

- 分散ポーリングの使用
分散ポーリングを使用すると、スケーラビリティの高いポーリングを構成できます。詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のスケーラビリティに関する項を参照してください。

- 同期プロセスの使用
BPELでデータベース・アダプタ・プロセスを非同期に構成できます。Mediatorで順次ルーティング・ルールを作成することもできます。こうすると、インスタンス処理への影響が軽減されるため、データベース対データベースのシナリオにおけるスループットが向上します。

- 挿入の使用
挿入操作は、存在チェックを使用せず、パフォーマンスへの影響を増大させることもないため、パフォーマンス面で最も優れています。読取りは発生せず、書込みのみが行われます。ほとんど挿入しか行わないことがわかっているのであれば、挿入を使用し、BPELプロセス内部で一意キー制約のSQL例外を捕捉します。例外が発生した場合は、挿入のかわりにマージまたは更新を実行します。パフォーマンスを監視するには、デバッグ・ロギングを有効にして、SQLにおける各種入力を監視します。

- マージの無効化
マージでは、関連する表1つにつきSELECT文が1回余分に実行されます。SELECTが使用されるのは、各行を挿入するのか、更新するのかを判断するためです。行が更新される場合、実行される更新は最小限になります。行に変更がない場合は、何も更新されません。

- 接続プーリングの使用
アダプタがチューニングされたデータ・ソース接続プールを指すようにすることも必要です。データベース接続の作成や解放はパフォーマンスに影響を与える可能性があるため、接続プールのチューニングは重要です。

- 属性のフィルタ処理の使用
アダプタ構成ウィザードの「属性のフィルタ処理」ページで、XMLにマップするフィールド、およびフィールドにマップするXMLを選択できます。対象となるビジネス・ケースに不要な列(特に、LOBなどの大きな列)の選択を解除すると、パフォーマンスが向上します。

- ネイティブ順序付けの使用
XSL関数を使用して主キーをレコードに割り当てる場合は、アダプタの組込みネイティブ順序付けサポートを使用することを検討してください。順序付けサポートを使用すると、デフォルトで一度に50個のキーが取得され、キャッシュされます。キャッシュを行うことで、ラウンドトリップ数が減少するため、パフォーマンスが向上します。チャンク・サイズを段階的に制御するには、sequencePreallocationSizeコネクタ・プロパティを変更します。

- データベースでの主キーおよび外部キーの不使用
主キーおよび外部キーを使用すると、パフォーマンスに影響が出る可能性があります。可能であれば、これらの使用は避けてください。

- JDBCドライバ・クラス
接続プールで物理データベース接続の作成に使用されるデフォルトのJDBCドライバ・クラスはoracle.jdbc.xa.client.OracleXADataSourceです。このドライバをoracle.jdbc.OracleDriverに変更すると、パフォーマンスが向上することがあります。

JDBCドライバのチューニングの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のサード・パーティJDBCドライバとデータベース接続の構成に関する項を参照してください。

17.3.2 存在チェック

マージのパフォーマンスを最適化する方法の1つは、データベース・チェックの存在チェックを省略することです。行が新しければ、存在チェックはわずかに改善されます。これは、行全体ではなく主キーのみが返されるためです。ただし、マージの性質により、存在チェックに合格したら、行全体を読み取って変更内容を計算する必要があります。したがって、マージ中には、更新対象の行ごとにデータベースへのラウンドトリップが1回余分に発生します。AがマスターでBがプライベートな子である場合は、ルート・ディスクリプタ/表および子表に対してキャッシュのチェックを使用してください。Aが存在しない場合、Bも存在しません。Aが存在する場合、そのすべての子表がAの読取りの一環としてロードされます。

注意:

挿入が必要であることがわかっている場合に、各レコードの存在チェックがマージ中に実行されないようにするには、主キーをNULLに設定するという方法があります。

17.3.3 速度調整

DbAdapterのパフォーマンスに対する速度制限を構成して、下流コンポーネントをメッセージの急増から保護することができます。SOAで効率的に処理できるまでは、ソース・データベースのバースト・レコードを未処理のままにすることを検討してください。Oracle Adaptersリリース11.1.1.6.0から、DbAdapterのインバウンド・プロパティRowsPerPollingIntervalを設定できます。これは、1ポーリング間隔で処理できるレコード数に対する制限として機能します。デフォルトは無制限です。

次の各項では、RowsPerPollingIntervalの構成オプションについて説明します。

17.3.3.1 計算式

1秒当たりの最大行数の計算式は、次のとおりです。

SOAクラスタ内のアクティブ・ノード数 x NumberOfThreads x RowsPerPollingInterval / PollingInterval

17.3.3.2 RowsPerPollingIntervalとMaxTransactionSize

MaxTransactionSizeは、RowsPerDatabaseTransactionまたはDatabaseFetchSizeであると考えられます。1ポーリング間隔で処理できる行数に作用しません。

1つの例外は、次の構成です。

-distributed polling checked, usesSkipLocking="false"

この場合、RowsPerPollingIntervalは、無制限ではなくMaxTransactionSizeにデフォルト設定されます。

RowsPerPollingIntervalがMaxTransactionSizeまたはMaxRaiseSizeより小さい値に設定されている場合、事実上RowsPerPollingIntervalにまで小さくなります。

17.3.3.3 構成

RowsPerPollingIntervalに対してUIサポートはありません。かわりに、インバウンド・ポーリング・サービス用のdb.jcaファイルを検索し、プロパティを手動で追加します。MaxRaiseSize、MaxTransactionSizeおよびPollingIntervalプロパティと同じセクションに、任意の順序で追加します。

17.4 Oracleソケット・アダプタのチューニング

この項では、Oracleソケット・アダプタのパフォーマンス・チューニングについて説明します。接続先のソケット・サーバーが対話のたびにソケットをクローズしない場合は、接続プールを使用して、Oracleソケット・アダプタのパフォーマンスを最適化できます。接続プールを使用すると、ソケット接続を繰り返し使用できるので、対話のたびに新しいソケットを作成することによる過負荷が発生しません。

注意:

接続プール機能は、アウトバウンドの対話にのみ適用できます。ソケット・アダプタの詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のOracle JCA Adapter for Socketsに関する項を参照してください。

Oracleソケット・アダプタの接続プール機能を有効にするには、KeepAlive接続ファクトリ・プロパティをTrueに設定する必要があります。この接続プロパティは、Oracle WebLogic Server管理コンソールの「接続プール」タブで変更できます。

Oracleソケット・アダプタの接続プーリングを変更する手順については、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のOracleソケット・アダプタの接続プーリングの構成に関する項を参照してください。

17.5 Oracle SOA JMSアダプタのチューニング

この項では、Oracle SOA JMSアダプタのパフォーマンス最適化のために設定するプロパティについて説明します。詳細は、『Oracle Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド』のOracle JMSアダプタの概要に関する項を参照してください。

17.5.1 adapter.jms.receive.threadsプロパティ

パフォーマンスを改善するには、アダプタ・サービスのadapter.jms.receive.threadsプロパティをチューニングします。デフォルト値は1ですが、複数のインバウンド・スレッドを使用することでパフォーマンスを改善できます。adapter.jms.receive.threadsに指定した値は、複数のインバウンド・ポーラー・スレッドを生成するために使用されます。

例:

<service name="dequeue" ui:wsdlLocation="dequeue.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/jms/textmessageusingqueues/textmessageusingqueues/dequeue%2F#wsdl.interface(Consume_Message_ptt)"/>
<binding.jca config="dequeue_jms.jca">
<property name="adapter.jms.receive.threads" type="xs:string" many="false">10</property>
</binding.jca">
</service>

17.6 Oracle AQアダプタのチューニング

この項では、Oracle AQアダプタのチューニング構成について説明します。

17.6.1 adapter.aq.dequeue.threadsプロパティ

デキューのパフォーマンスを改善するには、アダプタ・サービスのadapter.aq.dequeue.threadsプロパティを設定します。デフォルト値は1ですが、複数のインバウンド・スレッドを使用することでパフォーマンスを改善できます。プロパティadapter.aq.dequeue.threadsの値は、複数のインバウンド・ポーラー・スレッドを生成するために使用されます。

例:

<service name="dequeue" ui:wsdlLocation="dequeue.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/aq/raw/raw/dequeue/#wsdl.interface(Dequeue_ptt)"/>
<binding.jca config="dequeue_aq.jca">
<property name="adapter.aq.dequeue.threads" type="xs:string" many="false">10</property>
</binding.jca>
</service>

17.7 Oracle MQアダプタのチューニング

Oracle MQ Seriesアダプタは、インバウンド操作のスケーラビリティ機能のみをサポートしています。Oracle MQ Seriesアダプタには、インバウンド・キューからメッセージをデキューするスレッドの数を制御するパラメータが用意されています。.jcaファイルに次のプロパティを指定する必要があります。

InboundThreadCount='N'

上の例では、Nはインバウンド・キューからメッセージをデキューするために生成するスレッドの数です。

18 Oracle Business Activity Monitoringのパフォーマンス・チューニング

この章では、Oracle Business Activity Monitoring(BAM)ダッシュボード・アプリケーションをチューニングして最適なパフォーマンスを得る方法について説明します。Oracle BAMは、企業のビジネス・サービスおよびプロセスを監視するためのツールを備えています。

この章では、変更するとBAMの全体的なパフォーマンスを強化できる便利なパラメータについて説明します。

- 18.1項「Oracle Business Activity Monitoringについて」

- 18.2項「チューニングに関する基本的な考慮事項」

18.1 Oracle Business Activity Monitoringについて

Oracle Business Activity Monitoring(BAM)は、企業のビジネス・サービスおよびプロセスを監視するためのツールを備えています。これにより、市場の指標を実際のビジネス・プロセスと相関させることや、ビジネス・プロセスをすばやく変更したり、ビジネス環境の変化に応じて修正を加えたりすることが可能になります。Oracle BAMは、ダッシュボード(リアルタイムのデータ流入を表示し、特定の状況でアラートを送信するためのルールを定義する場所)の作成に必要なツールとランタイム・サービスも提供します。

詳細は、Oracle Fusion Middleware Oracle Business Activity Monitoringのユーザーズ・ガイドを参照してください。

18.2 チューニングに関する基本的な考慮事項

この後の項では、Oracle BAMのチューニングに関する考慮事項を示します。これらはパフォーマンスの問題を解決するのに役立ちます。

- BAMサーバーのチューニング

- BAMダッシュボードのチューニング

- BAMデータベースのチューニング

- インターネット・ブラウザのチューニング

- エンタープライズ・メッセージ・ソースのチューニング

18.2.1 BAMサーバーのチューニング

次のチューニング構成を使用することで、BAMサーバーのパフォーマンスを改善できます。

18.2.1.1 ViewSetSharingパラメータおよびElementCountLimitパラメータの設定

ViewSetSharingパラメータは、BAMサーバー構成ファイルでTRUEまたはFALSEに設定できます。このパラメータを使用すると、ビューセットを共有できます(可能な場合)。一般に、特定のビューセットを他のユーザーと共有できるのは、他のユーザーが同じダッシュボードにアクセスしようとしているときに、行レベルのセキュリティやフィルタに設定されたプロンプト、パラメータなどが原因でビューセットが異なってはいない場合です。

アクティブ・データ・キャッシュ(ADC)がビューセットを追加作成せずに、同じビューセットおよびスナップショットを再利用できるよう、ViewSetSharingパラメータをTRUEに設定することを検討してください。そうすることで、BAMサーバーのリソース使用率が低下し、ユーザーのレスポンス時間が短縮されます。

このパラメータをオンにしても、ADCによる既存のビューセットの再利用が常に保証されるわけではありません。既存のビューセットの基礎となるスナップショットに加えられた変更が多すぎる場合、ADCは新しいビューセットを作成することがあります。

変更が多すぎるかどうかを判断するのに使用されるReportCacheパラメータはElementsCountLimitです。これには、レポート・キャッシュで判断のために使用されるスナップショットの変更の数を定義します。アクティブ・データが頻繁に発生する場合は、このパラメータを大きな数に設定してください。そうすることで、サーバーのCPU使用量は増えますが、ADCがビューの共有機能を使用できるようになります。ElementsCountLimitのデフォルト値は50です。

18.2.1.2 非同期サーブレットの有効化

アクティブ・データの発生率が高い期間は、ブラウザのメモリー使用量が増えます。パフォーマンスへの影響を防止するため、クライアント・マシンのメモリーを増やすことを検討してください。その場合は、BAMダッシュボード・アプリケーションに対してUseAsynchServlet=TRUEと設定します。

BAMダッシュボード・アプリケーションは、BAMサーバーが特定のスレッドを特定のユーザー・リクエストにバインドしないよう、非同期サーブレット機能を使用します。これにより、サーバー側でのシステム・リソースの使用状況が改善されます。

このパラメータは、サーバー構成ファイルにUseAsynchServlet=FALSEを追加することでオフにできます。デバッグ中はオフにして、プロセスの負荷を減らすことを検討してください。

それ以外の場合は、常にオン(デフォルト)にします。

Oracle Fusion Middleware Oracle Business Activity Monitoringのユーザーズ・ガイドのダッシュボード・ビューの作成に関する項を参照してください。

18.2.2 BAMダッシュボードのチューニング

この項では、パフォーマンスを考慮したBAMダッシュボードのチューニングについて説明します。

18.2.2.1 アクティブ・データ取得間隔のチューニング

アクティブ・データ取得間隔パラメータは、Oracle BAMアクティブ・データ・キャッシュ(ADC)がOracle BAMレポート・サーバーにイベントをプッシュする頻度(ミリ秒)を制御します。これは、アクティブなイベントがダッシュボード・ページに表示される頻度に影響を与える要因の1つです。この間隔を長くすると、Oracle BAMサーバーの負荷が軽減されます。間隔が長いと、ダッシュボードの複数の更新が単一の更新にまとめられる可能性が高くなりますので注意してください。

ADCPushIntervalのデフォルト値は1秒です。アクティブ・スタジオでアクティブ・データ取得間隔プロパティを使用して、特定のレポート内でADCPushIntervalのデフォルト値を上書きできます。

アクティブ・スタジオの使用の詳細は、Oracle Fusion Middleware Oracle Business Activity Monitoringのユーザーズ・ガイドのOracle BAMアクティブ・スタジオの概要に関する項を参照してください。

18.2.3 BAMデータベースのチューニング

Oracle Business Activity Monitoringのパフォーマンスを最適化するには、Oracle Business Activity Monitoringシステム専用のハードウェアでデータベースを管理することを検討してください。『Oracle Databaseパフォーマンス・チューニング・ガイド』に記載されている一般的なデータベース管理手法は、Oracle Business Activity Monitoring専用のデータベースにも当てはまります。

一般的なデータベース構成の詳細は、2.6項「データベース・パラメータのチューニング」を参照してください。

18.2.4 インターネット・ブラウザのチューニング

この項では、インターネット・ブラウザのパフォーマンス・チューニング構成について説明します。

18.2.4.1 iActiveDataScriptsCleanupFactorの設定

BAMは、アクティブ・データを<script>ブロックに入れて、永続的な接続を介してブラウザに送信します。この<script>ブロックによって使用されるメモリーをブラウザが解放しないことがあります。その場合、ダッシュボードのパフォーマンスに徐々に影響が現れます。

iActiveDataScriptsCleanupFactorパラメータは、このようなメモリーの問題の解決策となります。指定した数の文字を受信するたびに、ブラウザの定期的なリフレッシュが強制的に実行されます。この問題が顕著になるのは、アクティブ・データが速いペースでダッシュボードに送信されている場合です。アクティブ・データが毎秒25イベント以上の間隔でダッシュボードに到達している場合など、データの頻度が特に高いときは、この値をさらに大きくする必要があります。結局、設定する値はデータ、ビューの数、ビューセットの数、ADCPushintervalなどの要因によって異なります)。ブラウザのメモリー消費量を監視して、適切な値の決定に役立ててください。

パフォーマンスの問題が解消されないときは、このパラメータの値を大きくすることを検討してください。たとえば、アクティブ・データの増加が予想される場合は、デフォルト値の2倍から3倍の値に設定します。このパラメータのデフォルト値は1048576バイトです。通常は、このデフォルト値のままでも、再接続が頻繁に発生したり、クライアント・マシンのCPU/メモリー使用率が高くなりすぎたりするのを防止できます。

18.2.4.2 ブラウザのキャッシュ設定

Microsoft Internet Explorerを使用している場合は、閲覧履歴設定を自動に設定することを検討してください。詳細は、Microsoft Internet Explorerオンライン・ヘルプを参照してください。

18.2.5 エンタープライズ・メッセージ・ソースのチューニング

BAMエンタープライズ・メッセージ・ソース(EMS)は、BAMへのインバウンドJMS接続を可能にします。設定後、BAM EMSインスタンスはJMSキュー/トピックを監視して、JMSキュー/トピックからデータを読み取ります。各EMSインスタンスは、データをBAMサーバーの単一データ・オブジェクトにパブリッシュするよう構成されています。エンタープライズ・メッセージ・ソースは、挿入、更新、アップサート、削除の4種類の操作をサポートしています。JMSメッセージは、MapMessageとTextMessageの2種類がサポートされています。

18.2.5.1 メッセージのバッチ処理

EMSバッチ・プロセスは、複数のメッセージを単一のメッセージにまとめてからBAM EMSへ送信します。この機能を使用することで、送信側はすべてのメッセージをひとまとめにしてJMS経由で送信できます。バッチ・プロセスを使用すると、送信側からJMSサーバーへ、さらにはBAM EMSへのラウンドトリップの回数を抑えられるため、ネットワークのパフォーマンスが向上します。

19 User Messaging Serviceのパフォーマンス・チューニング

この章では、User Messaging Serviceのチューニングのヒントを示します。内容は次のとおりです。

- 19.1項「Oracle User Messaging Servicesについて」

- 19.2項「チューニングに関する基本的な考慮事項」

- 19.3項「データベース・チューニングによるスループットの最適化」

19.1 Oracle User Messaging Servicesについて

Oracle User Messaging Serviceを使用すると、Oracle JDeveloperを使用して開発し、Oracle WebLogic ServerにデプロイしたSOAアプリケーションから、通知を受信できます。

アプリケーション・レベルでは、特定の配信チャネル(SMSや電子メールなど)に対応した通知アクティビティが存在します。たとえば、電子メール通知を送信するSOAアプリケーションを構築する際には、Emailアクティビティ・コンポーネントをJDeveloperコンポーネント・パレットからワークフロー内の適切な場所にドラッグ・アンド・ドロップします。このアプリケーションは、接続して通知を送信します。

Oracle User Messaging Serviceの詳細は、Oracle WebLogic Communication Servicesの管理者ガイド、Oracle WebLogic Communication Servicesの開発者ガイドおよび『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

19.2 チューニングに関する基本的な考慮事項

ユーザー・メッセージングの使用状況およびパフォーマンスの問題に応じて、次の点をチューニングすることを検討してください。

- SMPPドライバのパフォーマンス・チューニング

- 電子メール・ドライバのポーリング頻度

19.2.1 SMPPドライバのパフォーマンス・チューニング

Short Messaging Peer-Peer Protocol(SMPP)メッセージング・ドライバは、Enterprise Managerを使用して構成できます。SMPPのパフォーマンスを最適化するうえで重要なパラメータの1つにWindowSizeがあります。これは、SMPPドライバがリモートSMSCに接続され、2つの要素の間のネットワーク待機時間が長い場合に、特に重要です。WindowSizeパラメータを構成すると、SMPPドライバが確認応答を待たずにショート・メッセージ・サービス・センター(SMSC)へ複数のリクエストを送信できるようになります。ウィンドウ機能を使用しない場合(WindowSizeが1)、ドライバはSMSCからの同期確認応答を待った後、次のメッセージを送信します。ウィンドウ機能を使用すると、1回のネットワーク・ラウンドトリップで送信できるメッセージが増えるため、全体的なスループットが向上します。

WindowSizeを増やしたことによる利点を十分に生かすには、ドライバのMDBスレッドの数も同じだけ増やす必要があります。ドライバ・スレッドがリクエストの確認応答を待たずにメッセージを処理して送信できるように、2つの値を一致させてください。2つの値を増やすことで、パフォーマンスが向上する場合もありますが、送信速度がネットワーク待機時間の影響を受けなくなった時点で、向上は止まります。また、WindowSizeに指定できる最大値は、通常SMSCのオペレータがサービス・ポリシーとして定義します。

詳細は、Oracle WebLogic Communication Servicesの管理者ガイドのOracle User Messaging Serviceの構成に関する項を参照してください。

19.2.2 電子メール・ドライバのポーリング頻度

電子メール・ドライバのCheckMailFreq構成パラメータでは、ドライバが受信電子メールをチェックする頻度を定義します。たとえば、値が30の場合、ドライバは構成済の受信ボックスを30秒おきにチェックします。このパラメータはパフォーマンスに影響を与えることがあります。チェックの頻度を上げれば、ドライバが対応可能な受信電子メールの負荷も大きくなりますが、IMAP操作またはPOP3操作が頻繁に行われるため、パフォーマンスに影響が出る可能性があります。デフォルト値は30秒です。

19.3 データベース・チューニングによるスループットの最適化

User Messaging Serviceは、送信済メッセージや受信済メッセージなどのメッセージング状態、および配信ステータス情報をデータベースに格納します。したがって、データベースおよびデータ・ソースをチューニングすると、メッセージングのスループットにその効果が表れることがあります。データ・ソースの接続プール・サイズをチューニングして、対応可能な負荷レベルを上げることもできますが、ほとんどの場合はデフォルト値で十分です。

データベース・チューニングに関する一般的な考慮事項は、2.6項「データベース・パラメータのチューニング」を参照してください。

20 Oracle B2Bのパフォーマンス・チューニング

この章では、Oracle B2Bのパフォーマンスをチューニングする方法について説明します。内容は次のとおりです。

- 20.1項「Oracle B2Bについて」

- 20.3項「スレッド数」

- 20.4項「JMSの複数のアウト・キュー設定」

20.1 Oracle B2Bについて

Oracle B2B(Business to Business)は、企業と取引パートナ間におけるセキュアで信頼性の高いビジネス・ドキュメントの交信を可能にするE-Commerceゲートウェイです。Oracle B2Bは、Business-to-Businessのドキュメント標準、セキュリティ、トランスポート、メッセージング・サービス、および取引パートナ管理をサポートしています。Oracle B2BをOracle SOA Suiteコンポジット・アプリケーション内でバインディング・コンポーネントとして使用すると、エンドツーエンドのビジネス・プロセスを実装できます。

Oracle SOA Suiteの詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。

20.2 MDSキャッシュ・サイズ

メタデータ・サービス(MDS)インスタンスのキャッシュ・サイズの値を変更すると、パフォーマンスを改善できます。xmx-to-mdsCache値の比率として5:1をお薦めします。たとえば、xmxサイズが1024の場合、mdsCacheに200MBを維持します。

Oracle Enterprise Manager Fusion Middleware Controlを使用して、これらの設定を変更できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「Oracle B2Bの構成」を参照してください。

20.3 スレッド数

b2b.inboundThreadCountおよびb2b.outboundThreadCountの値を変更すると、Oracle B2Bのメッセージ処理を改善できます。推奨値は、使用しているシステムによって異なります。たとえば、2GBのコンピュータの場合、3から5の間の設定をお薦めします。b2b.inboundThreadSleepTimeおよびb2b.outboundThreadSleepTimeプロパティは、メッセージ処理後にスレッドをスリープします。10から1000(ミリ秒)の間の設定をお薦めします。

Oracle Enterprise Manager Fusion Middleware Controlを使用して、これらの設定を変更できます。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「Oracle B2Bの構成」を参照してください。

20.4 JMSの複数のアウト・キュー設定

JMSアウト・キュー・コンポーネントは、B2BでJMSキューからデータを受け取れるようにする要素です。パフォーマンスを最大化するには、複数のJMSOUTQUEUESを設定することを検討し、対応するリスニング・チャネルをB2Bに作成してください。

21 Oracle Service Busのパフォーマンス・チューニング

この章では、Oracle Service Busのパフォーマンスをチューニングする方法について説明します。内容は次のとおりです。

- 21.1項「Oracle Service Busについて」

- 21.2項「チューニングに関する基本的な考慮事項」

- 21.3項「OSB操作設定のチューニング」

- 21.4項「トランスポート・チューニング(Oracle WebLogic ServerおよびOracle Service Bus)」

- 21.5項「プロキシ・アプリケーションの設計時の考慮事項」

- 21.6項「XQueryチューニングの設計の考慮事項」

21.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管理者ガイド』を参照してください。

21.2 チューニングに関する基本的な考慮事項

OSBの使用状況およびパフォーマンスの問題に応じて、次の点をチューニングすることを検討してください。

- JVMメモリーのチューニング

- WebLogic Serverのチューニング

21.2.1 JVMメモリーのチューニング

JVMパラメータは、OSBのパフォーマンスに影響を与える可能性があります。OSBのパフォーマンスを最適化する場合に検討する2つの主なJVMチューニング・パラメータは、ヒープ・サイズとガベージ・コレクションです。JVMのパフォーマンス・チューニングの詳細は、2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。

21.2.2 WebLogic Serverのチューニング

OSBを最適化するには、次のWebLogic Serverパラメータのチューニングを検討してください。

21.2.2.1 ドメイン・モード

本番環境では、「本番」モードのドメインを作成して、パフォーマンスを最大化します。パラメータは次のとおりです。

-Dweblogic.ProductionModeEnabled=true

WebLogic管理コンソールを使用してWebLogic Server本番モードを有効にするには、Oracle Fusion Middleware Oracle WebLogic Serverのドメイン構成についてを参照してください。

21.2.2.2 WebLogic Serverのロギング・レベル

OSBパフォーマンスのテストおよび本番環境では、できるだけ「エラー」や「警告」などの許容されている最も低いロギング・レベルを使用することを検討してください。詳細は、2.10項「ロギング・レベルの設定」を参照してください。

21.2.2.3 HTTPアクセス・ロギング

OSBパフォーマンスを最適化するには、HTTPアクセス・ロギングをオフにすることを検討してください。詳細は、5.3.1項「アクセス・ロギング」を参照してください。

21.2.2.4 JMSのチューニング

適切な永続性レベルがJava Message Service(JMS)の宛先に設定されていることを確認します。次のシナリオを検討してください。

- 非永続JMSシナリオの場合
WebLogic ServerコンソールのJMSサーバーの「一般」タブの「詳細」セクションから「ストアの有効化」フラグの選択を解除して、JMSサーバー・レベルの永続性を明示的にオフにします。また、JMS宛先レベルの永続モードを上書きできます。

- 永続JMSシナリオの場合
ファイル・ストアとJDBCストアの2つの選択肢があります。通常、ファイル・ストアの操作は、JDBCストアよりもパフォーマンスが高くなります。複数のJMSサーバーが含まれる場合、個別のディスクに各ストアを作成して、I/Oの競合を少なくします。

JMSサーバー・チューニングの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogic JMSのチューニングに関する項を参照してください。

21.2.2.5 接続バックログのバッファリング

追加のリクエストを拒否する前にWebLogic Serverインスタンスが受け入れる接続リクエストの数をチューニングできます。バックログの受入れパラメータには、待機キューにバッファリングできるTransmission Control Protocol(TCP)接続の数を指定します。この固定サイズのキューにTCPスタックが受け取った接続のリクエストが移入されますが、アプリケーションでまだ承認されていません。多くの同時クライアントを処理する場合には、このパラメータをチューニングする必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の接続バックログのバッファリングのチューニングに関する項を参照してください。

21.3 OSB操作設定のチューニング

この項では、次のOracle Service Bus操作設定について説明します。

- 「OSBの監視」

- 「OSBのトレース」

- 「プロキシ・サービスの実行時データのキャッシュ・チューニング」

21.3.1 OSBの監視

すぐに使用可能な監視サブシステムは多くのサービスおよびクラスタの複数のノードに対して非常に低いオーバーヘッドおよびスケールになりますが、数千のサービスまたは大規模なクラスタのデプロイメントを処理する場合に監視の有効化を選択すると、ネットワーク・トラフィックを削減できます。ビジネスまたはプロキシ・サービスが作成されると、その特定のサービスの監視がデフォルトで無効になります。詳細は、Oracle Fusion Middleware Oracle Service Bus管理者ガイドのプロキシ・サービスの操作設定の構成またはビジネス・サービスの操作設定の構成に関する項を参照してください。

個々に監視を有効化または無効化しているすべてのサービスの監視を有効または無効にするには、「操作のグローバル設定」ページの「モニターの有効化」オプションを使用します。詳細は、Oracle Fusion Middleware Oracle Service Bus管理者ガイドのグローバル設定の有効化に関する項を参照してください。

21.3.2 OSBのトレース

Oracle Service Busには、サーバーを停止しないでメッセージをトレースするオプションがあります。これは、1つ以上のプロキシ・サービスのメッセージ・フローを含む問題のデバッグ、診断およびトラブルシューティングを行う開発および本番環境に非常に便利な機能です。

デフォルトのトレースは無効ですが、サービスごとに有効にできます。トレースを有効にすると、ヘッダーおよびメッセージ本文を含む全体のメッセージ・コンテキストも出力されます。大きいメッセージ・サイズおよび高いスループットのシナリオの影響を把握することが重要です。

詳細は、Oracle Fusion Middleware Oracle Service Bus管理者ガイドのトレースを有効または無効にする方法に関する項を参照してください。

21.3.3 プロキシ・サービスの実行時データのキャッシュ・チューニング

OSBは、静的および動的セクションの2つのレベルのキャッシュを使用して、プロキシ・サービスの実行時メタデータをキャッシュします。このキャッシュにより、メモリー使用量およびコンパイル・コストのパフォーマンスのトレードオフが導入されます。プロキシ・サービスのキャッシュによってスループットが高くなる場合がありますが、メモリーの使用に影響を与える可能性があります。

静的セクションは、ガベージ・コレクションが実行されない上限のLeast Recently Used(LRU)キャッシュです。プロキシ・サービスが静的セクションから除外される場合、メモリーの不足時にキャッシュのガベージ・コレクションを実行できる動的セクションに降格されます。

システム・プロパティcom.bea.wli.sb.pipeline.RouterRuntimeCache.sizeでサイズを設定して、キャッシュの静的部分のプロキシ・サービスの数をチューニングできます。デフォルト値は100です。多くのプロキシ・サービスの実行時データ処理に十分なメモリーがある場合は、任意の値に増やすことができます。

次に示すように、追加のJava引数としてこのプロパティ値をsetDomainEnv.shファイルに設定できます。

-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size={size}

例:

EXTRA_JAVA_PROPERTIES="-Dcom.bea.wli.sb.pipeline.RouterRuntimeCache.size=3000 ${EXTRA_JAVA_PROPERTIES}"

21.4 トランスポート・チューニング(Oracle WebLogic ServerおよびOracle Service Bus)

ポーラー・ベースのトランスポートの待機時間およびスループットは、ソースがポーリングされる頻度およびポーリング・スイープごとに読み込まれるファイルとメッセージの数によって異なります。

次に、チューニングする主なトランスポート構成を示します。

21.4.1 ポーリング間隔

メッセージ・サイズが大きすぎず、CPUが飽和していない高いスループットのシナリオに短いポーリング間隔を使用することを検討してください。追加情報のリンクとともに主なポーリング間隔のデフォルトを次に示します。

ポーリング間隔

デフォルトの間隔

追加情報

ファイル・トランスポート

60秒

Oracle Fusion Middleware Oracle Service Bus管理者ガイドのファイル・トランスポート構成ページに関する項

FTPトランスポート

60秒

Oracle Fusion Middleware Oracle Service Bus管理者ガイドのFTPトランスポート構成ページに関する項

MQトランスポート

1000ミリ秒

Oracle Fusion Middleware Oracle Service Bus管理者ガイドのMQトランスポート構成ページに関する項

SFTPトランスポート

60秒

Oracle Fusion Middleware Oracle Service Bus管理者ガイドのSFTPトランスポート構成ページに関する項

JCAトランスポート

60秒

Oracle Fusion Middleware Oracle Service Bus管理者ガイドのJCAトランスポート構成ページに関する項

17.3.1項「JCAアダプタのチューニングに関する基本的な考慮事項」も参照してください。

21.4.2 読取り制限

読取り制限は、ポーリング・スイープごとに読み込まれるファイルまたはメッセージの数を決定します。ファイルおよびFTPトランスポートに使用されるこのデフォルトは10です。0を設定して無制限を指定できます。この値を任意の同時実行性に設定してください。詳細は、Oracle Fusion Middleware Oracle Service Bus管理者ガイドのファイル・トランスポート構成ページを参照してください。

注意:

読取り制限を高い値、ポーリング間隔を小さい値に設定すると、多くのメッセージがメモリーに同時に読み込まれる場合があります。メッセージ・サイズが大きい場合、OOM(メモリー不足エラー)が発生する可能性があります。

21.5 プロキシ・アプリケーションの設計時の考慮事項

OSBの使用およびユースケース・シナリオに基づいて、プロキシ・アプリケーションの次の設計の構成を検討してください。

- 別のXQueryで一度だけ使用される多くのOSBコンテキスト変数の作成を回避します。
割当てアクションを使用して作成されるコンテキスト変数は、XmlBeansに変換され、次のXQueryの固有のXQuery形式に戻されます。FLWOR式を使用すると、複数の「割当て」アクションを1つの割当てアクションに縮小できます。「let」文を使用して中間値を作成できます。冗長なコンテキスト変数の作成を回避すると、内部データ形式変換に関連するオーバーヘッドがなくなります。この利点とコードの可視性および変数の再利用でバランスをとる必要があります。

- $bodyなどのコンテキスト変数の内容を変換します。
1つの手順で変換を完了するには、置換アクションを使用します。$bodyの全体の内容を置換する場合、XPathフィールドを空のままにして、「ノードのコンテンツを置換」を選択します。これは、$body($body/Orderなど)の子ノードを参照して「ノード全体を置換」を選択するよりも高速です。XPathフィールドを空のままにすると、余分なXQuery評価が排除されます。

- 変換(XQuery/XSLT)リソースへの入力として、$body/*[1]を使用して$bodyの内容を表します。
OSBは、XQueryエンジンを起動しないで評価できる特別なXPathとして$body/*[1]を処理します。これは、$bodyの子を参照する絶対パスを指定するよりも高速になります。主な変換リソースを実行する前に、$body/Orderなどの一般的なXPathをXQueryエンジンで評価する必要があります。

- 純粋なコンテンツベースのルーティング・シナリオのストリーミングを有効にします。
コンテンツベースのルーティングなどの読取り専用シナリオでは、ストリーミングの有効化でパフォーマンスを向上できます。OSBは、索引付けされたXPathと組み合せてストリーミングを使用する場合にXQueryエンジンの部分解析機能を利用します。そのため、XPathで参照されるフィールドのみ、ペイロードが解析および処理されます。部分解析以外の読取り専用シナリオの利点は、ストリーミングによってXmlBeansの解析およびシリアライズに関連するオーバーヘッドがなくなることです。

複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。詳細は、21.6項「XQueryチューニングの設計の考慮事項」を参照してください。

変換の出力は、メモリーまたはディスクに圧縮されたバッファ形式で格納されます。そのため、メモリー不足の問題がない場合はストリーミングを回避する必要があります。

- 適切なQOSレベル設定およびトランザクション設定を実行します。
必要な信頼性レベルが1回および1回のみで、その設定を使用できる場合(クライアントがHTTPクライアントの場合は使用できません)を除いて、XAまたは必ず1回を設定しないでください。OSBがトランザクションを開始すれば、XAをLLRに置換して同じレベルの信頼性を実現できます。

OSBは、QOSが「ベスト・エフォート」の場合にバックエンドHTTPサービスを非同期に起動できます。非同期呼出しにより、OSBは長時間実行するバックエンド・サービスのスケーラビリティを向上できます。また、HTTPでの公開を忠実に一方向に実行できます。

- すべてのログ・アクションを無効化または削除します。
ログ・アクションにより、I/Oオーバーヘッドが追加されます。ロギングには、高負荷になる可能性があるXQuery評価も含まれます。1つのデバイス(リソースまたはディレクトリ)に書き込むと、ロック競合が発生する可能性もあります。

21.6 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>

- XPathの先頭の2つのスラッシュ(「//」)の使用を回避します。
$body//CustNameは$body/Order/CtrlArea/CustNameと同じ値を戻しますが、後者の式よりもパフォーマンスが大幅に低下します。「//」は、XMLツリーの場所に関係なくノードのすべての発生を示します。そのため、「//」の後に指定したパターンでXMLツリーの全体の深さおよび範囲を検索する必要があります。設計時にノードの正確な場所がわからない場合のみ、「//」を使用してください。

- 該当する場合、XPathを索引付けします。
パスの各ノードの後に[1]を追加して、XPathを索引付けできます。XQueryは宣言型言語で、XPathは複数のノードを戻すことができます。つまり、ノードの配列を戻すことができます。$body/Order/CtrlArea/CustNameは、$bodyの下のOrderのすべてのインスタンスとOrderの下のCtrlAreaのすべてのインスタンスを戻すことを示します。そのため、前述のXPathを適切に処理するには、ドキュメント全体を読み込む必要があります。$bodyの下にOrderの1つのインスタンス、Orderの下にCtrlAreaの1つのインスタンスが存在する場合、前述のXPathを$body/Order[1]/CtrlArea[1]/CustName[1]と書き換えることができます。

2番目のXPathは、子ノードの最初のインスタンスを戻すことを意味します。そのため、ドキュメントの上部だけをXQueryエンジンで処理してパフォーマンスを改善する必要があります。索引付けは、必要な内容のみの処理に重要です。

注意:

予想される戻り値がノードの配列の場合、索引付けを使用しないでください。たとえば、$body/Order[1]/ItemList[1]/Itemはすべてのアイテム・ノードを戻しますが、$body/Order[1]/ItemList[1]/Item[1]は最初のアイテム・ノードのみ戻します。別の例は、「for」アクションでドキュメントを分割するために使用されるXPathです。

- FLWOR式内の中間変数として、大きいXMLドキュメントの頻繁に使用する部分を抽出します。
中間変数を使用して、複数の値の共通のコンテキストを格納できます。共通のコンテキストを使用したサンプルのXPathは、次のとおりです。

$body/Order[1]/Summary[1]/Total, $body/Order[1]/Summary[1]/Status,$body/Order[1]/Summary[1]/Shipping

前述のXPathを変更して、中間変数を使用できます。

let $summary := $body/Order[1]/Summary[1]
$summary/Total, $ summary/Status, $summary/Shipping

中間変数の使用はメモリーを多く消費しますが、冗長なXPath処理を削減します。

- ストリーミングを使用した読取り専用シナリオにハイブリッド方法を使用します。
複数のフィールドを読み込むために何度もペイロードにアクセスする場合、ストリーミングの増加を無効にできます。すべてのフィールドの読込みがXMLドキュメントの1つのサブセクションの場合、ハイブリッド方法で最適なパフォーマンスを実現します。ハイブリッド方法には、プロキシ・レベルのストリーミングの有効化およびコンテキスト変数への関連するサブセクションの割当てが含まれます。このコンテキスト変数から個々のフィールドにアクセスできます。

3つの割当てアクションを使用して、「合計」および「ステータス」フィールドを取得できます。

Assign "$body/Order[1]/Summary[1]" to "foo"
Assign "$foo/Total" to "total"
Assign "$foo/Status" to "total"

22 Oracle Business Intelligenceのパフォーマンス・チューニング

この章では、Oracle Business Intelligenceのパフォーマンス・チューニングのヒントを示します。内容は次のとおりです。

- 22.1項「Oracle Business Intelligenceについて」

- 22.2項「Oracle BI Serverの問合せのパフォーマンス・チューニング」

- 22.3項「Oracle BI Serverの問合せキャッシュのパフォーマンス・チューニング」

- 22.4項「Oracle BI Webクライアントのパフォーマンス・チューニング」

22.1 Oracle Business Intelligenceについて

Oracle Business Intelligence (BI) Enterprise Edition (Oracle Business Intelligence)には、あらゆるビジネス・インテリジェンス機能が装備されており、組織からの最新データの収集、わかりやすい形式(表やグラフなど)でのデータの表示、組織内の人々への短時間でのデータの配信を行うことができます。

これらの機能によって、組織では、よりよい決定、詳細な情報に基づいた措置、より効率的なビジネス・プロセスの実装が可能になります。

22.2 Oracle BI Serverの問合せのパフォーマンス・チューニング

この項では、Oracle BI Serverにおいて問合せのパフォーマンスを向上する上で重要ないくつかの考慮事項について説明します。

BIのパフォーマンス・チューニングの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のパフォーマンス・チューニングと問合せキャッシュの管理に関する項を参照してください。

問合せのパフォーマンス向上に使用できる方法の概要を、次に示します。

- 基礎となるデータベースのチューニングと索引付け: Oracle BI Serverのデータベース問合せを迅速に返すには、基礎となるデータベースを正しく構成、チューニングおよび索引付けする必要があります。データベース製品ごとにチューニングの考慮事項がそれぞれ異なるので注意してください。
基礎となるデータベースからの戻りに時間がかかる問合せがある場合は、問合せのSQL文を問合せログに取得し、それをデータベース管理者(DBA)に提供して分析してもらいます。システムでの問合せロギングの構成の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の問合せログの管理に関する項を参照してください。

- 集計表: 問合せのパフォーマンスを向上するには、集計表の使用が非常に重要です。集計表には、データの合計があらかじめ計算されて含まれています。詳細な数千もの行から答えを再計算するより、集計表から答えを取得する方がはるかに高速です。
Oracle BI Serverでは、リポジトリに正しく指定されている場合、集計表が自動的に使用されます。集計ナビゲーションの設定例については、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』を参照してください。

- 問合せキャッシング: Oracle BI Serverでは、後続の問合せで再利用するために、問合せ結果を保存しておくことができます。問合せキャッシングにより、よく使用されるダッシュボードの場合は特に、ユーザーに対する見かけ上のシステム・パフォーマンスが大幅に向上します。ただし、ほとんどの非定型な分析ではパフォーマンスは向上しません。
問合せキャッシングの概念および設定の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BI Serverの問合せキャッシュの概要に関する項を参照してください。

- Fusion Middleware Controlでのパラメータの設定: Fusion Middleware Controlを使用して各種のパフォーマンス構成パラメータを設定することで、システムのパフォーマンスを向上できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のFusion Middleware Controlでのパフォーマンス・パラメータの設定に関する項を参照してください。

- NQSConfig.INI内のパラメータの設定: NQSConfig.INIファイルには、一時記憶域用のディスク容量を構成するパラメータ、仮想表のページ・サイズを設定するパラメータ、その他の詳細な構成設定など、Oracle BI Serverの構成およびチューニングの追加パラメータが含まれています。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。

22.3 Oracle BI Serverの問合せキャッシュのパフォーマンス・チューニング

Oracle BI Serverを構成して、問合せ結果セットのディスクベース・キャッシュをローカルに保持できます(問合せキャッシュ)。問合せキャッシュを使用すると、Oracle BI Serverがバックエンド・データソース(OracleやDB2など)にアクセスせずに、後続の多数の問合せリクエストを処理できます。このような通信コストの削減により、クエリーに対するレスポンス時間を大幅に短縮できます。『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BI Serverの問合せキャッシュの概要に関する項を参照してください。

22.4 Oracle BI Webクライアントのパフォーマンス・チューニング

すべての静的ファイルを処理するようにWebサーバーを構成し、さらに静的リソースと動的リソースを両方とも圧縮することによって、Oracle BI Webクライアント(UI)のパフォーマンスを向上できます。BI 11gはBI WebクライアントのデフォルトHTTPサーバーとして動作するWebLogic Server (WLS)に同梱されています。かわりに、Oracle HTTP Server (OHS)にWLSへのリクエストをプロキシすることを許可することで、BI Webクライアントのパフォーマンスが向上する場合があります。『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle BI Webクライアントのパフォーマンスの向上に関する項を参照してください。

第V部

Identity Management Suiteコンポーネント

この部では、パフォーマンスの向上を目的とするOracle Identity Management Suiteコンポーネントの構成について説明します。Oracle Identity Management製品を使用すると、様々なサーバーにまたがったユーザー、デバイスおよびサービスのアイデンティティの構成と管理、アイデンティティの管理の委任、ならびにエンドユーザーへのセルフサービス権限の付与が可能になります。また、複数のアプリケーション間でのシングル・サインオンを構成したり、有効な資格証明を持つユーザーのみがオンライン・リソースへのログインおよびアクセスを行えるようにユーザーの資格証明を処理することもできます。

次の章で構成されています。

- 第23章「Oracle Internet Directoryのパフォーマンス・チューニング」

- 第24章「Oracle Virtual Directoryのパフォーマンス・チューニング」

- 第25章「Oracle Identity Federationのパフォーマンス・チューニング」

- 第26章「Oracle Fusion Middlewareセキュリティのパフォーマンス・チューニング」

23 Oracle Internet Directoryのパフォーマンス・チューニング

この章では、インストールされているOracle Internet Directoryのチューニングおよびサイズ設定のガイドラインを示します。内容は次のとおりです。

- 23.1項「Oracle Internet Directoryについて」

- 23.2項「Oracle Internet Directoryのチューニングの概要」

- 23.3項「チューニングに関する基本的な考慮事項」

- 23.4項「拡張構成」

- 23.5項「チューニングに関する優先度の低い考慮事項」

- 23.6項「特殊なユースケース」

- 23.7項「検索の最適化」

- 23.8項「UNIXシステムおよびWindowsシステムでのパフォーマンスの評価」

- 23.9項「チューニングとサイズ設定ウィザードを使用した推奨事項の取得」

- 23.10項「oidstats.sqlを使用したデータベース統計の更新」

- 23.11項「パフォーマンス関連のレプリケーション構成属性の設定」

- 23.12項「システム構成属性の管理」

- 23.13項「ガベージ・コレクション構成属性の設定」

23.1 Oracle Internet Directoryについて

Oracle Internet Directoryは、オラクル社のLightweight Directory Application Protocol(LDAP)バージョン3のディレクトリ・サーバーです。Oracle Internet Directoryは、スケーラビリティ、可用性および管理性に優れています。また、マルチスレッド、マルチプロセス、マルチインスタンスのプロセス・アーキテクチャを備え、Oracle Databaseをディレクトリ・ストアとして使用します。この独自の物理アーキテクチャにより、Oracle Internet Directoryは、対称型マルチプロセッサ(SMP)、不均一メモリー・アクセス(NUMA)、クラスタ・ハードウェアなどの複数のハードウェア・アーキテクチャにデプロイできます。Oracle Internet Directoryの物理アーキテクチャは、ハードウェア・リソースおよび多数の高可用性構成で、リニアなパフォーマンスのスケーラビリティを実現します。

詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。

23.2 Oracle Internet Directoryのチューニングの概要

注意:

Oracle Internet Directoryのデフォルト構成は、ほとんどの本番用デプロイメントおよびテスト用デプロイメントにとって最適なものではありません。最適なパフォーマンスおよび可用性を得るには、少なくとも23.3項「チューニングに関する基本的な考慮事項」に示す手順に従う必要があります。

関連項目:

- 23.9項「チューニングとサイズ設定ウィザードを使用した推奨事項の取得」。

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryのトラブルシューティング」

この章の推奨事項の多くは、Oracle Internet Directoryのシステム構成属性およびレプリケーション構成属性の変更を必要とします。

関連項目:

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「システム構成属性の管理」

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「レプリケーション構成属性の管理」

- 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の「属性リファレンス」

Oracle Internet Directoryの構成属性の詳細は、これらを参照してください。

23.3 チューニングに関する基本的な考慮事項

チューニングとは、ディレクトリのパフォーマンスを改善するためにパラメータを調整することです。Oracle Internet Directoryのデフォルト構成は、ほとんどすべてのデプロイメントでチューニングを必要とします。この項に記載されている要件および推奨事項を十分に確認してください。

23.3.1 データベース・パラメータ

Oracle Databaseインスタンス・パラメータの推奨される最小値を表23-1に示します。

表23-1 Oracle Databaseインスタンス・パラメータの最小値

パラメータ

値

注意

sga_targetと

sga_max_size

1700M(32ビットのシステムの場合)

sga_targetおよびsga_max_sizeを使用したSGA自動チューニングを使用している場合に適用されます。bulkdeleteのパフォーマンスにおいて特に重要です。

ディレクトリ・サイズが100万エントリを超える場合や、I/Oレートが高い場合には、大きな値が必要になることがあります。64ビットのシステムでは、マシン上のOracle Databaseで使用できるRAMの最大60から70%まで増やすことができます。

db_cache_size

1200M(32ビットのシステムの場合)

sga_targetおよびsga_max_sizeを使用したSGA自動チューニングを使用していない場合に適用されます。(このパラメータを使用せずに、sga_targetおよびsga_max_sizeを使用したSGA自動チューニングを行うことをお薦めします。)

ディレクトリ・サイズが100万エントリを超える場合や、I/Oレートが高い場合には、大きな値が必要になることがあります。64ビットのシステムでは、マシン上のOracle Databaseで使用できるRAMの最大60から70%まで増やすことができます。

shared_pool_size

300M

sga_targetおよびsga_maxsizeを使用したSGA自動チューニングを使用していない場合に適用されます。

session_cached_cursors

100

processes

500

pga_aggregate_target

300M

大規模なbulkload操作を実行する前に、この値を1から4GBに設定します(十分なRAMが使用可能な場合)。操作が完了したら、元の値に戻します。

job_queue_processes

1以上。

このパラメータは、Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用している場合にのみチューニングします。

max_commit_propagation_delay

99以下

Oracle RACデータベース・デプロイメントのRDBMS v10.1にのみ、このパラメータをチューニングします。

Oracle Databaseインスタンス・パラメータの設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

23.3.2 LDAPサーバー属性

この項の推奨事項は、表23-2にまとめてあります。

- LDAPアプリケーション・トラフィックを処理するOracle Internet Directoryサーバー・インスタンスのプロセスおよびスレッドの数をチューニングします。これは、全体的なパフォーマンスに大きな影響を与えます。表23-2に記載されたorclmaxccおよびorclserverprocsの推奨設定を参照してください。

- レプリケーションまたはOracle Directory Integration Platformをデプロイしない場合、変更ログの生成を無効にします。属性orclgeneratechangelogを0に設定します。

- ディレクトリに参照エントリがない場合、LDAP検索で参照をスキップします。orclskiprefinsqlを1に設定します。これは、パフォーマンスに大きな影響を与える可能性があります。

- アイドル状態のLDAP接続をオープンのままにせず、一定時間の経過後にクローズします。こうすると、接続が必要以上に増えるのを防止できます。たとえば、orclldapconntimeoutを60分に設定します。
これは、g(10.1.4.0.1)から、操作統計を追跡するよう構成されていないユーザーにしか設定できなくなりました。統計を収集するよう構成されているユーザーの接続は、この設定に従ってタイムアウトしません。

関連項目:

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のFusion Middleware Controlを使用した統計収集のためのユーザーの構成に関する項。

- LDAP検索操作のベースDNがディレクトリになく、クライアントが詳細なMatchDN情報を必要としない場合は、詳細なMatchDN情報を無効にします。orclmatchdnenabledを0に変更します。

次の値は、ほとんどのデプロイメントに適しています。

表23-2 チューニングするLDAPサーバー属性

属性

デフォルト

推奨値

注意

orclmaxcc

2

10

サーバーの再起動が必要です。

orclserverprocs

1

システムのCPUコアの数

orclskiprefinsql

0

1

この変更を行うことを強くお薦めします。LDAP参照エントリがある場合は変更しないでください。LDAP参照エントリは共通ではありません。

サーバーの再起動が必要です。

orclgeneratechangelog

1

0

レプリケーションまたはOracle Directory Integration Platformをデプロイしない場合にのみ、変更ログの生成を無効にします。

orclldapconntimeout

0(タイムアウトなし)

場合によって異なる(一般的には60分)

統計を追跡するよう構成されているユーザーはタイムアウトしません。

orclmatchdnenabled

1

0

検索のベースDNが存在せず、アプリケーションが詳細なMatchDN情報を必要としない場合にのみ、無効にします。

Oracle Enterprise Manager Fusion Middleware Controlを使用したorclserverprocs、orclldapconntimeoutおよびorclmatchdnenabledの構成の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlを使用したorclskiprefinsqlまたはorclmatchdnenabledの構成の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の共有プロパティの構成に関する項を参照してください。

これらの属性およびorclgeneratechangelogのコマンドラインからの構成の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

23.3.3 データベース統計

LDAPコマンドを使用して多数のエントリをOracle Internet Directoryに追加すると、ディレクトリのパフォーマンスに影響が出ることがあります。その場合は、データベース統計を更新します。23.10項「oidstats.sqlを使用したデータベース統計の更新」を参照してください。

通常、この操作が必要になるのは、Oracle Internet Directoryのインストール後に初めてエントリをバルクで追加する場合のみです。データベース統計は夜間に自動的に更新されるため、この操作を再度実行する必要はありません。ただし、データ・フットプリントを変更していないのにLDAP操作が突然遅くなった場合は、一度oidstats.sqlを実行してパフォーマンスが改善するかどうか確認することを検討してください。データベースSQL実行計画の変更が原因で影響が出ている可能性があります。この場合は、oidstats.sqlによって改善します。

関連項目:

SQLチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

bulkloadツールを使用してエントリを追加する場合、データベース統計の更新は不要です。データベース統計は、bulkloadコマンドによって自動的に更新されます。

23.4 拡張構成

前の項で推奨されている変更を行った後、デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。

23.4.1 レプリケーションまたはOracle Directory Integration Platform

Oracle Internet DirectoryをOracle Directory Integration Platformまたはレプリケーションとともにデプロイする際には、この2つのサーバー専用のLDAPサーバー・インスタンスを使用すると、パフォーマンスが向上します。この場合、デフォルトのOracle Internet Directory LDAPインスタンスでLDAPアプリケーションのトラフィックを処理し、2番目のインスタンスでレプリケーション・サーバーおよびOracle Directory Integration PlatformサーバーからのLDAPリクエストを処理することができます。

1. 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryインスタンスの管理」の説明に従って、追加のサーバー・インスタンスを作成します。

2. 新しいインスタンス構成で、orclmaxccを10に、orclserverprocsを1に設定します。

3. 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryインスタンスの管理」の説明に従って、サーバーを再起動します。

4. 新しいインスタンスが使用するSSLポートおよび非SSLポートを設定し、レプリケーションおよびOracle Directory Integration Platformがこれらのポートを指し示すように構成します。

orclmaxccおよびorclserverprocsを構成するには、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

注意:

Oracle Internet Directoryクラスタ構成(ラックマウントまたはマルチボックス)では、レプリケーション・サーバーを1つのハードウェア・ノードでのみ起動する必要があります。レプリケーション専用のLDAPサーバー・インスタンスは、それと同じノードで起動してください。Oracle Directory Integration Platformサーバーは、別のノードにあってもかまいません。

23.4.2 レプリケーション・サーバー構成

次の推奨事項は、レプリケーション・トラフィックが多い場合に役立ちます。変更を行う前に、必ずトレードオフを理解しておいてください。推奨値は、表23-3にまとめてあります。

- 読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解決をオフにすると、パフォーマンスへの影響を軽減できます。そのためには、orclconflresolutionの値を0に変更します。

- サプライヤがボトルネックになっている場合、サプライヤのorclthreadspersupplierを増やします。コンシューマがボトルネックになっている場合も、コンシューマのorclthreadspersupplierを増やせますが、並列度が高まることによって変更ログの適用時に競合状態が生じ、結果的に管理者操作キュー(HIQ)の変更が増加することに注意してください。

- orclchangeretrycountを減らして、新しい変更ログのリソースを増やします。ただし、競合が発生している場合は、これによって管理者操作キュー(HIQ)の変更が増加します。

- orclupdatescheduleを0に変更して、サーバー・プロセスの変更ログが60秒おき(デフォルト)ではなく、ただちに作成されるようにします。これは、サプライヤとコンシューマの両方で行います。

- orclhiqscheduleの値を大きくします。たとえば、管理者操作キュー(HIQ)に1日4回アクセスすれば十分であり、デプロイメントにもそれが適している場合は、orclhiqscheduleを21600秒(6時間)に設定します。

表23-3は、これらの推奨事項をまとめたものです。

表23-3 レプリケーション属性

属性

デフォルト

推奨値

注意

orclthreadspersupplier

転送=1

適用=5

転送スレッドを1に、適用スレッドを10以上に設定

サプライヤがボトルネックになっている場合に最も有効です。

orclchangeretrycount

10

4

変更ログのリソースが増えますが、HIQが増加することがあります。

orclupdateschedule

60秒

0

変更ログがただちに処理されます。

orclhiqschedule

600秒

216000秒

新しい変更を処理するためのリソースが増えます。

orclconflresolution

1

0

読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合にのみ変更します。

これらのレプリケーション属性の設定の詳細は、23.11項「パフォーマンス関連のレプリケーション構成属性の設定」を参照してください。

23.4.3 ガベージ・コレクション構成

デフォルトでは、Oracle Internet Directoryはデータベース・ジョブを実行して、変更ログ、サーバー管理性統計、その他のデータをパージします。各ジョブは、午前0時から15分間隔で開始されます。表23-4に示すパラメータを変更すれば、この構成をデプロイメント要件に合せて変更できます。

表23-4 ガベージ・コレクション構成パラメータ

パラメータ

値

注意

orclpurgetargetage

10日(240時間)未満

変更ログを保持する必要がない場合のみ

orclpurgeinterval

6から12時間

これらの属性は、ldapmodifyまたはOracle Directory Services Managerを使用して変更できます。23.13項「ガベージ・コレクション構成属性の設定」を参照してください。

23.4.4 Oracle Internet DirectoryとRACデータベース

23.4.2項「レプリケーション・サーバー構成」で説明したとおり、デフォルトのサーバーに加えて、Oracle Directory Integration Platformおよびレプリケーション専用のLDAPサーバーを使用できます。Oracle Internet Directoryクラスタでは、すべてのOracle Internet DirectoryノードでデフォルトのLDAPインスタンスを起動しますが、この専用のインスタンスはOracle Directory Integration Platformおよびレプリケーションが稼働しているノードでのみ起動します。

どのデータベース・インスタンスにOracle Internet Directoryを接続するかを慎重に検討してください。

- クラスタ内のOracle Databaseインスタンス間のロード・バランシング、またはフェイルオーバー・モード用にOracle Internet Directoryを構成できます。

- レプリケーションおよびOracle Directory Integration Platform専用のLDAPサーバー・インスタンスを使用する場合は、そのインスタンスの接続文字列をフェイルオーバー用に構成できます。tnsnames.oraで次の文字列を使用します。

(FAILOVER=ON)(LOAD_BALANCE=OFF)

- bulkloadなどのバルク操作の実行時には、ツールを1つのOracle Databaseインスタンスにのみ接続してすべての操作を実行します。

- Oracle Internet Directoryインスタンスを次のように構成します。

- LDAPアプリケーション・トラフィックを処理する各ノードにOracle Internet Directoryインスタンスを1つ配置

- Oracle Internet Directoryレプリケーション・サーバーおよびOracle Directory Integration Platformサーバーのインスタンスを1つのノードに配置

23.4.5 パスワード・ポリシーとパスワード検証プロファイル

Oracle Internet Directoryでは、パスワード・ポリシーおよびパスワード検証プロファイルがデフォルトで有効になっています。特定のデプロイメントでパスワード・ポリシーを適用する必要がない場合は、パスワード・ポリシーを無効にできます。デフォルトで有効になっているパスワード検証プロファイルは、Enterprise User SecurityやOracle Collaboration SuiteなどのOracle製品で必要とされる特定のパスワード・ベリファイアの生成を制御します。他のOracle製品用にOracle Internet Directoryがデプロイされていない場合は、すべてのパスワード検証プロファイルを無効にできます。

パスワード・ポリシーおよびパスワード・ベリファイアは、Oracle Directory Services Managerまたはldapmodifyを使用して無効にできます。

関連項目:

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「パスワード・ポリシーの管理」。

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「パスワード・ベリファイアの管理」。

23.4.6 サーバー・エントリ・キャッシュ

Oracle Internet Directoryのサーバー・エントリ・キャッシュを使用すると、Oracle Internet Directoryのサーバー・プロセス・ヒープにLDAPエントリをキャッシュすることで、パフォーマンスを改善できます。エントリ・キャッシュの構成によって効果が得られるのは、すべてまたは大部分のエントリがキャッシュ可能な場合のみです。

注意:

サーバー・エントリ・キャッシュは、小規模なディレクトリ・デプロイメントでのみ効果的です。ここに記載したチューニング推奨事項の中には、これまでの項のチューニング推奨事項と矛盾するものもあります。特定のデプロイメントにエントリ・キャッシュを適用できるかどうかを確認し、次にあげる考慮事項のすべてが該当する場合にのみ、この項で説明するチューニングを採用してください。

23.4.6.1 エントリ・キャッシュを使用する条件

次の条件を満たす場合にのみ、Oracle Internet Directoryのサーバー・エントリ・キャッシュの使用を検討してください。

- クラスタ構成を使用していないこと

- 予想される更新率が非常に低いこと(特にグループ・エントリ)。

23.4.6.2 エントリ・キャッシュを使用する利点

エントリ・キャッシュを使用する主な利点の1つに、ベース・スコープを使用したLDAP検索操作が約5倍速くなることがあります。これは、エントリのすべて、または大半がキャッシュ可能な場合にのみ当てはまります。キャッシュ・ミスは、エントリ・キャッシュを無効にするよりコストがかかります。

23.4.6.3 エントリ・キャッシュを構成するための値

サーバー・エントリ・キャッシュは、表23-5に示す値を設定することで構成および最適化できます。

表23-5 サーバー・エントリ・キャッシュの構成

属性

デフォルト

推奨値

注意

orclmaxcc

2

10

この属性を変更した後、サーバーを再起動します。

orclserverprocs

1

システムのコアの総数。

orclecacheenabled

1

1

orclecachemaxsize

200000000バイト

ディレクトリの合計サイズ(バイト)

この属性の最適な設定を決定するには、ディレクトリ情報ツリーのエントリ数を使用し、その数に平均エントリ・サイズを掛けます。

LDIF形式のエントリ・サイズの3倍の見積りをしてください。

orclecachemaxentries

100000

DIT内のエントリ総数

orclecachemaxentsize

1000000

DIT内の最大エントリのサイズ(バイト)

通常、最大エントリはグループ・エントリまたはバイナリ属性値のエントリです。

たとえば、ディレクトリ情報ツリーの合計サイズが300Kで、LDAPデータ交換ファイル(LDIF)形式の300Kのエントリの合計サイズが500Mである場合、orclecacheenabledを1に、orclecachemaxsizeを1,500,000,000に、orclecachemaxentriesを300,000に設定します。最大のグループ・エントリまたはバイナリ値のエントリのサイズが10Mの場合、orclecachemaxentsizeを10,000,000に設定します。

ディレクトリ情報ツリーのエントリ数を取得するには、次のコマンドを使用します。

sqlplus ods@oiddb
select count(*) from ct_dn;

oidctl connect=oiddb status -diag

次の例は、oidctl connect=oiddb status -diagコマンドの出力を示しています。

+--------------------------------------------------------------------------+
| Process      |  PID   |   InstName    |  CompName   |Inst#| Port | Sport |
+--------------------------------------------------------------------------+
| oidmon       |   8192 |         inst1 |        oid1 |    0|      |       |
+--------------------------------------------------------------------------+
| oidldapd disp|   8201 |         inst1 |        oid1 |    1| 5678 |     0 |
| oidldapd serv|   8205 |         inst1 |        oid1 |    1| 5678 |     0 |
| oidldapd serv|   8209 |         inst1 |        oid1 |    1| 5678 |     0 |
| oidldapd serv|   8213 |         inst1 |        oid1 |    1| 5678 |     0 |
| oidldapd serv|   8217 |         inst1 |        oid1 |    1| 5678 |     0 |
| Config   DN  | cn=oid1,cn=osdldapd,cn=subconfigsubentry                  |
+--------------------------------------------------------------------------+

+--------------------------------------------------------------------------+
|Printing LDAP Operation in progress status ...                          |
+--------------------------------------------------------------------------+
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8205 WorkerID: 8 DBSID: 168 DBPID: 8245 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8205 WorkerID: 9 DBSID: 170 DBPID: 8253 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8205 WorkerID: 10 DBSID: 180 DBPID: 8261 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8205 WorkerID: 11 DBSID: 189 DBPID: 8269 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8209 WorkerID: 13 DBSID: 171 DBPID: 8249 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8209 WorkerID: 9 DBSID: 181 DBPID: 8257 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8209 WorkerID: 12 DBSID: 193 DBPID: 8267 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8209 WorkerID: 10 DBSID: 199 DBPID: 8225 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8209 WorkerID: 11 DBSID: 190 DBPID: 8227 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8205 WorkerID: 13 DBSID: 197 DBPID: 8223 ==> IDLE
+--------------------------------------------------------------------------+
OIDLDAPD_PID: 8205 WorkerID: 12 DBSID: 182 DBPID: 8229 ==> IDLE
+--------------------------------------------------------------------------+

Cache Max Size                       : 1000000512
Max Entries configured             : 1000000
Max Entries cached                  : 100000
Num Entries in Cache               : 100000
Num Entries in GC                   : 0
Page size                                  : 976556
Entry cache Hit count                : 6172127
Entry cache Mis count               : 99999
Hash Area bytes used               : 24497696
Hash Area blocks used             : 37
ResultSet cache bytes used       : 6799604
Resultset cache blocks used      : 300000
Entry cache bytes used             : 404047820
Entry cache blocks used           : 5900293
Cache memory used                 : 435345120

属性を構成するには、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

23.4.7 結果セット・キャッシュ

結果セット・キャッシュは、完全な結果セットをメモリーに格納できるようにするOracle 11g OIDの機能です。SQL問合せが実行され、その結果セットがキャッシュ内にある場合、SQL実行のオーバーヘッドのほぼ全部が回避されます。これには、解析時間、論理読取り、物理読取り、通常に発生するキャッシュ競合オーバーヘッド(インスタンスのラッチ)が含まれます。結果キャッシュを構成すると、パフォーマンスが向上する可能性があります。これは、ほとんどのLDAPアプリケーションは通常、mail=john.doe@acme.comやuid=john.doeなどのユーザー・エントリをユーザー・ツリーから検索するためです。このような問合せは、ユーザーがアプリケーションにログインしたり、使用したりするたびに、アプリケーションによって繰り返されます。このような問合せの結果セットは、単一エントリであることがあります。問合せが実行されるたびに、そのエントリを求めてOIDはデータベースを検索するため、パフォーマンスに影響が出ることがあります。

23.4.7.1 結果セット・キャッシュを使用する条件

次の条件を満たす場合にのみ、結果セット・キャッシュの使用を検討してください。

- フィルタが1つまたは少数のエントリと合致すること。

- SQL文によってディスクまたはバッファから複数の読取りが発生すること(高コスト)

23.4.7.2 結果セット・キャッシュを使用する利点

エントリ・キャッシュを使用する利点は次のとおりです。

- OIDはデータベースを検索せずにフィルタを評価するため、データベースに対する負荷が軽減します。
結果セット・キャッシュのデータベース・パラメータは、クライアント側またはサーバー側で構成できることに注意してください。サーバー側のキャッシュが有効になっていると、結果セット・キャッシュは、膨大な量のデータベース・メモリーを消費できるため、OIDのパフォーマンスに影響が出る可能性があります。

- 結果セット・キャッシュを使用しないときのパフォーマンスと比較すると、パフォーマンスは3から5倍の影響を受けます。

23.4.7.3 結果セット・キャッシュを構成するための値

次の構成属性に対する変更には、OIDサーバー(すべてのインスタンス)を再起動する必要があることに注意してください。

表23-6 チューニングする結果セット・キャッシュ属性

属性

デフォルト

推奨値

注意

OrclRSCacheAttr

cn、mail、uid、orclguid

複数値属性。値には属性の名前が含まれます。通常、これらの属性はエントリの存続期間中変更できません。

ResultSetMaxEntries

4

特定の検索に対する、キャッシュ可能なエントリの最大数。

ResultSetMaxCacheSize

10MB

結果セット・キャッシュの共有メモリーで割当可能な最大メモリー。

ResultSetMaxTime

8時間

キャッシュが満杯になったときの結果セット・キャッシュの存続時間(TTL)。

23.4.8 セキュリティ・イベント追跡のチューニング

インスタンス固有の構成エントリ属性orcloptrackmaxtotalsizeおよびorcloptracknumelemcontainersは、セキュリティ・イベント追跡に使用するメモリー量を制御します。

属性orcloptrackmaxtotalsizeには、セキュリティ・イベント追跡で各タイプの操作に使用できるRAMの最大バイト数を指定します。ある操作に関して収集される情報について、この制限を超えると、ディレクトリ・サーバーは新しい情報の収集を停止し、該当するメッセージをサーバー・ログ・ファイルに記録します。比較操作の場合、ディレクトリ・サーバーではこの属性値の2倍のメモリーを使用します。これは、比較操作を実行するユーザーと、パスワードを比較されているユーザーに関する情報を合せた量です。orcloptrackmaxtotalsizeのデフォルト値は100000000バイトで、ほとんどのデプロイメントはこれで十分です。この値は200MBまで増やせます。orcloptrackmaxtotalsizeの変更の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項のインスタンス固有の構成属性の例を参照してください。

属性orcloptracknumelemcontainersによって、Oracle Internet Directoryサーバーでセキュリティ・イベント追跡に割り当てるメモリー内キャッシュ・コンテナの数を選択できます。この属性にはサブタイプが2つあります。1stlevelと2ndlevelです。1stlevelサブタイプでは、操作を実行するユーザーの情報を格納するためのメモリー内キャッシュ・コンテナの数を設定します。2ndlevelサブタイプは比較操作にのみ適用されます。このサブタイプでは、詳細比較操作統計がプログラムされている場合に、ユーザー・パスワードが比較および追跡されるユーザーの情報を格納するためのメモリー内キャッシュ・コンテナの数を設定します。両サブタイプのデフォルト値は256です。これらのサブタイプの適切な値は、次のように、環境内のユーザー数、およびディレクトリへのアクセスに使用されるアプリケーションの数によって異なります。

- 多数のエンドユーザーにかわって複数のアプリケーションが操作を実行するデプロイメントでは、アプリケーションの数にディレクトリに直接アクセスするエンドユーザー用の数百を足した数に比例して1stlevelを設定します。2ndlevelは、エンドユーザーの数に比例して設定します。

- エンド・ユーザー自身が操作を行うデプロイメントでは、1stlevelはエンド・ユーザーの数に比例して設定し、2ndlevelは25などの小さい値に設定します。

- 通常、比例値は5分の1です。ほとんどの環境で10分の1から2分の1までの割合が適切です。

デプロイメントでの必要に応じて、セキュリティ・イベント収集が有効になっている場合にのみorcloptracknumelemcontainersに値を設定します。

23.5 チューニングに関する優先度の低い考慮事項

この項では、パフォーマンスを改善することはあるが、優先度が低いとみなされている属性について説明します。

23.5.1 検索で返されるエントリの数

属性orclsizelimitは、検索で返されるエントリの最大数を制御します。デフォルト値は10000です。この値を非常に大きくすると、サーバーのパフォーマンスに影響が出ます。また、レプリケーション・サーバーが一度に処理できる変更ログの最大数を制限する役割も果します。

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

23.5.2 グループ・キャッシュの有効化

インスタンス固有のサブエントリ属性orclenablegroupcacheは、権限グループおよびACLグループをキャッシュするかどうかを制御します。このキャッシュを使用すると、ユーザーのアクセス制御評価のパフォーマンスが向上します。

グループ・キャッシュは、権限グループ・メンバーシップが頻繁に変更されない場合に使用してください。権限グループ・メンバーシップが頻繁に変更される場合は、グループ・キャッシュをオフにすることをお薦めします。これは、グループ・キャッシュを計算する処理がパフォーマンスに影響を与えるためです。デフォルトは1(有効)です。0(ゼロ)に変更すると、無効になります。

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

23.5.3 書込み操作のタイムアウト

LDAPクライアントが操作を開始した後、構成された秒数の間サーバーに応答しないと、サーバーは接続をクローズします。この秒数は、インスタンス固有の構成エントリのorclnwrwtimeout属性によって制御されます。デフォルトは30秒です。

orclnwrwtimeoutの変更には、Fusion Middleware Controlまたはコマンドラインを使用できます。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項を参照してください。

23.6 特殊なユースケース

この項では、23.3項「チューニングに関する基本的な考慮事項」に加えて、さらにチューニングが必要になる特殊なユースケースについて説明します。

23.6.1 バルク・ロード操作

大規模なbulkload操作を予定している場合は、次の変更を行います。

- 操作の間、データベース初期化パラメータpga_aggregate_targetを1から4GBに設定します(十分なRAMが使用可能な場合)。

- 多数のエントリをロードする前に、データベース一時表領域を大きくします。100万エントリのロードにつき、約1GBの一時表領域が必要になります。この一時表領域は、操作の完了後に解放できます。

23.6.2 バルク削除操作

大規模なbulkdelete操作を予定している場合は、次のタスクを実行します。

- データベース初期化パラメータsga_targetが、23.3.1項「データベース・パラメータ」の説明に従ってチューニングされていることを確認します。

- データベース初期化パラメータlog_bufferを10Mに設定します。こうすると、パフォーマンス上の利点が増します。

- 100MB以上のデータベースREDOログ・ファイルが少なくとも3つあることを確認します。

- UNDO表領域の合計サイズが1GB以上であることを確認します。

- 次の23.6.3項「負荷の高いLDAP書込み操作」のREDOログおよびUNDO表領域に関する推奨事項に従います。

23.6.3 負荷の高いLDAP書込み操作

LDAP書込み操作の負荷が高い場合や、多くのbulkdelete操作を実行する場合は、次の値のチューニングを検討します。

- データベースREDOログ・ファイルのサイズまたは数を、合計サイズが1000から1500MBになるよう増やします。他に考慮すべき要素によってREDOログの合計サイズは変わります。

- ディスクの構成によっては、REDOログ・ファイルを専用のディスク・セットに置くほうが効果的な場合があります。

- データ・ファイルをUNDO表領域に追加することで、この表領域を大きくします。ほとんどのデプロイメントでは、2から4GBで十分です。

- Oracle Internet Directoryのサーバー・エントリ・キャッシュは使用しないでください。23.4.6項「サーバー・エントリ・キャッシュ」を参照してください。

- Oracle Internet DirectoryレプリケーションもDIPもデプロイされていない場合、変更ログの生成を無効にします。23.4.1項「レプリケーションまたはOracle Directory Integration Platform」を参照してください。

表23-7は、この項で説明したREDOログおよびUNDO表領域に関する推奨事項をまとめたものです。

表23-7 REDOログおよびUNDO表領域の値

属性

値

注意

REDOログ

3つのログ(それぞれ100MB)

多数のbulkdelete操作。

REDOログ

合計サイズ1000から15000MB

多数の書込み操作。

UNDO表領域

合計で1GB以上

多数のbulkdelete操作。

UNDO表領域

2から4GB

多数の書込み操作。

23.7 検索の最適化

この項の内容は次のとおりです。

- 23.7.1項「大きいグループ・エントリの検索の最適化」

- 23.7.2項「スキュー属性の検索の最適化」

- 23.7.3項「複雑な検索フィルタのパフォーマンスの最適化」

23.7.1 大きいグループ・エントリの検索の最適化

member属性とuniquemember属性のいずれかが数千の属性値を持つグループ・エントリの検索では、待機時間が長くなる可能性があります。待機時間が受け入れ難いほど長い場合は、これを減らせる方法があります。

最も簡単な方法は、検索する属性の数を減らすことです。グループ・エントリの属性をすべて取得する必要がないのであれば、待機時間を最適化するために検索リクエストに必須の属性を指定します。

23.7.1.1 エントリ・キャッシュを有効にした構成

必須の属性を指定してもまだ待機時間が長すぎる場合は、エントリ・キャッシュに大きいグループ・エントリをキャッシュします。そのためには、インスタンス固有の構成エントリのorclEcacheMaxEntSize属性の値を増やします。

cn=componentname,cn=osdldapd,cn=subconfigsubentry

この属性は、キャッシュ・エントリの最大サイズを制御します。

注意:

大きいグループに対する更新が頻繁になることが予想される場合は、このチューニング方法を使用しないでください。エントリ・キャッシュを無効にした構成を使用します。

23.7.1.2 エントリ・キャッシュを無効にした構成

アクションは不要です。この構成はデフォルトで有効になっています。

23.7.2 スキュー属性の検索の最適化

通常の検索リクエストを処理する場合、ディレクトリ・サーバーはSQL文をOracle Databaseに送信します。ある属性のレスポンス時間が属性の値によって大きく異なる場合、この属性はスキュー属性と呼ばれます。たとえば、my_attribute=value1とmy_attribute=value2の検索で、レスポンス時間が大きく異なる場合、my_attributeはスキュー属性と呼ばれます。

このような属性を、DSA構成エントリにあるorclskewedattribute属性の値として追加することにより、検索時のレスポンス時間を均一にできます。DSA構成エントリのDNは次のとおりです。

cn=dsaconfig,cn=configsets,cn=oracle internet directory

デフォルトでは、objectclass属性はorclskewedattribute属性内に値としてリストされます。

ldapmodifyを使用してorclskewedattributeの値を変更できます。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

23.7.3 複雑な検索フィルタのパフォーマンスの最適化

Oracle Internet Directoryは、クライアント・アプリケーションからLDAP検索フィルタを受け取ると、フィルタをSQL問合せとしてOracle Databaseに送信します。クライアント・アプリケーションから送られたフィルタに、ディレクトリ内の多数のエントリと一致する条件が含まれている場合があります。たとえば、次のようなフィルタがあるとします。

(&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE))

このフィルタの条件(objectclass=inetorgperson)および(orclisenabled=TRUE)は、ほとんどすべてのエントリと一致します。Oracle Databaseでのフィルタ全体の実行には非常に多くのリソースが必要になります。パフォーマンスを改善するために、Oracle Internet Directoryがデータベースではなく自身のメモリーでフィルタの一部を実行するよう指定できます。そのためには、DSA構成エントリの属性orclinmemfiltprocessを使用します。

cn=dsaconfig,cn=configsets,cn=oracle internet directory

orclinmemfiltprocessが構成されている場合、Oracle Internet DirectoryがLDAP検索を受け取るたびに、次のイベントが発生します。

1. Oracle Internet Directoryは、SQL問合せを形成する前に、orclinmemfiltprocessに構成されているすべての条件を削除します。

2. Oracle Internet Directoryは、SQL問合せをOracle Databaseに送信します。

3. Oracle Databaseは、SQL問合せの結果のエントリをOracle Internet Directoryに送信します。

4. Oracle Internet Directoryは、クライアントから送信された元のフィルタ(orclinmemfiltprocessの条件)をメモリー内のエントリに適用します。

5. Oracle Internet Directoryは、そのフィルタと一致するエントリをクライアントに送信します。

たとえば、orclinmemfiltprocessが(objectclass=inetorgperson)(orclisenabled=TRUE)に設定されているとします。Oracle Internet Directoryは、検索(&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE))を受け取ると、パラメータ(uid=msmith)のみを含むフィルタをデータベースに送信します。データベースから返されたエントリを受信すると、Oracle Internet Directoryはフィルタ(objectclass=inetorgperson) (orclisenabled=TRUE)をこれらのエントリに適用します。

デフォルトでは、orclinmemfiltprocessは次の値に設定されています。

(objectclass=inetorgperson)

(objectclass=oblixorgperson)

(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=activated))

(|(obuseraccountcontrol=activated)(!(obuseraccountcontrol=*)))

(objectclass=*)

(objectclass=oblixworkflowstepinstance)

(objectclass=oblixworkflowinstance)

(objectclass=orcljaznpermission)

(obapp=groupservcenter)(!(obdynamicparticipantsset=*))

(objectclass=orclfeduserinfo)

ldapmodifyを使用してorclinmemfiltprocessの値を変更できます。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

ある条件下では、Oracle Internet Directoryはorclinmemfiltprocessを無視してフィルタ全体をデータベースに送信します。これが実行されるのは、受信するフィルタが次の条件を満たしている場合です。

- 1つのパラメータ、つまり1つの属性/値ペアのみで構成されていること。

- orclinmemfiltprocessで指定されている条件以外のフィルタ条件がないこと

- orclinmemfiltprocessで指定されている条件に適用されるOR条件があること

- orclinmemfiltprocessで指定されている条件と同じ条件が異なる順序で含まれていること

次の各例でこれらの条件について説明します。次の例ではすべて、orclinmemfiltprocessが(objectclass=inetorgperson)(employeetype=Contract)に設定されています。

例

例A

(&(manager=cn=john doe)(objectclass=inetorgperson) (employeetype=Contract))

Oracle Internet Directoryは、フィルタ(&(manager=cn=john doe))をデータベースに送信します。

例B

(&(uid=rmsmith)((objectclass=inetorgperson)(employeetype=Contract)))

Oracle Internet Directoryは、(&(uid=rmsmith))のみをデータベースに送信し、データベースから返されたエントリにフィルタ(&(objectclass=inetorgperson)(employeetype=Contract))を適用します。

例C

(|(uid=rmsmith)(objectclass=inetorgperson) (employeetype=Contract))

このフィルタでは、orclinmemfiltprocessと一致する条件がOR条件に含まれます。Oracle Internet Directoryは、このフィルタをそのままデータベースに送信します。

例D

(&(uid=rmsmith)(employeetype=Contract) (objectclass=inetorgperson))

このフィルタの条件の一部がorclinmemfiltprocessと一致しても、条件の順序が異なるため、Oracle Internet Directoryはフィルタ全体をデータベースに送信します。Oracle Internet Directoryがこのフィルタをデータベースに送信しないようにするには、orclinmemfiltprocessに(employeetype=Contract)(objectclass=inetorgperson)を追加します。

例E

(|(&(uid=rmsmith)(sn=smith)(objectclass=inetorgperson)(employeetype=Contract))

このフィルタでは、orclinmemfiltprocessと一致する条件がOR条件に含まれます。Oracle Internet Directoryは、このフィルタをそのままデータベースに送信します。

例F

(&(|(uid=rmsmith)(sn=smith))(objectclass=inetorgperson)(employeetype=Contract)))

このフィルタにOR演算子が含まれていても、フィルタはorclinmemfiltprocessと一致する条件に適用されません。Oracle Internet Directoryは、(&(|(uid=rmsmith)(sn=smith)))をディレクトリに送信し、データベースから返されたエントリにフィルタ(&(manager=cn=john doe)(&(objectclass=inetorgperson) (employeetype=Contract))を適用します。

複数のフィルタの構成

アプリケーションが複数のフィルタを送信し、あるフィルタの条件が別のフィルタの条件のスーパーセットである場合は、両方の値に対してorclinmemfiltprocessを構成する必要があります。たとえば、アプリケーションが次の2つのフィルタを送信するとします。

(&(uid=rmsmith)(objectclass=inetorgperson)(employeetype=Contract))

(&(uid=rmsmith)(objectclass=inetorgperson)(employeetype=Contract)(departmentNumber=627))

(departmentNumber=627)は多くのエントリと一致します。orclinmemfiltprocessを次のように構成する必要があります。

(objectclass=inetorgperson)(employeetype=Contract)

(departmentNumber=627)

検索ベースDNのパフォーマンスの最適化

DITでは、cn=users,dc=acme,dc=comなどの1つのベースDNにすべてのユーザーが存在する場合、すべてのLDAP検索クライアントがcn=users,dc=acme,dc=comとしてベースを送信するので、orclinmemfilterの構成でデータベース処理時間が大幅に削減されます。次の例を参照してください。

orclinmemfiltprocess;dn: cn=users,dc=acme,dc=com

23.8 UNIXシステムおよびWindowsシステムでのパフォーマンスの評価

Linux、Solaris、その他のUNIXライクなオペレーティング・システムを使用している場合は、次の各ツールを理解しておくことをお薦めします。

ツール

説明

top

システムでCPUを最も多く消費しているタスクを表示します。

vmstat

Virtual Memory Managerなど、システムの様々な部分の実行統計を示します。

mpstat

vmstatと同様の出力ですが、システム内の各種CPUにわたって分割して示します。これはSolarisでのみ使用可能です。

iostat

各種ディスク・コントローラからのディスクI/O統計を示します。

sar

システムのアクティビティ情報を収集、報告または保存します。

Microsoft Windowsを使用している場合は、次のツールを理解しておくことをお薦めします。

ツール

説明

Windowsパフォーマンス モニター

システム内のイベントのカスタマイズされたビューを表示します。

Windowsタスク マネージャ

システムで実行されている主なタスクの大まかな出力(UNIXのtopと同様)を提供します。

Oracle Databaseを使用する場合は、次のツールを理解しておくことをお薦めします。

- utlbstat.sqlおよびutlestat.sql、またはstatspack

- DBMS_STATSパッケージのANALYZEファンクション

関連項目:

- utlbstat.sqlおよびutlestat.sqlの詳細は、Oracle Databaseドキュメント・ライブラリの『Oracle Databaseリファレンス』を参照してください。

- statsパッケージの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

- DBMS_STATSパッケージのANALYZEファンクションの詳細は、Oracle Databaseドキュメント・ライブラリの『Oracle Database概要』を参照してください。

オペレーティング・システム・ツール以外に、カスタマ環境で使用されているLDAPアプリケーションも待機時間やスループットの測定方法を提供しています。

さらに、様々なデータベースodsスキーマ・オブジェクトを分析して統計を見積るために、$ORACLE_HOME/ldap/adminにあるデータベース統計収集ツール(oidstats.sql)が提供されています。23.10項「oidstats.sqlを使用したデータベース統計の更新」を参照してください。

23.9 チューニングとサイズ設定ウィザードを使用した推奨事項の取得

Oracle Enterprise Manager Fusion Middleware Controlには、Oracle Internet Directoryのチューニングおよびサイズ設定に便利なツールが用意されています。

このウィザードを使用して、システムのチューニングおよびサイズ設定に関する推奨事項を取得します。「チューニング」、「サイズ設定」または「両方」を選択できます。サイズ設定」または「両方」を選択した場合は、「基本」または「拡張」を選択できます。

チューニング

1. 「Oracle Internet Directory」メニューから、「管理」→「チューニングとサイズ設定」を選択します。

2. 「作成」アイコンをクリックしてウィザードを起動します。

3. 「タイプ選択」ページで、レポート名を変更し、「チューニング」を選択します。

4. ウィザードに「ハードウェア」、「機能」、「ロード」、「データ特性」および「ガベージ・コレクション」の各ページが表示されます。
各ページで、テキスト・フィールドに値を指定(またはデフォルト値を使用)し、質問ごとに「はい」または「いいえ」を選択します。一部の選択肢は、前の選択内容に応じてグレーアウトされている場合があります。ほとんどのフィールドには、カーソルをフィールド上に移動すると表示されるツールチップが用意されています。

次のページに進むには「次へ」、前のページに戻るには「戻る」をクリックします。ウィザードを閉じるには、「取消」をクリックします。

5. 「確認」ページで、入力したデータを確認します。指定内容を変更するには「戻る」、レポートを表示するには「終了」をクリックします。

6. レポートは、ページの右下のセクションに表示されます。
レポートをダウンロードするには、「レポートのダウンロード」をクリックします。レポートを削除するには、「削除」をクリックします。

サイズ設定

1. 「Oracle Internet Directory」メニューから、レポート名を変更し、「管理」→「チューニングとサイズ設定」を選択します。

2. 「作成」アイコンをクリックしてウィザードを起動します。

3. 「タイプ選択」ページで、「サイズ設定」を選択します。

4. 「基本」または「拡張」を選択します。

5. 「サイズ設定」ページで、テキスト・フィールドに値を指定(またはデフォルト値を使用)し、質問ごとに「はい」または「いいえ」を選択します。一部の選択肢は、前の選択内容に応じてグレーアウトされている場合があります。

6. 「次へ」をクリックします。

7. 「確認」ページで、入力したデータを確認します。指定内容を変更するには「戻る」、レポートを表示するには「終了」をクリックします。

8. レポートは、ページの右下のセクションに表示されます。
レポートをダウンロードするには、「レポートのダウンロード」をクリックします。レポートを削除するには、「削除」をクリックします。

両方

1. 「Oracle Internet Directory」メニューから、レポート名を変更し、「管理」→「チューニングとサイズ設定」を選択します。

2. 「作成」アイコンをクリックしてウィザードを起動します。

3. 「タイプ選択」ページで、「両方」を選択します。

4. 「基本」または「拡張」を選択します。

5. 「次へ」をクリックします。

6. ウィザードに「サイズ設定」、「ハードウェア」、「機能」、「ロード」、「データ特性」および「ガベージ・コレクション」の各ページが表示されます。
各ページで、テキスト・フィールドに値を指定(またはデフォルト値を使用)し、質問ごとに「はい」または「いいえ」を選択します。一部の選択肢は、前の選択内容に応じてグレーアウトされている場合があります。

次のページに進むには「次へ」、前のページに戻るには「戻る」をクリックします。ウィザードを閉じるには、「取消」をクリックします。

7. 「確認」ページで、入力したデータを確認します。指定内容を変更するには「戻る」、レポートを表示するには「終了」をクリックします。

8. レポートは、ページの右下のセクションに表示されます。
レポートをダウンロードするには、「レポートのダウンロード」をクリックします。レポートを削除するには、「削除」をクリックします。

23.10 oidstats.sqlを使用したデータベース統計の更新

データベース統計が自動的に更新され、OIDMONがデータベースの構成された数の更新ごとにoidstats.sqlを実行します。デフォルトでは、5000エントリが追加されるたびに、OIDMONがoidstats.sqlを実行します。次のようにldapmodifyコマンドを使用して、この頻度を変更できます。

$ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin -w <adminPassword> << eof
dn:  cn=configset,cn=oidmon,cn=subconfigsubentry
changetype: modify
replace: orclstatsperiodicity
orclstatsperiodicity: <desired_number>
eof

関連項目:

『Oracle Fusion Middleware Oracle Identity Managementリファレンス』のoidstats.sqlコマンドライン・ツールのリファレンス

23.11 パフォーマンス関連のレプリケーション構成属性の設定

レプリケーション属性を設定するには、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードまたはコマンドラインを使用します。

属性orclthreadspersupplier、orclchangeretrycountおよびorclconflresolutionは、レプリケーション構成セット属性です。

関連項目:

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のFusion Middleware Controlを使用したレプリケーション属性の構成に関する項

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したレプリケーション構成セット属性の構成に関する項

次の情報については

属性orclhiqscheduleおよびorclupdatescheduleは、レプリケーション承諾エントリ属性です。

関連項目:

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のFusion Middleware Controlレプリケーション・ウィザードを使用したLDAPベースのレプリケーション設定の表示または変更に関する項

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したレプリケーション承諾属性の構成に関する項

関連項目:

- レプリケーション・ウィザードを使用したレプリケーション属性の設定の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の、Fusion Middleware Controlのレプリケーション・ウィザードを使用した一方向、双方向またはマルチマスターLDAPベースのレプリケーション承諾の設定に関する項を参照してください。

- 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したレプリケーション構成セット属性の構成に関する項。

23.12 システム構成属性の管理

ほとんどのパフォーマンス関連のシステム構成属性は、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンドラインから設定できます。Oracle Directory Services Managerのデータ・ブラウザを使用してシステム構成属性を変更することもできます。

Oracle Internet Directoryのシステム構成属性の設定の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「システム構成属性の管理」を参照してください。

- 「Fusion Middleware Controlを使用したシステム構成属性の管理」

- 「WLSTを使用したシステム構成属性の管理」

- 「LDAPツールを使用したシステム構成属性の管理」

- 「ODSMデータ・ブラウザを使用したシステム構成属性の管理」

23.13 ガベージ・コレクション構成属性の設定

属性orclpurgetargetageおよびorclpurgeintervalは、変更ログ・パージ構成エントリにあります。これらは、ldapmodifyまたはOracle Directory Services Managerを使用して変更できます。

23.13.1 ldapmodifyを使用した変更ログ・パージ属性の変更

次の例は、変更ログのパージの構成に使用するLDIFファイルです。

関連項目:

変更ログのパージの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の変更ログのパージに関する項を参照してください。

この例では、120時間(5日)の時間ベースのパージを構成しています。次のようなLDIFファイルを使用します。

dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry
changetype:modify
replace: orclpurgetargetage
orclpurgetargetage: 240

LDIFファイルmod.ldifを適用するには、次のように入力します。

ldapmodify -D "cn=orcladmin" -q -p port -h host -D dn -q -f mod.ldif

関連項目:

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の時間ベースの変更ログのパージの構成に関する項。

23.13.2 Oracle Directory Services Managerでの変更ログのパージの変更

orclpurgetargetageおよびorclpurgeintervalは、Oracle Directory Services Managerのデータ・ブラウザを使用して変更できます。データ・ツリーで変更ログ・パージ構成エントリに直接移動することはできませんが、次のように拡張検索を使用すると可能です。

1. 「データ・ブラウザ」タブで「拡張」をクリックします。

2. 左ペインで「ガベージ・コレクション」を展開し、「changelog purgeconfig」を選択します。ガベージ・コレクタ・ウィンドウが右ペインに表示されます。

3. 右ペインで、パージのターゲット期間およびパージの間隔に加える変更を入力します。

4. 「適用」を選択します。

24 Oracle Virtual Directoryのパフォーマンス・チューニング

この章では、Oracle Virtual Directoryのチューニングのヒントを示します。内容は次のとおりです。

- 24.1項「Oracle Virtual Directoryについて」

- 24.2項「チューニングに関する基本的な考慮事項」

- 24.3項「拡張構成」

24.1 Oracle Virtual Directoryについて

Oracle Virtual DirectoryはLDAPバージョン3対応のサービスです。これを使用すると、1つ以上の企業データ・ソースを抽象化したビューが得られます。Oracle Virtual Directoryでは、複数のデータ・ソースが単一のディレクトリ・ビューに一体化されます。そのため、LDAP対応のアプリケーションを様々なディレクトリ・サーバー・データ・ストアと統合できます。

この章の内容は、読者が『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』の概念および管理についての情報に目を通しているものと想定して書かれています。

注意:

Oracle Virtual Directoryのデフォルト構成は、多くの本番用デプロイメントおよびテスト用デプロイメントにとって最適なものではありません。最適なパフォーマンスおよび可用性を得るために、「基本的なチューニング構成」に示す推奨事項を実施することをお薦めします。

24.2 チューニングに関する基本的な考慮事項

この項のチューニングの考慮事項は、ほとんどのデプロイメントおよび使用状況に当てはまります。各構成を検討し、各自のユースケース・シナリオに適したものを実装することを強くお薦めします。チューニングの内容は、表24-1にまとめてあります。

- opmn.xmlファイルのping間隔を60秒(必要に応じてそれ以上)に増やします。
システムがビジー状態の場合、Oracle Process Manager and Notification Server(OPMN)からOracle Virtual Directoryへのpingに失敗する可能性があります。その結果、OPMNが20秒後(デフォルトのping間隔)にOracle Virtual Directoryを再起動します。この問題を回避するには、ping間隔を60秒以上に増やすことを検討してください。

次に示すように、$ORACLE_INSTANCE/config/OPMN/opmn/opmn.xmlでping間隔を変更できます。

<process-type id="OVD" module-id="OVD">
<module-data>
<category id="start-options">
<data id="java-bin" value="$ORACLE_HOME/jdk/bin/java"/>
<data id="java-options" value="-server -Xms2056m -Xmx2056m                               -Dvde.soTimeoutBackend=0  -DdisableECID=1  -Didm.oracle.home=$ORACLE_HOME                               -Dcommon.components.home=$ORACLE_HOME/../oracle_common                               -Doracle.security.jps.config=$ORACLE_INSTANCE/config/JPS/jps-config-jse.xml"/>
<data id="java-classpath" value="$ORACLE_HOME/ovd/jlib/vde.jar$:$ORACLE_HOME/jdbc/lib/ojdbc6.jar"/>
</category>
</module-data>
<stop timeout="120"/>
<ping interval="60"/>
</process-type>

- Oracle Virtual Directory Serverがシステムで使用できる中央処理装置(CPU)の数に基づいて、ワーカー・スレッドの数をチューニングします。
Oracle Virtual Directoryリスナー設定のThreads構成パラメータを適切な値に設定してください。管理ゲートウェイ・リスナーおよびDSMLゲートウェイ・リスナーの場合、Threadsのデフォルト値は最適であり、変更の必要はないのが一般的です。LDAPリスナーのThreadsの値は通常、チューニングする必要があります。これは、LDAPリスナーがアプリケーションからの同時トラフィックを受け入れるためです。一般的な構成は、1 CPU当たり10スレッドです。たとえば、システムに中央処理装置が4つある場合、スレッドの数は40になります。

詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のリスナーの管理に関する項を参照してください。

- 特定のLDAPリスナーに対して予想される同時クライアントの最大数に基づいて、ワーク・キューの容量をチューニングします。
Oracle Virtual Directoryリスナー設定のWorkQueueCapacity構成パラメータを適切な値に設定してください。そうすることで、LDAPクライアントからの接続リクエストがワーク・キューの容量不足で拒否されることはなくなります。作業用の要素はオンデマンドでのみ割り当てられるため、実際の見積りより大きい値を使用できます。

Fusion Middleware Controlパフォーマンス・モニターには、最大接続数を含む履歴レポートが表示されます。このレポートを使用して、本番データに基づいた接続値の調整方法を決定します。

Oracle Virtual Directoryで多くの同時クライアントをサポートする必要がある場合、ulimitの「ファイルなし」(記述子)パラメータを予想されるLDAPクライアントの数に設定します。たとえば、OPMNが起動するコマンド・ウィンドウでは、8000の同時クライアントが予想される場合に次のulimitを設定します。

ulimit -n 8192

この変更を有効にするには、OPMNおよびOracle Virtual Directoryを再起動する必要があります。

詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のリスナーの管理に関する項を参照してください。

- Oracle Virtual Directory LDAPアダプタのLDAP接続プールのサイズをチューニングし、LDAPアダプタを使用するアクティブなOracle Virtual Directoryリスナーに構成されているスレッドの総数以上になるようにします。
こうすれば、リクエストを処理するのに十分なLDAP接続をワーカー・スレッドに持たせることができます。アクティブなアダプタおよびリスナーの実際の数、ならびにトラフィックのパターンは、接続の使用状況を左右します。ただし、LDAPアダプタ接続プール内のアイドル接続は定期的にクローズされるため、大きな値を指定してもパフォーマンスに影響が出ることはありません。バックエンドのディレクトリ・サーバーが、Oracle Virtual Directory LDAPアダプタ接続プールの同時接続数を処理できるよう構成されていることを確認してください。

詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のLDAPアダプタの構成に関する項を参照してください。

- Oracle Virtual Directoryを実行しているJVMの最大Javaヒープ・サイズをチューニングします。これは、同時負荷を処理するのに十分なヒープをOracle Virtual Directoryに持たせるために行います。
詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のOracle Virtual Directoryサーバーに割り当てられた最大ヒープ・サイズの制御に関する項を参照してください。

表24-1 基本的なチューニング構成

構成属性

カテゴリ

デフォルト値

推奨値

注意

スレッド

リスナー・プロパティ

10

10 * Oracle Virtual Directoryサーバーが使用できる中央処理装置(CPU)の数

推奨値が当てはまるのは、アクティブなLDAPリスナーのみです。

ワーク・キューの容量

リスナー・プロパティ

2048

予想される最大同時クライアント数 * 2

2048の操作が同時に実行されます。一部のクライアントで非同期操作を送信する場合もあります。

最大の初期プール接続

LDAPアダプタ・プロパティ

10

このアダプタを使用するすべてのアクティブ・リスナーのThreadsパラメータの値の合計

バックエンドのディレクトリ・サーバーが、ここに指定した数の接続を処理できることを確認してください。

最大ヒープ・サイズ

システム・プロパティ

256MB

32ビットのシステムでは最大2GB、64ビットのシステムではそれ以上の値を指定できます。

値を大きくすると、メモリー不足エラーの発生を防ぐことができます。構成した値を処理するのに十分なRAMがシステムにあることを確認してください。

24.3 拡張チューニング構成

Oracle Virtual Directoryデプロイメントのユースケース・シナリオによっては、次のチューニング構成を行うとパフォーマンスが向上することがあります。

24.3.1 データベース・アダプタ

データベース・アダプタは、あらゆる機能を備えたLDAPからJDBCへのゲートウェイで、すべてのLDAP操作(add、bind、delete、baseSearch、modify、wildCardSearch)を、プリコンパイルされた同等のSQL文コードに変換するトランスレーションをサポートしています。データベース・アダプタは、JDBCクラス・ライブラリを使用して、LDAP検索を実行するためのデータベース接続を形成します。一般に、データベース・ライブラリはデータベース・ベンダーから提供されます。

注意:

パフォーマンスを改善するため、データベース・アダプタを使用する前にデータベースをチューニングします。詳細は、データベースのドキュメントを参照してください。使用しているデータベースがOracleデータベースの場合は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

最適なパフォーマンスを得るために、Oracle Virtual Directoryデータベース・アダプタの構成対象となるデータベース・スキーマについて、次の構成オプションを検討してください。

- 一般に、マップされたLDAP属性をLDAP検索フィルタで使用する場合は、基礎となるデータベース・スキーマのマップされた列に索引を定義します。

- LDAP検索フィルタで使用するLDAP属性に、caseIgnoreMatchの一致するルールがある場合、参照のパフォーマンスを最適化するには、この属性にマップされたデータベース表の列にファンクション索引を定義する必要があります。
たとえば、LDAP属性CNがデータベース・スキーマ列EMP.NAMEにマップされている場合、CN属性を含むLDAP検索フィルタのパフォーマンスを最適化するには、UPPER(EMP.NAME)にファンクション索引が必要です。

ファンクションベースの索引の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のパフォーマンスを考慮したファンクション索引の使用方法に関する項を参照してください。

表24-2に、その他のデータベース・アダプタ設定を示します。

表24-2 データベース・アダプタ設定

パラメータ

値

注意

アダプタ

デフォルト: アクティブ

アダプタは、アクティブまたは非アクティブとして構成できます。サーバーの再起動中またはサーバーの起動時に非アクティブなアダプタを起動することはできません。「非アクティブ」設定の目的は、古い構成設定を構成から削除せずに使用可能な状態(スタンバイ状態)にしておくことです。

最大接続数

デフォルト: 10接続

このプロパティでは、データベース・アダプタがデータベースとの間に作成できる接続の最大数を定義します。

データベース接続タイムアウト

デフォルト: 10秒

アダプタのデータベース接続タイムアウト・プロパティは、最大接続数の制限に達した後、キャッシュ内で接続が使用可能になるのを待つLDAPリクエストを制御します。

定義した秒数以内に接続が使用可能にならなければ、LDAPリクエストは失敗します。データベース接続タイムアウト・システム・プロパティを使用しない場合、LDAPリクエストは接続が使用可能になるのを10秒間待ちます。

24.3.2 結合アダプタ

結合アダプタを使用する場合は、適切なソースのみを結合します。たとえば、プライマリ・ソースのcn=usersブランチにある属性のみをリンクする必要がある場合、このブランチのみを公開するプライマリ・アダプタを作成します。次に、そのアダプタを使用した結合ルールを作成します。こうすることで、対応するリンク先エントリが存在しない可能性のあるエントリの結合を試みる必要性が減ります。

ヒント:

結合ルールで使用する属性が正しく索引付けされていることを必ず確認してください。

24.3.3 フィルタの一般的なチューニング

既知のクライアント検索フィルタが特定のアダプタに該当しない場合、そのフィルタをすべての適用可能な対象外フィルタに適用すると、パフォーマンスが向上するとともに、ネットワーク・トラフィックが減少します。

24.3.4 ロード・バランサのローカル・ストア・アダプタのチューニング

ロード・バランサの中には、LDAPサーバーが稼働しているか停止しているかをそのサーバーに問い合せて判断するものがあります。ロード・バランサがこの機能を使用している場合は、独立したネームスペース(dc=loadbalancerなど)を持つローカル・ストア・アダプタを作成して、ロード・バランサ専用とすることを検討してください。おそらくロード・バランサがパフォーマンスに与える影響は目に見えるほどではありませんが、ロード・バランサを独立したネームスペース内に保持することで、トラブルシューティング時にロード・バランサのKeepAliveリクエストによって大きなログ・ファイルが作成されるのを防ぎやすくなります。

24.3.5 Cacheプラグインのチューニング

Cacheプラグインは、Oracle Virtual Directoryにメモリー内キャッシュを提供します。あらゆるソースからの問合せ結果をキャッシュして、LDAPクライアントが再利用できるようにする機能を持ちます。このプラグインを使用すると、問合せが何度も繰り返されるアプリケーションのパフォーマンスを改善できます。

キャッシュの操作および構成を確認するには、VEロギング・レベルを「ダンプ」に設定して詳細を参照します。キャッシュは通常のプラグインであるため、Oracle Virtual Directory内の任意の場所で実行するように構成できます。グローバルに実行することも、単一アダプタのコンテキスト内で実行することも可能です。また、標準のプラグイン構成に用意されているネームスペース・フィルタ処理を使用して、キャッシュを特定のネームスペースに制限することもできます。

24.3.5.1 キャッシュ・ヒット・ロジック

キャッシュは、問合せ結果を格納して、後で使用できるようにする機能を持ちます。問合せが同じユーザーによって繰り返され、同一の属性または属性のサブセットがリクエストされる場合、Oracle Virtual Directoryがソースから情報を取得するのではなく、キャッシュから問合せの結果が返されます。キャッシュ・ヒットをユーザー間で共有するようプラグインを構成することもできます。

パス資格証明がバックエンド・ソースに渡されず、Oracle Virtual Directoryのみによってセキュリティが実施されている場合以外は、ユーザー間でキャッシュ・エントリを共有しないでください。ユーザー間でキャッシュ・ヒットを共有する場合は、より強力な権限を持つユーザーのキャッシュ結果に他のユーザーがアクセスして、見てはならない情報を目にしてしまう可能性もあるため、十分に注意する必要があります。

24.3.5.2 Cacheプラグインのメモリー管理

このプラグインは、キャッシュを定期的に確認し、期限切れの結果や以前の変更トランザクションで無効にされたエントリがないかどうかチェックします。キャッシュの割当て制限を超えた場合は、使用頻度が最も低い(LRU)問合せをパージしてメモリーのサイズを小さくします。

表24-3に、メモリー管理プラグインのチューニングに使用するパラメータを示します。

表24-3 メモリー管理プラグインの設定

パラメータ

値

注意

Size

デフォルト: 1000エントリ

一度にキャッシュ可能なエントリの最大数。

MaxResultSize

デフォルト: 1000エントリ

特定の問合せに対してキャッシュ可能なエントリの最大数。

Trimsize

デフォルト: 1000エントリ

最大キャッシュ・サイズを超えたときに、キャッシュ・マネージャがその時点のエントリ数から減らす量。注意: 必要に応じて、まず期限切れの問合せをパージし、次に使用頻度の最も低い問合せから順にパージすることで、切り捨てが実行されます。

MaximumAge

デフォルト: 600秒

キャッシュに格納される問合せ/エントリの最大有効期間(秒)。

MaintenanceInterval

デフォルト: 60秒

キャッシュ・マネージャが期限切れの問合せの有無をチェックする間隔(秒)。

BySubject

デフォルト: 1(共有しない)

キャッシュ結果をサブジェクト間で共有するかどうかを示すフラグ(1または0)。値1は、結果をサブジェクト間で共有しないことを示します。

24.3.6 LDAPリスナーのチューニング

表24-4に、LDAPリスナーのチューニングに使用するパラメータを示します。

表24-4 リスナー・パラメータ

パラメータ

値

注意

バックログ

デフォルト: 128リクエスト

サーバーが新規接続の試行を拒否し始めるまでキューにためることのできる、保留中の接続リクエストの最大数を指定します。

ほとんどの場合、デフォルト値で十分です。この値の変更が必要になることはほとんどありません。

アドレスの再利用

デフォルト: False

このオプションにより、LDAPリスナーがソケット・ディスクリプタを再利用するかどうかを決定します。

有効にすると、Oracle Virtual Directoryサーバーのリスン・ソケットでSO_REUSEADDRソケット・オプションが使用され、TIME_WAIT状態のクライアントのソケット・ディスクリプタを再利用できるようになります。

キープ・アライブ

デフォルト: False

このオプションにより、LDAP接続でTCPキープ・アライブを使用するかどうかを決定します。

有効にすると、SO_KEEPALIVEソケット・オプションが使用されます。これは、関連付けられた接続がまだ有効であることを確認するためにTCPキープ・アライブ・メッセージが定期的にクライアントに送信されることを示します。

TCP遅延なし

デフォルト: True

このオプションにより、LDAP接続でTCP遅延なしを使用するかどうかを決定します。

有効にすると、TCP_NODELAYソケット・オプションが使用されます。この場合、クライアントへのレスポンス・メッセージは、追加のレスポンス・メッセージを同一のパケットで送信できるかどうかの判断を待たずに、即座に送信されます。

読取りタイムアウト

デフォルト: 0

このオプションにより、指定されたタイムアウト(ミリ秒)でSO_TIMEOUTを有効または無効にします。

このオプションをゼロ以外のタイムアウトに設定すると、Oracle Virtual Directoryサーバーへのクライアント接続は、その時間のみアイドル状態を維持できます。接続のアイドル期間が指定されたタイムアウトを超えると、クライアント接続は終了します。

ゼロのタイムアウトは無限タイムアウトとみなされます。

警告: このオプションは、Oracle Virtual Directoryバージョン10gのvde.soTimeoutFrontendシステム・プロパティに相当します。vde.soTimeoutFrontendシステム・プロパティは11gではサポートされていません。ユーザーは、システム・プロパティに指定した値を変更する必要があります。

10gから11gへの値のマッピングは次のとおりです。「有効」=0

「無効」=ゼロ以外の時間(ミリ秒)

24.3.7 サーバーのチューニング

表24-5に、サーバーのチューニングに使用する基本的なパラメータを示します。

表24-5 サーバー・パラメータ

パラメータ

値

注意

匿名検索制限

デフォルト: 1000

匿名クライアントに対して返すエントリの最大数。

接続タイムアウト

デフォルト: 120(分)

「接続タイムアウト」システム・プロパティは、正しく接続をクローズしないクライアントが原因でサービスが停止するのを防ぐために使用します。値は、Oracle Enterprise Managerの「サーバー・プロパティ」ページで設定できます。

警告: 0に設定すると、接続タイムアウトの実施は無効化され、非アクティブの期間に関係なくクライアント接続をクローズできなくなります。このシステム・プロパティは、割当て制限から除外された、または割当て制限を実施できないIPアドレスおよびサブジェクトには適用されません。

ロギング・レベル

デフォルト: Error:1(Severe)

デフォルトでは、ロギングがNOTIFICATION:1に設定されている場合にのみ、ログ・メッセージがaccess.logファイルに書き込まれます。パフォーマンスを確保するために、デフォルトのログ・レベルをそのまま使用するか、WARNING:1(WARNING)を使用して、access.logファイルに書き込まれる情報の量を制限することを検討してください。

25 Oracle Identity Federationのパフォーマンス・チューニング

Oracle Identity Federationは、複数ドメインからなるアイデンティティ・ネットワークでのシングル・サインオンおよび認証を可能にする、スタンドアロンの自己完結型フェデレーション・サーバーです。内容は次のとおりです。

- 25.1項「Oracle Identity Federationについて」

- 25.2項「LDAPのチューニング」

- 25.3項「データベースのチューニング」

- 25.4項「Oracle HTTP Serverのチューニング」

- 25.5項「SAMLプロトコルのチューニング」

注意:

この章で説明する構成例および推奨設定は解説用のものです。各自のユースケース・シナリオを検討し、パフォーマンスの向上が可能な構成オプションを判断してください。

25.1 Oracle Identity Federationについて

Oracle Identity Federationは、複数ドメインからなるアイデンティティ・ネットワークでのシングル・サインオン(SSO)および認証を可能にする、スタンドアロンの自己完結型フェデレーション・サーバーです。フェデレーション・シングル・サインオン機能は、SAML 1.x/SAML 2.0/WS-Fedプロトコルをベースとしています。サーバーは、WebLogic管理対象サーバーにデプロイされたJava EEアプリケーションです。そのため、ソリューション・セットに含まれる他のOracle Identity Management製品を実装しているかどうかにかかわらず、異機種環境や異業種提携におけるフェデレーションが可能になります。

詳細は、Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドを参照してください。

25.2 LDAPのチューニング

この項では、LDAPのチューニングに使用できる次の構成設定について説明します。

- 接続プール設定

- 接続設定

- フェデレーション・データ・ストア設定

最適なパフォーマンスを得るため、Oracle Identity Federationのチューニングを行う前に、第2章「主なパフォーマンス分野」でチューニング構成を確認してください。

25.2.1 接続プール設定

Oracle Identity Federationがユーザー・データ・ストア、フェデレーション・データ・ストアまたは認証エンジンとしてLDAPサーバーと統合されている場合、サーバーは後続のリクエストで再利用可能なLDAP接続のプールを保持します。

Oracle Identity Federationは、LDAPサーバーに対して次の種類の操作を実行します。

1. ユーザー・データ・ストア

- アサーション・マッピング中のユーザーの検索

- アサーション作成時にユーザー・レコードから属性を取得

2. 認証エンジン

- ユーザーの検索

- 認証操作中のユーザー資格証明の検証

3. フェデレーション・データ・ストア(使用する場合)

- フェデレーション・レコードの作成

- フェデレーション・レコードの検索

- フェデレーション・レコードの更新または削除。LDAP接続プールは次の方法で構成できます。

- 最大接続数を指定します。これは、プールに保持できるLDAP接続の数を示します。

- 接続待機タイムアウトを設定します。これは、プールに使用可能なLDAP接続がなく、プールが最大容量に達している場合に、スレッドがLDAP接続の取得を再試行するまで待機する時間です。

ユーザー・ストア、フェデレーション・ストア、およびLDAP認証エンジンの詳細は、Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのOracle Identity Federationの構成に関する項を参照してください。

25.2.2 接続設定

Oracle Identity Federationがユーザー・データ・ストア、フェデレーション・データ・ストアまたは認証エンジンとしてLDAPサーバーと統合されている場合、LDAPランタイム接続を構成できます。詳細は、Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのOracle Identity Federationの構成に関する項を参照してください。

LDAP接続を構成するには次の方法があります。

- LDAP非アクティブ時間を設定します。これにより、LDAP接続がアクティブでないために削除されるまでプールに保持しておく期間をOracle Identity Federationに指示します。長期的には、非アクティブの状態が長く続いたためにLDAPサーバーが接続をクローズすることがあります。チェックしないままだと、これがエラーの原因となり、Oracle Identity Federationのパフォーマンスに影響を与える可能性があります。
Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのLDAP非アクティブ設定の構成に関する項を参照してください。

- LDAP読取りタイムアウトを設定します。LDAPサーバーは応答しなくなることがありますが、その場合、スレッド/ユーザーはレスポンスまたはエラーを待つことになります。サーバーが応答していないときにエラーを長時間待つことがないよう、Oracle Identity FederationでLDAP接続に対する読取りタイムアウト・プロパティを設定します。読取りタイムアウトの時間内にLDAPサーバーが応答しない場合は、エラーが生成されます。Oracle Identity Federationは、接続をクローズし、新しい接続をオープンして、LDAPコマンドを再発行します。
Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのLDAP読取りタイムアウト設定の構成に関する項を参照してください。

- 高可用性(HA)LDAPフラグを設定します。Oracle Identity FederationがHAモードでデプロイされたLDAPサーバーと統合されている場合、Oracle Identity Federationの構成の際に、LDAPサーバーがHAモードであることを指定する必要があります。
Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドの高可用性LDAPサーバーの構成に関する項を参照してください。

25.2.3 フェデレーション・データ・ストア設定

Oracle Internet Directoryをフェデレーション・データ・ストアとして使用する場合、Oracle Identity Federationは、アカウント・リンク情報を含むフェデレーション・レコードの作成、検索、更新および削除を行います。

Oracle Identity Federationは、Oracle Internet Directoryとやり取りする際に特定の問合せを使用するため、Oracle Internet Directoryでフィルタを作成するとパフォーマンスが向上します。Oracle Internet Directoryをフェデレーション・データ・ストアとして使用する場合は、LDAPサーバーをチューニングして、参照操作のパフォーマンスを高めることができます。Oracle Identity Federationサーバーは、フェデレーション・ストアを使用してフェデレーテッド・アイデンティティ・レコードを保存するように構成できます。

フェデレーション・サーバーは、このストアを使用して次の操作を行います。

- 様々な問合せによるフェデレーション・レコードの参照

- フェデレーション・レコードの作成

- フェデレーションの削除

デフォルトで用意されているOracle Identity Federation関連のorclinmemfiltprocessフィルタ(objectclass=orclfeduserinfo)に加えて、一部のOracle Identity Federation環境では次の形式のフィルタも有効なことがあります。

(orclfedserverid=local_oif_server_id)

(orclfedproviderid=providerid_of_remote_server)

(orclfedfederationtype=n)

orclfedserveridは、問合せを作成しているOracle Identity Federationサーバーを表します。orclfedprovideridは、リモートSAMLサーバーの識別子です。orclfedfederationtypeは、1または3です。Oracle Identity Federationがアイデンティティ・プロバイダであり、リモート・プロバイダがサービス・プロバイダである場合は、orclfedfederationtypeの値として1を使用します。Oracle Identity Federationがサービス・プロバイダであり、リモート・プロバイダがアイデンティティ・プロバイダである場合は、3を使用します。

多くのリモートSAMLサーバーと連携するようにデプロイメントを構成できるため、orclfedprovideridフィルタおよびorclfedfederationtypeフィルタが複数存在する場合もあります。

例:

(orclfedserverid=my_oif_server)

(orclfedproviderid=http://server.example.com:7499/fed/idp)

(orclfedproviderid=http://server2.example.com:7492/fed/idp)

(orclfedfederationtype=1)

(orclfedfederationtype=3)

25.3 データベースのチューニング

この項では、データベースのチューニングに使用できる構成設定について説明します。

Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドの追加のRDBMS構成に関する項を参照してください。

25.3.1 データ・ソース

Oracle Identity Federationは、次のような各種操作を実行する際に、Java EEデータ・ソースを使用してデータベースとやり取りします。

- ユーザー・データ・ストア内のユーザー・レコードの検索

- ユーザー・データ・ストア内のユーザー・レコードの属性の取得

- フェデレーション・データ・ストア内のOracle Identity Federationレコードの検索、作成または削除

- セッション・データ・ストアまたはメッセージ・データ・ストア内のOracle Identity Federation一時レコードの検索、作成または削除。(一時レコードは、ユーザー・セッション、アーティファクト・レコード、フェデレーション・プロトコル、セッション状態のいずれかです。)

Oracle Identity Federationで使用可能なデータ・ソースをOracle WebLogic管理コンソールで作成する際に、パフォーマンスが向上するよう、最大および最小の接続設定をチューニングする必要があります。各自のユースケース・シナリオを検討し、アプリケーションのパフォーマンス向上が可能な接続設定を判断してください。

25.3.2 RDBMSのセッション・キャッシュ

Oracle Identity Federationがセッション・データ・ストアとして使用するRDBMSと統合されている場合、サーバーは実行時のパフォーマンスを高めるためにキャッシュ・メカニズムを使用します。これにより、最近使用したセッション・オブジェクトへの参照をメモリー内に保持できるため、データベースへの読取りアクセスが不要になります。

RDBMSのセッション・キャッシュを最適化するには、次の項目を構成します。

- 同時にメモリーに保持されるセッション・オブジェクトの数

- 特定のセッション・オブジェクトがメモリーに保持される時間

注意:

Oracle Identity Federationがロード・バランサを使用した高可用性(HA)モードの場合、常に正確なデータがキャッシュに反映されるように、スティッキー・セッションを有効にする必要があります。

Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのRDBMSセッション・キャッシュの構成に関する項を参照してください。

25.3.3 RDBMSの圧縮

RDBMSに格納されるデータの量を減らすために、Oracle Identity Federationはデータを圧縮してからデータベースに格納する機能を備えています。圧縮可能なデータには次の3種類があります。

- SSOアーティファクト・プロファイルのAuthnRequest: Oracle Identity FederationがLiberty 1.xプロトコルのIdPとして機能する場合、サーバーは、アーティファクト・プロファイルが使用されたときに、AuthnRequestメッセージをRDBMSに格納します。

- SSOアーティファクト・プロファイルのアサーション・レスポンス: Oracle Identity FederationがSSOプロトコルのIdPとして機能する場合、サーバーは、アーティファクト・プロファイルが使用されたときに、アサーションを含むレスポンス・メッセージをRDBMSに格納します。アサーションに属性が含まれている場合は、これを有効にする必要があります。

- ユーザー・セッション・データ: Oracle Identity Federationは、実行時にユーザー関連のセッション・データを格納します。(カスタム認証エンジンで設定されているか、Oracle Identity Federationがサービス・プロバイダであったときに属性アサーション・ストレージが有効になっていたために)複数の属性がユーザー・セッションに格納される場合、圧縮を使用する必要があります。

Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのRDBMSデータ圧縮の構成に関する項を参照してください。

25.4 Oracle HTTP Serverのチューニング

Oracle Identity FederationがOracle HTTP Server(OHS)を介して動作する場合、HTTP Serverの構成をチューニングすることでパフォーマンスを改善できます。Oracle HTTP Serverの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』を参照してください。

OHSのhttpd.confファイルにある次のパラメータを変更できます。その他のOracle HTTPチューニング構成については、第5章「Oracle HTTP Serverのパフォーマンス・チューニング」を参照してください。各自のユースケース・シナリオを検討し、どのような設定が適切であるかを判断してください。

- Timeout

- KeepAlive

- MaxKeepAliveRequests

- KeepAlive TimeOut

- MinSpareServers

- MaxSpareServers

- StartServers

- MaxClients

- MaxRequestPerChild

これらのパラメータを変更した後、OHMを保存して再起動します。

25.5 SAMLプロトコルのチューニング

Security Assertion Markup Language(SAML)プロトコルは、Simple Object Access Protocol(SOAP)を使用したリモート・サーバーとのやり取りを必要とします。

25.5.1 SOAP接続

Oracle Identity Federationサーバーは、SAMLリクエストの送信およびSAMLレスポンスの受信にSOAPプロトコルを使用します。

パフォーマンスを最適化するには、次のSOAP接続を構成します。

- Oracle Identity Federationが同時にオープンできるSOAP接続の合計最大数

- Oracle Identity Federationが特定のリモート・サーバーに対して同時にオープンできるSOAP接続の最大数

詳細は、Oracle Fusion Middleware Oracle Identity Federationの管理者ガイドのSOAPバインディングに関する項を参照してください。

25.5.2 XMLデジタル署名

Oracle Identity FederationのSAMLプロトコルおよびWS-Fedプロトコルでは、メッセージの真正性、およびメッセージが改ざんされていないことを保証するために、XMLデジタル署名を使用します。

可能であれば、アサーションまたはレスポンス(あるいはその両方)に署名して、変更が加えられるのを防止してください。メッセージにXMLデジタル署名がない場合、アーカイブされる監査済メッセージには、メッセージの真正性および整合性を証明するデータは含まれません。

次の場合は、アサーションまたはレスポンス(あるいはその両方)に署名しないようにOracle Identity Federationを構成するほうがよいことがあります。

- パフォーマンスを改善する必要がある場合

- SOAP通信に対してSSL認証を行うSSLが有効になっている場合

- XMLデジタル署名を無効にすることが企業のセキュリティ規定に合致している場合

注意:

SAML 2暗号化が使用されている場合を除き、暗号化アサーションの内容は参照可能です。アサーションの暗号化はオプションですが、XML暗号化はリソース消費量が多く、パフォーマンス低下の原因となります。

25.5.3 シングル・サインオンのPOSTプロファイルおよびアーティファクト・プロファイル

SAML仕様で定義されたシングル・サインオン・プロファイルには次の2種類があります。

- POSTプロファイル
POSTプロファイルでは、アサーションはユーザーのブラウザを介して遷移します。したがって、アサーションまたはレスポンス(あるいはその両方)に署名して、内容が変更されていないことを保証する必要があります。

注意:

パフォーマンスを改善する必要があり、かつPOSTプロファイルの使用が企業のセキュリティ規定に合致しているのであれば、POSTプロファイルを使用するようにOracle Identity Federationを構成することがパフォーマンス改善の方法となる場合もあります。

- アーティファクト・プロファイル
アーティファクト・プロファイルでは、アイデンティティ・プロバイダがIdPのローカル・ストア内のアサーションを参照するランダムな識別子を作成します。(アサーションは、アイデンティティ・プロバイダからサービス・プロバイダへ直接提供されます。)この識別子は、ユーザーのブラウザを介してサービス・プロバイダに提示されます。サービス・プロバイダは、アイデンティティ・プロバイダにアクセスして識別子の参照を解除し、対応するアサーションを取得します。

SPからIdPへのSOAP接続が、SSLサーバー証明書を使用したSSLプロトコルで暗号化されている場合、SPはIdPを認証し、通信内容が改ざんされていないことを証明します。この場合は、トランスポート層でメッセージの真正性および整合性を実現しているため、SAMLのレスポンスおよびアサーションに対するXMLデジタル署名はオプションです。

メッセージにXMLデジタル署名がない場合、アーカイブされる監査済メッセージには、メッセージの真正性および整合性を証明するデータは含まれません。

注意:

アーティファクト・プロファイルを使用すると、サービス・プロバイダとアイデンティティ・プロバイダの間で余分な通信フローが発生するため、パフォーマンスが低下する可能性があります。

26 Oracle Fusion Middlewareセキュリティのパフォーマンス・チューニング

Oracle Fusion Middlewareセキュリティ・サービスを使用すると、重要なアプリケーションや機密データを保護できます。この章では、セキュリティ・サービスを構成して最適なパフォーマンスを得る方法について説明します。

この章の内容は次のとおりです。

- 26.1項「セキュリティ・サービスについて」

- 26.2項「一般的なパフォーマンスの問題の検出」

- 26.3項「Oracle Platform Security Servicesのチューニング」

- 26.4項「Oracle Web Services Securityのチューニング」

26.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セキュリティ・サービスの概念および管理についての情報に目を通し、理解しているものと想定して書かれています。セキュリティ・パラメータをチューニングする前に、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』を参照し、詳細を確認してください。

26.2 一般的なパフォーマンスの問題の検出

この項では、パフォーマンス・ボトルネックの特定方法、およびパフォーマンス・ボトルネックなどの問題の解決方法に関して、一般的なガイドラインを示します。

パフォーマンス・ボトルネックを発見するには、まずWebサービスのデプロイメント全体で予想されるトラフィック負荷に対応できていることを確認します。CPU使用率が100%に達しているシステムがクリティカル・パスにある場合は、1台以上のコンピュータをクラスタに追加する必要があります。

デプロイメントにボトルネックが存在する場合、その発生箇所はおそらく次のいずれかです。

- エージェントとの低速な接続を介したトラフィック

- JMSのようなサード・パーティのキューイング・システムへの接続待機時間

どちらの問題についても、次の原因を確認します。

- 外部リソース(特に次のタイプ)への接続を含むポリシー・アサーションの問題

- データベース・リポジトリ

- LDAPリポジトリ

- セキュア・リソース

- 独自のセキュリティ・システム

- データベース・パフォーマンスの問題

これらのいずれかがボトルネックの原因であると判明した場合は、データベースまたはLDAP接続の管理方法、あるいはリソースの保護方法を変更する必要があります。

26.3 Oracle Platform Security Servicesのチューニング

この項では、Oracle Platform Security Services(OPSS)における次の基本的なチューニング構成について説明します。

- JVMチューニング・パラメータ

- LDAPチューニング・パラメータ

- 認証チューニング・パラメータ

- 認可チューニング・プロパティ

- OPSS PDPサービス・チューニング・パラメータ

26.3.1 JVMチューニング・パラメータ

JVMパラメータをチューニングすると、パフォーマンスが大幅に向上します。たとえば、JVMヒープ・サイズはストア内のロールおよび権限の数に応じてチューニングする必要があります。実行時には、ロールおよび権限はすべてメモリー内キャッシュに格納されます。JVMチューニングの詳細は、2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。

26.3.2 LDAPチューニング・パラメータ

この項では、Lightweight Directory Access Protocol(LDAP)のチューニングについて説明します。Oracleは、ファイルベースのリポジトリであるOracle Internet DirectoryおよびOracle Virtual Directoryでのポリシーの管理をサポートしています。

SQLの実行に時間がかかるためにCPU使用率が上昇している場合は、次の章を参照し、大規模デプロイメント向けの基本的なチューニング構成を確認してください。

- Oracle Internet Directoryの構成設定はパフォーマンスに影響を与えることがあります。詳細は、第23章「Oracle Internet Directoryのパフォーマンス・チューニング」を参照してください。

- Oracle Virtual Directoryは、LDAPサーバーとしてだけでなく、ローカル・ストレージ・アダプタ(LSA)として構成することもできます。第24章「Oracle Virtual Directoryのパフォーマンス・チューニング」を参照してください。

26.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)を参照してください。

26.3.4 認可チューニング・プロパティ

次のJavaシステム・プロパティを使用して、認可を最適化できます。

表26-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に委任します。

26.3.5 OPSS PDPサービス・チューニング・パラメータ

表26-2に、ポリシー・ストアのOPSSチューニング・パラメータを示します。

表26-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に設定します。

26.4 Oracle Web Services Securityのチューニング

Oracle Web Services Securityは、XMLベースのメッセージを使用してWebサービスとやり取りするための認可および認証のフレームワークを提供します。この項では、Webサービスのパフォーマンスに影響を与える要因について説明します。

- 適切なポリシーの選択

- ポリシー・マネージャ

- SOAPメッセージを記録するためのログ・アサーションの構成

- Webサービスのパフォーマンスの監視

26.4.1 適切なポリシーの選択

Oracle Web Services Securityでは多くのポリシーがサポートされていますので、デプロイメントのセキュリティ・ニーズに基づいて適切なポリシーを実装する必要があります。追加するセキュリティ・ポリシーはそれぞれパフォーマンスに影響を与える可能性があるため、パフォーマンスを十分に考慮してください。たとえば、トランスポート・レベルのセキュリティ(SSL)は、アプリケーション・レベルのセキュリティより高速ですが、マルチステップのトランザクションでは脆弱性を生む可能性があります。アプリケーション・レベルのセキュリティのほうがパフォーマンスへの影響は大きいものの、エンドツーエンドのセキュリティを実現できます。

『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』のポリシーの構成に関する項を参照し、デプロイメントに必要なセキュリティ・ポリシーを見極めてください。

26.4.2 ポリシー・マネージャ

データベースベースのポリシー強制を使用する際には、パフォーマンスへの影響がつきものです。データベース・ポリシーの強制を選択した場合、エージェントからデータベースへのポーリングの頻度を慎重に検討する必要があります。

26.4.3 SOAPメッセージを記録するためのログ・アサーションの構成

デフォルト・ポリシーのリクエスト・パイプラインおよびレスポンス・パイプラインには、ポリシー強制ポイント(PEP)でSOAPメッセージをデータベースまたはコンポーネント別ローカル・ファイルに記録するログ・アサーションが含まれています。ロギング・レベルはパフォーマンスに影響を与えることがあります。パフォーマンスの問題を回避するには、デプロイメントに適した最低のロギング・レベルを使用することを検討してください。

ログ・ステップ内に構成できるロギング・レベルには次のものがあります。

- ヘッダー: SOAPヘッダーのみが記録されます。

- 本文: メッセージの内容(本文)のみが記録されます。

- エンベロープ: SOAPエンベロープ全体(ヘッダーと本文の両方を含む)が記録されます。添付ファイルは記録されません。

- すべて: メッセージ全体が記録されます。これには、SOAPヘッダー、本文、およびすべての添付ファイル(SOAPメッセージそのものの外部に存在するURLなど)が含まれます。

注意: 一般に、ログ・ファイルをトポロジ的に強制コンポーネントに近い場所に配置すると、システムのパフォーマンスが向上します。可能であれば、著しい分散環境では複数の分散ログを使用してください。

26.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”

26.4.5 Webサービスのパフォーマンスの監視

Oracle Fusion Middleware Controlの「Webサービス」ホームページで、次のOracle Web Servicesのパフォーマンスを監視できます。

- 次のエンドポイント有効メトリック

- ポリシー参照ステータス

- 合計違反

- セキュリティ違反

- 完了した呼出し

- レスポンス時間(秒)

- 次のポリシー違反

- 合計違反

- 認証違反

- 認可違反

- 機密保持違反

- 整合性違反

- 障害の合計

Oracle Fusion Middlewareコンポーネントの監視の概要は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

Oracle Fusion Middleware Controlを使用したOracle Web Servicesの監視の詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』のWebサービスのパフォーマンスの監視に関する項を参照してください。

第VI部

Oracle WebCenterコンポーネント

この部では、パフォーマンスの向上を目的とするOracle WebCenterコンポーネントの構成について説明します。次の章で構成されています。

- 第27章「Oracle WebCenter Portalのパフォーマンス・チューニング」

27 Oracle WebCenter Portalのパフォーマンス・チューニング

この章では、WebCenter Portalアプリケーションをインストールしたオペレーティング・システム、WebCenter Portalアプリケーション、およびバックエンド・コンポーネントの構成プロパティをチューニングする方法について概説します。

- 27.1項「Oracle WebCenter Portalについて」

- 27.2項「チューニングに関する基本的な考慮事項」

- 27.3項「WebCenter Portalアプリケーション構成のチューニング」

- 27.4項「バックエンド・コンポーネント構成のチューニング」

- 27.5項「ポートレット構成のチューニング」

27.1 Oracle WebCenter Portalについて

Oracle WebCenter Portal 11gは、標準ベースのサービス指向アーキテクチャ(SOA)上にソーシャル・アプリケーション、エンタープライズ・ポータル、コミュニティ、コンポジット・アプリケーション、およびインターネットまたはイントラネットのWebサイトを構築するために使用する統合製品スイートです。Oracle WebCenter Portalは、リッチ・インターネット・アプリケーションの開発、マルチチャネルのポータル・フレームワーク、および水平型のEnterprise 2.0アプリケーション・スイートを一体化し、非常にインタラクティブなユーザー体験を生み出すコンテンツ機能、プレゼンス機能、およびソーシャル・ネットワーキング機能を備えています。ポータルまたはアプリケーションのコンテキスト内で、インスタント・メッセージ、ブログ、Wiki、RSS、タグ、ディスカッション・フォーラム、アクティビティ、ソーシャル・ネットワークなどのサービスと直接やり取りすることで、ユーザーやグループの生産性が向上し、IT投資回収率も高まります。

Oracle WebCenter Portal: Spacesは、ソーシャル・ネットワーキング、通信、コラボレーション、個人の生産性に関して、最新テクノロジを提供する、すぐに使用可能なWebCenter Portalアプリケーションで、開発作業は必要ありません。Spacesアプリケーションでは、Oracle WebCenter Portalのフレームワーク、コンポーザおよびリソース・カタログによって提供される、強力な統合型のサービスおよびアプリケーションのセットを通じて、インスタント・コミュニティ・ポータル、チーム・サイト、その他の共同作業型アプリケーションをデプロイできます。

Oracle WebCenter Portalの詳細は、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』および『Oracle Fusion Middleware Oracle WebCenter Portal開発者ガイド』を参照してください。

27.2 チューニングに関する基本的な考慮事項

この項のチューニングの考慮事項は、ほとんどのWebCenterポータルおよびWebCenterポータル: スペースのデプロイメントおよび使用状況に当てはまります。各構成を検討し、各自のユースケース・シナリオに適したものを実装することを強くお薦めします。

27.2.1 システム制限の設定

WebCenter Portalアプリケーションを適度な負荷で実行するには、open-files-limitを4096に設定します。ファイル・ディスクリプタの不足などのエラーが発生した場合は、システム制限を増やします。

たとえば、Linuxでは次のコマンドを使用します。

ulimit -n 8192

このシステム制限を変更する方法については、オペレーティング・システムのドキュメントを参照してください。

27.2.2 JDBCデータ・ソースの設定

次のデータ・ソース設定は、mds-SpacesDSおよびWebCenterDSのデフォルトです。これらの設定は、アプリケーションの使用パターンおよび負荷に応じて調整可能です。

<jdbc-connection-pool-params>
<initial-capacity>10</initial-capacity>
<max-capacity>50</max-capacity>
<capacity-increment>1</capacity-increment>
<shrink-frequency-seconds>0</shrink-frequency-seconds>
<highest-num-waiters>2147483647</highest-num-waiters>
<connection-creation-retry-frequency-seconds>0</connection-creation-retry-frequency-seconds>
<connection-reserve-timeout-seconds>60</connection-reserve-timeout-seconds>
<test-frequency-seconds>0</test-frequency-seconds>
<test-connections-on-reserve>true</test-connections-on-reserve>
<ignore-in-use-connections-enabled>true</ignore-in-use-connections-enabled>
<inactive-connection-timeout-seconds>0</inactive-connection-timeout-seconds>
<test-table-name>SQL SELECT 1 FROM DUAL</test-table-name>
<login-delay-seconds>0</login-delay-seconds>
<statement-cache-size>5</statement-cache-size>
<statement-cache-type>LRU</statement-cache-type>
<remove-infected-connections>true</remove-infected-connections>
<seconds-to-trust-an-idle-pool-connection>60</seconds-to-trust-an-idle-pool-connection>
<statement-timeout>-1</statement-timeout>
<pinned-to-thread>false</pinned-to-thread>
</jdbc-connection-pool-params>

JDBCデータ・ソースの設定を編集するには、次の手順に従います。

1. WebLogic Server管理コンソールにログインします。

2. 「ホーム」ページから「JDBCデータ・ソースのサマリー」→「mds-SpacesDSの設定」を選択し、「接続プール」タブを選択します。

3. 必要に応じてプロパティを編集します。

WebCenterポータル・データ・ソースの設定を編集するには、次の手順に従います。

1. WebLogic Server管理コンソールにログインします。

2. 「ホーム」ページから「JDBCデータ・ソースのサマリー」を選択し、「接続プール」タブに移動します。

『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の「データ・ソース接続プールのチューニング」も参照してください。

27.2.3 JRockit仮想マシン(JVM)引数の設定

JVM引数は、UNIXオペレーティング・システムのsetDomainEnv.shファイルおよびWindowsオペレーティング・システムのsetDomainEnv.cmdに設定されます。setDomainEnvファイルは、<domain_dir>/binディレクトリにあります。

関連項目:

2.4項「Java仮想マシン(JVM)のチューニング」

- WebLogic Server本番モード: WebCenterを本番デプロイメント用にインストールすると、WebLogic Serverは本番モードに設定されます。しかし、デプロイメント用にインストールした後に、パフォーマンスを向上させるために本番モードに切り替える場合は、次のパラメータを起動コマンドに含める必要があります。

-Dweblogic.ProductionModeEnabled=true

管理コンソールを使用した本番モードのドメインの設定の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプの本番モードへの変更に関する項を参照してください。

- ヒープ・サイズ: ガベージが収集されたり、メモリー不足のエラーが頻繁に発生したりしてサーバーがオーバーロードしている場合、サーバーの使用できる物理メモリーに応じてヒープ・サイズを増やします。
詳細は、2.4.1.1項「ヒープ・サイズ値の指定」と、Oracle Fusion Middleware Oracle WebLogic Server管理コンソールのオンライン・ヘルプのノード・マネージャで起動したサーバーのJavaオプションの設定に関する項を参照してください。

サーバーの起動コマンドまたは管理コンソールで次のパラメータを変更して、ヒープ・サイズを増やすことができます。

jrockit vm: -Xms2048M -Xmx2048M -Xns512M

hotspot vm: -Xms2048M -Xmx2048M -XX:MaxPermSize512M

27.2.4 コンテンツの圧縮を使用したダウンロードの削減

クライアントがリモートの場所からモデムやVPNを利用して比較的遅い接続を使用するサーバーに接続する場合、クライアントにダウンロードする前にコンテンツを圧縮することを検討してください。コンテンツの圧縮でサーバーの負荷が高まりますが、クライアントのダウンロード体験が大幅に改善されます。

いくつかのコンテンツの圧縮方法を使用できます。次の手順は、Apacheのmod_deflateモジュールの使用方法を示しています。

1. Apacheのmod_deflateモジュールを有効にします。
これを実行するには、次の内容をhttpd.conf ($OH/instances/$INSTANCE_NAME/config/OHS/$OHS_NAME)に追加します。

LoadModule deflate_module "${ORACLE_HOME}/ohs/modules/mod_deflate.so"

2. 出力フィルタを設定して、圧縮のルールを指定します。
次に示すのは、httpd.conf(上記の場所と同じ)に追加できるサンプル・スニペットです。コンテンツおよび圧縮要件に基づいて、コンテンツを変更します。

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom+xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.(?:pdf|doc?x|ppt?x|xls?x)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
</IfModule>

mod_deflateの詳細は、http://httpd.apache.org/docs/2.0/mod/mod_deflate.htmlを参照してください。

27.3 WebCenter Portalアプリケーション構成のチューニング

この項では、管理者がWebCenter Portalアプリケーションのパフォーマンスをチューニングするためのパラメータについて説明します。

この項の内容は次のとおりです。

- Spacesアプリケーションのセッション・タイムアウトの設定

- HTTPセッション・タイムアウトの設定

- JSPページ・タイムアウトの設定

- ADFクライアント状態トークンの設定

- ADF表示状態圧縮の設定

- MDSキャッシュ・サイズおよびパージ頻度の設定

- 同時実行性管理の構成

27.3.1 Spacesアプリケーションのセッション・タイムアウトの設定

Spacesアプリケーションのデフォルトのセッション・タイムアウトは、web.xmlに指定されたHTTPセッション・タイムアウトから導出されます。初期状態のweb.xmlの<session-timeout>設定は、45分です。「HTTPセッション・タイムアウトの設定」を参照してください。

管理者は、必要に応じてwebcenter-config.xmlでwcSessionTimeoutPeriod属性を使用して、セッション・タイムアウトを増減できます。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のwebcenter-config.xmlに関する項も参照してください。

27.3.2 HTTPセッション・タイムアウトの設定

全体のリソースの使用を管理するには、web.xmlファイルでアプリケーションのHTTPセッション・タイムアウト値を分単位で調整します。一般に、短いセッション・タイムアウト値は、サーバー上のメモリーおよびCPUの使用が少なくなります。

デプロイメント後にこのプロパティを変更する必要がある場合、web.xmlを手動で編集してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のweb.xmlプロパティの編集に関する項を参照してください。

次に示すのは、web.xmlのサンプル・スニペットです。

<session-config>
<session-timeout>
45
</session-timeout>
</session-config>

27.3.3 JSPページ・タイムアウトの設定

web.xmlファイルでリクエストされていないJSPページがメモリーからすべて削除されるまでの時間(秒)を表す整数値を指定できます。こうすると、頻繁にコールされないページがある場合にリソースが解放されます。

値を大きくするとユーザー・レスポンス時間が短縮され、値を小さくするとアプリケーションのメモリー・フットプリントが減少します。デフォルト値は600秒(10分)です。jsp_timeoutが指定されていないと、タイムアウトがないことになります。

このプロパティをデプロイメント後に変更するには、web.xmlを手動で編集する必要があります。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のweb.xmlプロパティの編集に関する項を参照してください。

次に示すのは、web.xmlのサンプル・スニペットです。

<servlet>
<servlet-name>
oraclejsp
<init-param>
<param-name>
jsp_timeout
</param-name>
<param-value>
600
</param-value>
</init-param>

27.3.4 ADFクライアント状態トークンの設定

この設定では、ユーザーがページ状態を失わずにブラウザの「戻る」ボタンで移動可能なページの数を制御できます。CPUおよびメモリーの使用率を下げるには、web.xmlファイルで値を小さくします。

デプロイメント後にこのプロパティを変更する必要がある場合、web.xmlを手動で編集してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』の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>

27.3.5 ADF表示状態圧縮の設定

この設定を通じて、ADF表示状態圧縮を制御できます。デフォルトで、この設定は有効(パラメータ値は'True')で、すべての非カレント・ビュー状態はメモリーに保存される前に圧縮され、それによりヒープの使用量は減少します。

WebCenterポータルでは推奨しませんが、web.xmlを手動で編集することで、このプロパティを無効にできます。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のweb.xmlプロパティの編集に関する項を参照してください。

次に示すのは、web.xmlのサンプル・コード・スニペットです。

<context-param>
<param-name> org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE
</param-name>
<param-value> false </param-value>
</context-param>

27.3.6 MDSキャッシュ・サイズおよびパージ頻度の設定

デフォルトのMDSキャッシュ・サイズは100MBです。JOCリージョンが満杯であるというエラー・メッセージが表示された場合は、adf-config.xmlファイルでMDSキャッシュ・サイズを大きくすることができます。

デプロイ後は、システムMBeanブラウザを使用してこれらのプロパティを変更します。詳細は、『Oracle Fusion Middleware管理者ガイド』のデプロイ済アプリケーションのMDS構成属性の変更に関する項を参照してください。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<cache-config>
<max-size-kb>150000</max-size-kb>
</cache-config>

MDSのauto-purge seconds-to-liveパラメータを(次の例に示すように)設定し、毎時、古いバージョンのメタデータを自動的に削除することを検討してください。デフォルトでは、auto-purge seconds-to-live="-1"で、パージは行われません。しかし、領域やページの作成および編集時など、WebCenterポータル・サイトが頻繁に変更される場合、最適なパフォーマンスのために、auto-purgeを適切な値に設定して、古いバージョンのメタデータを削除する必要があります。

メタデータが大量にたまってしまい、毎回のパージに高いコストがかかる場合は、adf-config.xmlファイルでこの間隔を短くします。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<auto-purge seconds-to-live="3600"/>

最初のパージが現在のユーザー・アクティビティに影響しないことを確認するには、ほとんどのユーザー・ロードがシステムにヒットする前に次のWLSTコマンドを使用してすぐにMDSパージを実行することを検討してください。

次の例は、バージョンが10秒よりも古いアプリケーション・リポジトリのすべてのドキュメントをパージする方法を示しています。

wls:/weblogic/serverConfig>purgeMetadata(application='[AppName]',server='[ServerName]',olderThan=10)

27.3.7 同時実行性管理の構成

同時実行性の管理には、WebCenter Portal全体に影響を与えるグローバル設定、ならびに特定のサービスのみに影響を与えるサービス固有の設定およびリソース固有の設定を使用します。

デプロイメント固有の変更や追加の構成は、adf-config.xmlファイルで定義します。たとえば、特定のデプロイメントに適したリソース固有(プロデューサ)の値を指定できます。

次の例は、adf-config.xmlのglobalエントリ、serviceエントリおよびresourceエントリの形式を示しています。

<concurrent:adf-service-config
xmlns="http://xmlns.oracle.com/webcenterportal/concurrent/config">
<global
queueSize="SIZE"
poolCoreSize="SIZE"
poolMaxSize="SIZE"
poolKeepAlivePeriod="TIMEPERIOD"
timeoutMinPeriod="TIMEPERIOD"
timeoutMaxPeriod="TIMEPERIOD"
timeoutDefaultPeriod="TIMEPERIOD"
timeoutMonitorFrequency="TIMEPERIOD"
hangMonitorFrequeny="TIMEPERIOD"
hangAcceptableStopPeriod="TIMEPERIOD" />
<service
service="SERVICENAME"
timeoutMinPeriod="TIMEPERIOD"
timeoutMaxPeriod="TIMEPERIOD"
timeoutDefaultPeriod="TIMEPERIOD" />
<resource
service="SERVICENAME"
resource="RESOURCENAME"
timeoutMinPeriod="TIMEPERIOD"
timeoutMaxPeriod="TIMEPERIOD"
timeoutDefaultPeriod="TIMEPERIOD" />
</concurrent:adf-service-config>

説明:

SIZE: 正の整数。たとえば20などです。

TIMEPERIOD: 正の整数と時間単位を示す接尾辞の組合せ。時間単位は、ms(ミリ秒)、s(秒)、m(分)、h(時間)のいずれかです。たとえば、50ms、10s、3m、1hのようになります。様々なサービスのデフォルト設定の例を次に示します。これらの設定は、connections.xmlファイルまたはadf-config.xmlファイルのサービス固有の構成で上書きされます。

<concurrent:adf-service-config
xmlns="http://xmlns.oracle.com/webcenter/concurrent/config">
<service service="oracle.webcenter.community" timeoutMinPeriod="2s" timeoutMaxPeriod="50s" timeoutDefaultPeriod="30s"/>
<resource service="oracle.webcenter.community"
resource="oracle.webcenter.doclib"
timeoutMinPeriod="2s" timeoutMaxPeriod="10s" timeoutDefaultPeriod="5s"/>
<resource service="oracle.webcenter.community"
resource="oracle.webcenter.collab.calendar.community"
timeoutMinPeriod="2s" timeoutMaxPeriod="10s" timeoutDefaultPeriod="5s"/>
<resource service="oracle.webcenter.community"
resource="oracle.webcenter.collab.rtc"
timeoutMinPeriod="2s" timeoutMaxPeriod="10s" timeoutDefaultPeriod="5s"/>
<resource service="oracle.webcenter.community"
resource="oracle.webcenter.list"
timeoutMinPeriod="2s" timeoutMaxPeriod="10s" timeoutDefaultPeriod="5s"/>
<resource service="oracle.webcenter.community"
resource="oracle.webcenter.collab.tasks"
timeoutMinPeriod="2s" timeoutMaxPeriod="10s" timeoutDefaultPeriod="5s"/>
</concurrent:adf-service-config>

注意:

serviceおよびresource以外の属性はすべてオプションです。そのため、たとえば次のタグは有効です。

<global queueSize="20"/>
<resource service="foo" resource="bar" timeoutMaxPeriod="5s"/>

Enterprise ManagerのシステムMBeanブラウザを使用して、使用パターンに基づく同時実行性構成を表示、追加、変更および削除できます。WebCenter PortalアプリケーションのMBeanブラウザにアクセスするには、『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のシステムMBeanブラウザのアクセスに関する項を参照してください。

1. システムMBeanブラウザで、次の場所に移動します。
「アプリケーション定義のMBean」→「oracle.adf.share.config」→「サーバー: (サーバー名)」→「アプリケーション: (アプリケーション名)」→「ADFConfig」→「ADFConfig (bean)」→「ADFConfig」→「WebCenterConcurrentConfiguration」→「操作」→「listResource」

図27-1 システムMBeanブラウザ - WebCenterConcurrentConfiguration

2. 現在の同時実行性設定を表示するには、「listResource」を選択して、「起動」をクリックします(図27-2)。

図27-2 システムMBeanブラウザ - listResource

「図27-2 システムMBeanブラウザ - listResource」の説明

3. 設定を変更するには、「setResource」を選択して、リソースの詳細を入力し、「起動」をクリックします(図27-3)。

図27-3 システムMBeanブラウザ - setResource

「図27-3 システムMBeanブラウザ - setResource」の説明

サービス、リソース、名前および値に正しい値を注意して入力してください。

注意: 変更しようとしているリソース・パラメータに、すでに[value]設定がある場合、最初に[removeResource]操作を起動してその設定を削除する必要があります(図27-4)。

図27-4 システムMBeanブラウザ - removeResource

4. 変更を保存するには、「アプリケーション定義のMBeans: ADFConfig:ADFConfig」 -> 「保存」に移動し、「起動」をクリックします。

27.4 バックエンド・コンポーネント構成のチューニング

この項では、WebCenter Portalアプリケーションが使用するバックエンド・サービスのパフォーマンス構成について説明します。BPELサーバーやOracle WebCenter Contentサーバーなどのバックエンドのパフォーマンスは、各バックエンドのガイドラインでの説明に従ってチューニングしてください。

この項の内容は次のとおりです。

- アナウンスメント・サービスのパフォーマンス・チューニング

- ディスカッション・サービスのパフォーマンス・チューニング

- インスタント・メッセージおよびプレゼンス(IMP)・サービスのパフォーマンス・チューニング

- メール・サービスのパフォーマンス・チューニング

- 個人イベント・サービスのパフォーマンス・チューニング

- RSSニュース・フィード・サービスのパフォーマンス・チューニング

- 検索サービスのパフォーマンス・チューニング

- ポリシー・ストアのパラメータのチューニング

27.4.1 アナウンスメント・サービスのパフォーマンス・チューニング

アナウンスメント・サービスの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 10秒

- 最小: 0秒

- 最大: 45秒

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用して「接続タイムアウト」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したディスカッション・サーバー接続詳細の変更に関する項

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したディスカッション・サーバー接続詳細の変更に関する項

次に示すのは、デフォルトのタイムアウト値を5秒に変更するconnections.xmlのサンプル・コード・スニペットです。

<Reference name="Jive-7777" className="oracle.adf.mbean.share.connection.webcenter.Announcement. AnnouncementConnection">
<Factory className="oracle.adf.mbean.share.connection.webcenter.forum.ForumConnectionFactory"/>
<StringRefAddr addrType="connection.time.out">
<Contents>5</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>

27.4.2 ディスカッション・サービスのパフォーマンス・チューニング

ディスカッション・サービスの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 10秒

- 最小: 0秒

- 最大: 45秒

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用して「接続タイムアウト」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したディスカッション・サーバー接続詳細の変更に関する項

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したディスカッション・サーバー接続詳細の変更に関する項

次に示すのは、connections.xmlのサンプル・スニペットです。

<Reference name="Jive-7777" className="oracle.adf.mbean.share.connection.webcenter.forum.ForumConnection">
<Factory className="oracle.adf.mbean.share.connection.webcenter.forum.ForumConnectionFactory"/>
<RefAddresses>
<StringRefAddr addrType="forum.url">
<Contents>http://[machine]:[port]/owc_discussions_5520</Contents>
<StringRefAddr addrType="connection.time.out">
<Contents>5</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>

27.4.3 インスタント・メッセージおよびプレゼンス(IMP)・サービスのパフォーマンス・チューニング

IMPサービスの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 10秒

- 最小: 0秒

- 最大: 45秒

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用して「接続タイムアウト」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したインスタント・メッセージおよびプレゼンス接続詳細の変更に関する項

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したインスタント・メッセージおよびプレゼンス接続詳細の変更に関する項

次に示すのは、デフォルトのタイムアウト値を5秒に変更するconnections.xmlのサンプル・コード・スニペットです。

<Reference name="IMPService-LCS"
className="oracle.adf.mbean.share.connection.webcenter.rtc.RtcConnection">
<Factory className="oracle.adf.mbean.share.connection.webcenter.rtc.RtcConnectionFactory"/>
<RefAddresses>
<StringRefAddr addrType="connection.time.out">
<Contents>5</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>

27.4.4 メール・サービスのパフォーマンス・チューニング

メール・サービスの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 10秒

- 最小: 0秒

- 最大: 45秒

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用して「接続タイムアウト」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したメール・サーバー接続詳細の変更に関する項

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したメール・サーバー接続詳細の変更に関する項

次に示すのは、デフォルトのタイムアウト値を5秒に変更するconnections.xmlのサンプル・コード・スニペットです。

<Reference name="MailConnection"
className="oracle.adf.mbean.share.connection.webcenter.mail.MailConnection">
<StringRefAddr addrType="connection.time.out">
<Contents>5</Contents>
</StringRefAddr>
</Reference>

27.4.5 アナウンスメント・サービスのパフォーマンス・チューニング

個人イベント・サービスの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 10秒

- 最小: 0秒

- 最大: 45秒

キャッシュ有効期限も設定できます。

- デフォルト: 10秒

- 最小: 0秒

- 最大: 45秒

デプロイメント後に、Fusion Middleware ControlまたはWLSTを使用して、「接続タイムアウト」および「キャッシュの期限」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したイベント・サーバー接続詳細の変更に関する項

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したイベント・サーバー接続詳細の変更に関する項

次に示すのは、デフォルトのタイムアウト値を5秒に変更するconnections.xmlのサンプル・コード・スニペットです。

<Reference name="MSExchange-my-pc"className="oracle.adf.mbean.share.connection.webcenter.calendar.PersonalEventConnection">
<Factory className="oracle.adf.mbean.share.connection.webcenter.calendar.PersonalEventConnectionFactory"/>
<StringRefAddr addrType="eventservice.connection.timeout">
<Contents>5</Contents>
</StringRefAddr>
<StringRefAddr addrType="eventservice.cache.expiration.time">
<Contents>5</Contents>
</StringRefAddr>
</RefAddresses>
</Reference>

27.4.6 RSSニュース・フィード・サービスのパフォーマンス・チューニング

RSSニュース・フィード・サービスの全体的なリソース使用状況を管理するには、adf-config.xmlファイルでリフレッシュ間隔およびタイムアウトを調整します。

これらのプロパティをデプロイメント後に変更する必要がある場合は、システムMBeanブラウザを使用してください。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<rssC:adf-rss-config>
<rssC:RefreshSecs>3600</rssC:RefreshSecs>
<rssC:TimeoutSecs>3</rssC:TimeoutSecs>
<rssC:Configured>true</rssC:Configured>
</rssC:adf-rss-config>

27.4.7 検索サービスのパフォーマンス・チューニング

検索の全体的なリソース使用状況およびユーザー・レスポンス時間を管理するには、表示される保存済の検索の数、表示される結果の数、および次のタイムアウト値を調整します。

- prepareTimeoutMs: サービスが検索の初期化にかけられる最大時間(ミリ秒)。

- timeoutMs: サービスが検索の実行にかけられる最大時間(ミリ秒)。

- showAllTimeoutMs: サービスがすべての検索結果の表示にかけられる最大時間(ミリ秒)。

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用してタイムアウト・プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したOracle SES接続詳細の変更に関する項。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したOracle SES接続詳細の変更に関する項。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<searchC:adf-search-config xmlns="http://xmlns.oracle.com/webcenter/search/config">
<display-properties>
<common numSavedSearches="25"/>
<region-specific>
<usage id="simpleSearchResultUIMetadata" numServiceRows="5"/>
<usage id="searchResultUIMetadata" numServiceRows="5"/>
<usage id="localToolbarRegion" numServiceRows="5"/>
</region-specific>
</display-properties>
<execution-properties prepareTimeoutMs="1000" timeoutMs="3000" showAllTimeoutMs="20000" />
</execution-properties>
</searchC:adf-search-config>

27.4.8 ポリシー・ストアのパラメータのチューニング

ログイン後にパフォーマンスの問題が発生している場合(特に権限のチェックの分野)、ポリシー・ストア・パラメータが、26.3.5項「OPSS PDPサービス・チューニング・パラメータ」の説明に従ってチューニングされている必要がある場合があります。ユース・ケース・シナリオによっては、WebCenterポータルおよびWebCenterポータル: スペースのパフォーマンスは、特に次のパラメータを変更することにより、向上させることができます。

- oracle.security.jps.policystore.rolemember.cache.warmup.enableをTrueに設定

- oracle.security.jps.policystore.rolemember.cache.sizeをWebCenterポータル: スペース環境で予想されるアクティブ・グループの数に応じて変更します。
注意: このパラメータはWebCenterポータル: スペース環境に3000を超えるアクティブ・スペースがあると予想される場合にのみ変更する必要があります。

- oracle.security.jps.policystore.policy.cache.sizeをグループ・スペースの数の5倍に設定

注意:

ポリシー・ストア・パラメータを変更する前に、必ず自身のユース・ケース・シナリオを参照してください。セキュリティ・パラメータをチューニングする前に、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』を参照し、詳細を確認してください。

27.5 ポートレット構成のチューニング

この項では、ポートレットのパフォーマンス関連の構成を説明します。この項の内容は次のとおりです。

- ポートレット・サービスのパフォーマンス・チューニング

- ポートレット・キャッシュ・サイズの構成

- WSRPプロデューサのJavaオブジェクト・キャッシュの有効化

- WSRPポートレットのオプティミスティック・レンダリングの抑制

- Oracle PDK-Javaプロデューサのパフォーマンス・チューニング

- ポートレット・コンテナ・ランタイム・オプションの設定

- WSRPポートレットのDefaultServedResourceRequiresWsrpRewriteの設定

- WSRPポートレットのDefaultProxiedResourceRequiresWsrpRewriteの設定

- IFrameポートレットのコンシューマCSSファイルのインポート

- ポートレット・タイムアウトの構成

- OmniPortletのパフォーマンス・チューニング

27.5.1 ポートレット・サービスのパフォーマンス・チューニング

全体的なリソース使用状況およびユーザー・レスポンス時間を管理するには、adf-config.xmlファイルで不要なロケール・サポートを削除し、ポートレットのタイムアウトおよびキャッシュ・サイズを変更します。

ポートレット・サービスに対しては、デフォルトで28のサポート・ロケールが定義されています。アプリケーションに必要のないロケールは削除できます。

デプロイメント後にこれらのプロパティを変更する必要がある場合、adf-config.xmlを手動で編集してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のadf-config.xmlの編集に関する項を参照してください。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<portletC:adf-portlet-config xmlns="http://xmlns.oracle.com/adf/portlet/config">
<supportedLocales>
<value>es</value>
<value>ko</value>
<value>ru</value>
<value>ar</value>
<value>fi</value>
<value>nl</value>
<value>sk</value>
<value>cs</value>
<value>fr</value>
<value>no</value>
<value>sv</value>
<value>da</value>
<value>hu</value>
<value>pl</value>
<value>th</value>
<value>de</value>
<value>it</value>
<value>pt</value>
<value>tr</value>
<value>el</value>
<value>iw</value>
<value>pt_BR</value>
<value>zh_CN</value>
<value>en</value>
<value>ja</value>
<value>ro</value>
<value>zh_TW</value>
</supportedLocales>
<defaultTimeout>20</defaultTimeout>
<minimumTimeout>1</minimumTimeout>
<maximumTimeout>300</maximumTimeout>
<parallelPoolSize>10</parallelPoolSize>
<parallelQueueSize>20</parallelQueueSize>
<cacheSettings enabled="true">
<maxSize>10000000</maxSize>
</cacheSettings>
</portletC:adf-portlet-config>

27.5.2 ポートレット・キャッシュ・サイズの構成

adf-config.xmlファイルでポートレット・キャッシュ・サイズを変更できます。デフォルトのポートレット・キャッシュ・サイズは10MBに設定されています。

デプロイメント後にこれらのプロパティを変更する必要がある場合、adf-config.xmlを手動で編集してください。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<adf-portlet-config>
....
<supportedLocales>
<cacheSettings enabled="true">
<maxSize>10000000</maxSize>
</cacheSettings>
</adf-portlet-config>

27.5.3 WSRPプロデューサのJavaオブジェクト・キャッシュの有効化

永続ストアに書き込まれるオブジェクトをキャッシュするため、WSRPプロデューサのJavaオブジェクト・キャッシュ(JOC)を有効にすることをお薦めします。

次に示すのは、web.xmlのサンプル・スニペットです。

<env-entry>
<env-entry-name>oracle/portal/wsrp/server/enableJavaObjectCache
</env-entry-name>
<env-entry-type>java.lang.String
</env-entry-type>
<env-entry-value>false
</env-entry-value>
</env-entry>

27.5.4 WSRPポートレットのオプティミスティック・レンダリングの抑制

WSRP PerformBlockingInteractionまたはHandleEvents呼出しの後にWSRPポートレットのオプティミスティック・レンダリングを抑制するには、portlet.xmlに指定されるポートレット・コンテナ・ランタイム・オプションのcom.oracle.portlet.suppressWsrpOptimisticRender=trueを設定します。

- true - オプティミスティック・レンダリングが常に抑制されます。

- false - オプティミスティック・レンダリングが実行される場合があります。

通常、WSRPポートレットがWSRP PerformBlockingInteractionリクエスト(JSR168/JSR286ポートレットのprocessAction)を受け取り、その結果ポートレットがイベントを送信しない場合、WSRPプロデューサはポートレットをレンダリングし、PerformBlockingInteraction SOAPメッセージに応答してポートレットのマークアップを戻します。このマークアップは、コンシューマのページがレンダリングされるまでコンシューマによってキャッシュされる場合があります。また、少なくともポートレットの状態に影響する場合(イベントを受信するポートレットなど)、コンシューマがキャッシュされたマークアップを使用できるので、GetMarkupへの2番目のSOAPコールが必要なくなります。

これには、ポートレットのレンダリング・フェーズが常にベスト・プラクティスの多重呼出し不変であると仮定します。ただし、ポートレットがイベントを受け取る可能性がある場合またはポーレットのレンダリングがGetMarkupの2番目のSOAPメッセージよりもコストがかかる場合、開発者はこのコンテナ・オプションを使用して、processActionまたはhandleEvent呼出し後のポートレットのオプティミスティック・レンダリングを抑制できます。プロデューサがWSRP GetMarkupリクエストを受け取ると、ポートレットが通常レンダリングされます。

27.5.5 Oracle PDK-Javaプロデューサのパフォーマンス・チューニング

Webプロデューサの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 30000ミリ秒

- 最小: 5000ミリ秒

- 最大: 60000ミリ秒

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用して「接続タイムアウト」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したプロデューサ登録詳細の編集に関する項。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したプロデューサ登録詳細の編集に関する項。

次に示すのは、connections.xmlのサンプル・スニペットです。

<webproducerconnection producerName="wc-WebClipping" urlConnection="wc-WebClipping-urlconn" timeout="10000" establishSession="true" mapUser="false"/>

27.5.6 ポートレット・コンテナ・ランタイム・オプションの設定

WebCenterポータル特有のexcludedActionScopeRequestAttributesコンテナ・ランタイム・オプションを使用して、新しいアクションが発生するまでポートレットが使用できるように、アクション・スコープ指定リクエスト属性を保存する方法を指定できます。

com.oracle.portlet.externalScopeRequestAttributesコンテナ・ランタイム・オプションに定義された正規表現と一致する値を含むリクエスト・パラメータに加えて、正規表現と一致するリクエスト属性は、javax.portlet.actionScopedRequestAttributesコンテナ・ランタイム・オプションが使用されている場合、アクション・スコープ指定リクエスト属性としては保存されません。

trueに設定した場合、numberOfCachedScopesの2番目の値と、ポートレット・コンテナによりキャッシュされるスコープの数を示す3番目の値を指定できます。

27.5.7 WSRPポートレットのDefaultServedResourceRequiresWsrpRewriteの設定

ポートレットによって提供されたリソースのリソースURLを生成する場合に使用するデフォルトのWSRP requiresRewriteフラグを指定するには、portlet.xmlに指定されるポートレット・コンテナ・ランタイム・オプションのcom.oracle.portlet.defaultServedResourceRequiresWsrpRewriteを設定します。

ResourceURLメソッドのwrite()またはtoString()の呼出し時にoracle.portlet.server.resourceRequiresRewritingリクエスト属性で上書きしないかぎり、この設定はポートレットで作成されたすべてのResourceURLに使用されます。この設定は提供されたリソース・レスポンスのWSRP requiresRewritingフラグの指定にも使用されますが、ポートレットのserveResource()メソッドが戻されるときのoracle.portlet.server.resourceRequiresRewritingリクエスト属性で上書きできます。

有効な値

- unspecified - (デフォルト) requiresRewrite URLフラグに値は提供されず、serveResource操作のrequiresRewritingレスポンス・フラグがレスポンスのMIMEタイプに基づいています。

- true - requiresRewrite URLフラグおよびrequiresRewritingレスポンス・フラグがtrueに設定され、コンシューマがリソースを書き換える必要があることを示します。

- false - requiresRewrite URLフラグおよびrequiresRewritingレスポンス・フラグがfalseに設定され、コンシューマはリソースの書換えを選択できますがリソースを必ずしも書き換える必要はありません。

27.5.8 WSRPポートレットのDefaultProxiedResourceRequiresWsrpRewriteの設定

ポートレットによって提供されないリソースのURLを暗号化する場合に使用するデフォルトのWSRP requiresRewriteフラグを指定するには、portlet.xmlに指定されるポートレット・コンテナ・ランタイム・オプションのcom.oracle.portlet.defaultProxiedResourceRequiresWsrpRewriteを設定します。

PortletResponse.encodeURL()メソッドの呼出し時にoracle.portlet.server.resourceRequiresRewritingリクエスト属性で上書きしないかぎり、この設定はPortletResponse.encodeURL()メソッドで戻されたすべてのURLに使用されます。

有効な値

- true - (デフォルト) requiresRewrite URLフラグがtrueに設定され、コンシューマがリソースを書き換える必要があることを示します。

- false - requiresRewrite URLフラグがfalseに設定され、コンシューマがリソースを必ずしも書き換える必要がないことを示します。

27.5.9 IFrameポートレットのコンシューマCSSファイルのインポート

CSSファイルがIFramedポートレットにインポートされることをポートレット・コンシューマに指定するには、portlet.xmlに指定されるポートレット・コンテナ・ランタイム・オプションのcom.oracle.portlet.importCssToIFrameを設定します。

有効な値

- true - コンシューマからのCSSファイルがIFramedポートレットに適用されます。

- false - (デフォルト) 何も実行されません。

27.5.10 ポートレット・タイムアウトの構成

adf-config.xmlファイルのadf-portlet-config要素でポートレット・タイムアウトの値を変更できます。デフォルト値は10秒、最小値は0.1秒、最大値は60秒です。

デプロイメント後にこれらのプロパティを変更する必要がある場合、adf-config.xmlを手動で編集してください。『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のadf-config.xmlの編集に関する項を参照してください。

次に示すのは、adf-config.xmlのサンプル・スニペットです。

<adf-portlet-config>
....
<defaultTimeout>5</defaultTimeout>
<minimumTimeout>2</minimumTimeout>
<maximumTimeout>300</maximumTimeout>
</adf-portlet-config>

27.5.11 OmniPortletのパフォーマンス・チューニング

OmniPortletの全体的なリソース使用状況を管理するには、「接続タイムアウト」プロパティを次のようにチューニングします。

- デフォルト: 30000ミリ秒

- 最小: 5000ミリ秒

- 最大: 60000ミリ秒

デプロイメント後は、Fusion Middleware ControlまたはWLSTを使用して「接続タイムアウト」プロパティを変更します。詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のFusion Middleware Controlを使用したプロデューサ登録詳細の編集に関する項。

- 『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』のWLSTを使用したプロデューサ登録詳細の編集に関する項。

次に示すのは、connections.xmlのサンプル・スニペットです。

<webproducerconnection producerName="wc-OmniPortlet" urlConnection="wc-OmniPortlet-urlconn" timeout="10000" establishSession="false" mapUser="false"/>

第VII部

キャパシティ・プランニング、スケーラビリティおよび可用性

この部では、高いトラフィック、スケーラビリティおよび可用性が得られるサイトを計画する方法について説明します。次の章で構成されています。

- 第28章「キャパシティ・プランニング」

- 第29章「クラスタおよび高可用性機能の使用」

28 キャパシティ・プランニング

キャパシティ・プランニングとは、アプリケーションのニーズを満たすために必要なハードウェアおよびソフトウェアの構成を決定するプロセスのことです。パフォーマンス計画と同様、キャパシティ・プランニングは反復型のプロセスです。優れたキャパシティ管理計画は、負荷データを長期的に監視および測定し、パフォーマンスに影響を与えることなく変化に対処できる柔軟なソリューションを実装するという作業に基づいています。

注意:

この章の内容は、効果的なキャパシティ管理計画を作成するうえで利用可能な各種手法の概要を示すことを目的としています。実行するステップ、および最終的に作成する計画は、個々の要件やデプロイメント構造によって異なります。

次の各項でキャパシティ・プランニングについて概説します。

- 28.1項「Oracle Fusion Middlewareのキャパシティ・プランニングについて」

- 28.2項「パフォーマンス目標の決定」

- 28.3項「パフォーマンス・メトリックの測定」

- 28.4項「システムのボトルネックの特定」

- 28.5項「キャパシティ管理計画の実施」

28.1 Oracle Fusion Middlewareのキャパシティ・プランニングについて

パフォーマンス・チューニングが既存のシステムを最適化してパフォーマンスを改善することであるのに対し、キャパシティ・プランニングでは、平常時とピーク時両方のパフォーマンスを維持するにはシステムに何が(いつ)必要かを決定します。

キャパシティ・プランニングには、ソリューションの設計および構成のテストに加えて、ビジネスの見通し、周期的な需要の変動、およびアプリケーションの制約を特定する作業が伴います。注意深く計画を立てて、丁寧にテストを行い、パフォーマンスに焦点を当てた設計原則を採用する必要があります。本番環境にアプリケーションをデプロイする前に、アプリケーションに対して厳密なパフォーマンス・テスト・サイクルを実施してください。効果的なキャパシティ管理計画を作成するには、パフォーマンス計画を作成するときと同じステップをいくつか実行します。

- ステップ1: パフォーマンス目標の決定

- ステップ2: パフォーマンス・メトリックの測定

- ステップ3: システムのボトルネックの特定

- ステップ4: キャパシティ管理計画の実施

28.1.1 キャパシティ・プランニングの際に考慮する要因

計画を作成する前に、デプロイメント方針を裏付けるデータを集める必要があります。キャパシティ管理計画が効果的なものになるよう、次に示す項目について確認し、得られた情報を注意深く分析してください。

表28-1 キャパシティ・プランニングの際に考慮する要因

キャパシティ・プランニングに関する確認事項

詳細の参照先

パフォーマンス目標は何か。

28.2項「パフォーマンス目標の決定」

同時に(並行して)実行する必要のあるユーザーの数はどのくらいか。

28.2項「パフォーマンス目標の決定」

シミュレーションしたワークロードは適切か。(ワークロードの増加が見込まれるか。)

28.2項「パフォーマンス目標の決定」

Oracle Fusion Middlewareのデプロイメントはクラスタリング、その他の高可用性要素をサポートするよう構成されているか。

28.4.1項「クラスタ構成の使用」

ハードウェアは構成要件を満たしているか。

28.5.1項「ハードウェアの構成要件」

ユーザーをサポートするのに十分なJVMがあるか。

28.5.2項「JVM要件」

データベースが制約要因になっているか。

28.5.4項「データベース構成」

28.2 パフォーマンス目標の決定

効果的なキャパシティ管理計画を作成するための最初のステップは、ネットワーク負荷およびパフォーマンス目標を決定することです。デプロイするアプリケーション、およびシステムにおける環境面の制約を理解する必要があります。アプリケーションのコンポーネントが達成することを求められるアクティビティ・レベルについて、次のような情報を収集しておくのが理想的です。

- 予想ユーザー数。

- 同時セッション数。

- 必要なSSL接続の数。

- リクエストの数およびサイズ。

- データの量および一貫性。

- 目標とするCPU使用率の決定。

パフォーマンス目標は、次のような制約によって制限されます。

- ハードウェアおよびソフトウェアの構成(CPUタイプ、ディスク・サイズとディスクの処理速度の比較、十分なメモリーなど)。

- ドメイン間の相互運用、レガシー・システムの使用、およびレガシー・データのサポートが可能かどうか。

- セキュリティ要件とSSLの使用。SSLには大量の計算処理が伴うため、SSLプロトコルでの暗号化処理をサポートする場合はWebLogic Serverのパフォーマンスに影響が出る可能性があります。

- 開発、実装およびメンテナンスのコスト。
この情報を基に、レスポンス時間、スループット、特定のハードウェアにかかる負荷など、アプリケーション環境にとって現実的なパフォーマンス目標を設定できます。

28.3 パフォーマンス・メトリックの測定

28.2項「パフォーマンス目標の決定」でパフォーマンス基準を決定したら、パフォーマンス目標を定量化するためのメトリックを測定します。キー・パフォーマンス・インジケータのベンチマーク・テストを実施することで、パフォーマンスの指針が得られます。Oracle Fusion Middlewareアプリケーションにおけるパフォーマンス・メトリックの測定の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。

28.4 システムのボトルネックの特定

ボトルネック(著しいパフォーマンス低下が見られる分野)は、キャパシティ管理計画の作成中に対処する必要があります。可能であれば、アプリケーションのプロファイリングを行ってボトルネックを正確に特定し、アプリケーションのパフォーマンスを改善します。Oracleでは、次のプロファイラを用意しています。

- Oracle JRockit Mission Controlは、JRockit JVMを使用した処理のプロファイリング機能を備えています。
http://www.oracle.com/technology/products/jrockit/missioncontrol/index.html

- Oracle Application Diagnosticsは、SUN JDKを使用したJava処理のプロファイリング機能を備えています。
http://www.oracle.com/technology/software/products/oem/htdocs/jade.html

ボトルネックを特定する目的は、ボトルネックをすべて解消することではなく、パフォーマンス目標を満たすことです。システム内のリソースは有限です。本質的に、1つ以上のリソース(CPU、メモリーまたはI/O)がシステムのボトルネックとなる可能性があります。たとえば、予想されるピーク使用量を考慮した計画を立てれば、ボトルネックがパフォーマンス目標に与える影響を最小限に抑えることができます。

システムのボトルネックに対処するにはいくつかの方法があります。一般的なソリューションを次に示します。

- クラスタ構成の使用

- 接続プーリングの使用

- JVMの最大ヒープ・サイズの設定

- メモリーまたはCPUの増加

- ネットワーク・トラフィックの分離

- プロセスとハードウェア割込みハンドラの分離

28.4.1 クラスタ構成の使用

クラスタ構成では、複数の同一クラスタ・メンバー・インスタンスにワークロードが分散されます。そのため、分散処理に利用できるリソースの量が何倍にも増えるとともに、シームレスなフェイルオーバーが可能になり、高可用性が実現します。

詳細は、第29章「クラスタおよび高可用性機能の使用」を参照してください。

28.4.2 接続プーリングの使用

既存のデータベース接続を使用してパフォーマンスを改善できる場合があります。接続文字列を変更することで、接続数、セッションのタイミング、その他のパラメータを制限できます。

データベース接続プールの構成の詳細は、2.7項「データベース接続の再利用」を参照してください。

28.4.3 JVMの最大ヒープ・サイズの設定

これは、ガベージ・コレクションの所要時間と同じハードウェア上で実行可能なJVMの数のトレードオフを可能にする、アプリケーション固有のチューニング項目です。ヒープ・サイズは、大きいほうが使用効率が高く、一般にガベージ・コレクションの回数も少なくなります。JVMプロセスが多ければ、フェイルオーバー・ポイントも多くなります。

詳細は、2.4項「Java仮想マシン(JVM)のチューニング」を参照してください。

28.4.4 メモリーまたはCPUの増加

単一のハードウェア・リソースにメモリーまたはCPU(あるいはその両方)をより多く集約すれば、同じハードウェアを共有するインスタンス間の通信をローカルに行うことができます。単一マシンの物理メモリーおよび処理能力を増やすことで、JVM(特に64ビットのJVM)を拡張して、格段に大きく、より強力なインスタンスを実行できるようになります。JVMの規模が大きいと、メモリーの使用効率が高まり、ガベージ・コレクションの発生頻度が低下する傾向があります。場合によっては、CPUを追加するとマシンの処理装置で利用できる命令キャッシュおよびデータ・キャッシュが増え、処理効率がさらに向上します。

詳細は、2.2項「十分なハードウェア・リソースの確保」を参照してください。

28.4.5 ネットワーク・トラフィックの分離

ネットワーク負荷の高いアプリケーションは、ネットワークを使用する他のアプリケーションで重大なパフォーマンス上の問題が発生する原因となります。時間が重要な意味を持つアプリケーションのネットワーク・トラフィックを、ネットワーク負荷の高いアプリケーションから分離して、別のネットワーク・インタフェースへ転送すれば、パフォーマンスへの影響を軽減できます。様々なネットワーク・インタフェースからのトラフィックにそれぞれ異なる転送優先度を割り当てることも可能です。

28.4.6 プロセスとハードウェア割込みハンドラの分離

特定のハードウェア・リソースで処理可能なキャパシティを計画する際には、オペレーティング・システムがJVMプロセスやその他のシステム・プロセスおよびハードウェア割込みハンドラを効率的にスケジューリングできない場合があることを理解することが重要です。JVMがハードウェア割込みハンドラとCPUコアの一部を共有している場合は、JVMのパフォーマンスに影響が出ることもあります。たとえば、ディスクおよびネットワークへの負荷の高いアプリケーションは、パフォーマンスに対して、CPUにかかる負荷と釣り合わないほどの影響を与えます。さらに、ハードウェア割込みが発生すると、アクティブなJavaスレッドがGCセーフ・ポイントまで効率的に到達できないことがあります。使用頻度の高いハードウェア割込みハンドラを、JVMプロセスを実行するCPUから分離することで、ガベージ・コレクションが開始されるまでの待ち時間を短縮できます。

マルチコア・マシンの複数のCPUを単一のJVM専用にすると、CPUキャッシュの効率が高まって効果的な場合もあります。複数のプロセスが同じCPUを共有する必要がある場合は、データ・キャッシュおよび命令キャッシュの中に両方のプロセスからのデータや命令が混在することになるため、効果的に使用されるキャッシュの量が減少します。ただし、プロセスを特定のCPUコアに割り当てれば、ピーク時の負荷急増の際に他のCPUコアを使用できるようになります。負荷が低いときのCPUの使用効率を高めるのか、それともアクティビティの急増に備えて余分なキャパシティを確保しておくのかを決め、それをキャパシティ管理計画に反映させてください。

28.5 キャパシティ管理計画の実施

パフォーマンス目標の定義、ワークロードの測定、およびボトルネックの特定が済んだら、キャパシティ管理計画を作成して実施する必要があります。計画の目的は、パフォーマンス目標を満たすか、それを上回るパフォーマンスを得ること(特にピーク時)、そして将来のワークロードの増加に対応できるようにすることです。パフォーマンス目標を達成するには、管理計画を実施し、第4章「Oracle Fusion Middlewareの監視」で説明したようにパフォーマンス・メトリックを継続的に監視する必要があります。

デプロイメントはそれぞれ異なるため、すべての構成に当てはまるキャパシティ管理計画の実施方法を説明することはほとんど不可能です。キャパシティ・プランニングは反復型のプロセスであり、計画はワークロードや環境の変化に合せて調整する必要があります。この後の項では、計画の中で考慮する必要のある主な要因を示します。

28.5.1 ハードウェアの構成要件

ハードウェア要件を決定するための唯一の公式などありません。ハードウェアおよびソフトウェアの構成を決定するプロセスでは、システムのパフォーマンス目標を評価し、アプリケーションについて理解することが必要です。サーバー・ハードウェアのキャパシティ・プランニングでは、最大のパフォーマンス要件に焦点を当てる必要があります。

現在のハードウェア要件は変化する可能性があります。計画は、ワークロードの増加、環境の変化(サーバーやサード・パーティ・サービスの追加など)、ソフトウェアのアップグレード(オペレーティング・システム、ミドルウェア、その他のアプリケーション)、ネットワーク接続およびネットワーク・プロトコルを考慮したものであることが必要です。

28.5.1.1 CPU要件

目標とするCPU使用率は、100%に設定するのではなく、アプリケーションのニーズ(ピーク時のCPUサイクルなど)に基づいて決定してください。通常負荷時のCPU使用率が100%になるように最適化した場合、ピーク時の負荷を処理するキャパシティは残っていません。待機時間の影響を受けやすく、高速のレスポンス時間を維持することが重要な意味を持つアプリケーションでは、CPU使用率が高い(100%に近づく)と、レスポンス時間が短くなる一方で、スループットは一定に保たれるか、向上します。これは、待機中の処理がサーバーにたまるためです。このようなアプリケーションの場合、推奨されるCPU使用率は70から80%です。待機時間の影響を受けないアプリケーションの場合は、90%程度を目標とすることをお薦めします。

28.5.1.2 メモリー要件

メモリー要件は、同じハードウェア上のJVMごとに、ユーザーが使用するアプリケーションの最適なヒープ・サイズによって決まります。最適なヒープ・サイズに加えて、JVMごとに最大500MBが必要です。パフォーマンスへの実際の影響は、JVMのブランドおよび実行するアプリケーションのタイプによって変わります。たとえば、ロードされるJavaクラスが多いアプリケーションには、コンパイル済クラスのために多くの領域が必要になります。ハードウェア・アーキテクチャやオペレーティング・システムによって制限が課される場合、一部のアーキテクチャでは、32ビットのJVMは約3GBの制限を超えることができません。オペレーティング・システム、IOバッファおよび共有メモリー・デバイス用にある程度のメモリーを確保しておくことをお薦めします。

28.5.2 JVM要件

単一のJava仮想マシン(VM)が処理できるユーザー/プロセスの数は、リクエストのタイプおよび実行しているJVMのタイプによって大きく異なります。パフォーマンス監視およびベンチマーク・テストの手順の一環として、実行するプロセスの数および種類を調べ、ハードウェアが特定のJVMの要件を満たしているかどうかを見極めてください。

28.5.3 管理対象サーバー

高いパフォーマンスと信頼性の両方を確保するために、クラスタ構成の複数のノードにわたって、複数の管理対象サーバーを使用することをお薦めします。ただし、管理対象サーバーが複数存在すると、使用するメモリーが増えることに注意してください。そのため、一部のアプリケーションでは特定の操作をメモリー内で最適化できるようになり、ディスク、データベースおよびネットワーク待機時間への影響が軽減されます。

クラスタ構成の使用の詳細は、『Oracle Fusion Middleware管理者ガイド』の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項を参照してください。

28.5.4 データベース構成

持続的なパフォーマンスを確保するためには、アプリケーション・サーバー層の予定キャパシティが増加した場合に、それに合せて既存のデータベースを拡張できるようにする必要があります。データベース・パラメータをチューニングし、ピーク時のデータベース・メトリックを監視することで、既存のデータベース・リソースを拡張して負荷の増加に対処することが可能かどうかを判断できます。メモリーの追加やデータベース・ハードウェア構成のアップグレードが必要になることもあります。Oracleデータベースのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

ただし、メモリーの追加やCPUのアップグレードを行っても、データベースが負荷の増加を効果的に管理できない場合があります。このような状況では、Oracle Real Application Cluster(Oracle RAC)環境をデプロイして増加に対処することを検討してください。Oracle RAC構成は、パフォーマンスの強化だけでなく、信頼性およびスケーラビリティの向上も実現します。Oracle RACの詳細は、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

29 クラスタおよび高可用性機能の使用

高可用性アーキテクチャは、あらゆるエンタープライズ・デプロイメントにとって重要な要件の1つです。Oracle Fusion Middlewareは多彩な高可用性機能を備えています。これらの機能は、Oracle Fusion Middlewareのコンポーネントおよびアプリケーションを計画外停止から保護するとともに、計画停止を最小限に抑えます。

この章では、Oracle Fusion Middlewareコンポーネントのアーキテクチャ、相互作用および依存関係について、またこれらのコンポーネントを高可用性アーキテクチャにデプロイしてパフォーマンスを最大化する方法について説明します。

この章の内容は次のとおりです。

- 29.1項「クラスタおよび高可用性機能について」

- 29.2項「Oracle Fusion Middlewareでのクラスタの使用」

- 29.3項「Oracle Fusion Middlewareでの高可用性機能の使用」

注意:

クラスタやその他の高可用性オプションを使用することは、複雑で緻密なプロセスです。この章は、Oracle Fusion Middlewareと関連のある概念を紹介することを目的としています。高可用性の詳しい情報が記載されているOracle Fusion Middlewareのマニュアルを表29-1にまとめてあります。

29.1 クラスタおよび高可用性機能について

高可用性とパフォーマンスのいずれにおいても、最も重要な要因の1つとなるのがクラスタの使用です。クラスタとは、単一または複数のコンピュータで実行され、同じワークロードを共有する、一連のプロセスです。クラスタ構成を使用すると、スケーラビリティ、高可用性およびパフォーマンスが向上します。

高可用性とは、サービスが中断することなくユーザーがシステムにアクセスできることを指します。高可用性システムをデプロイすると、システムの停止時間(利用できない時間)が最小化され、システムの稼働時間(利用可能な時間)が最大化されます。次を参照

クラスタやその他の高可用性機能の使用の詳細は、表29-1に示すアプリケーション別のマニュアルを参照してください。

表29-1 クラスタおよび高可用性の情報が記載されたOracle Fusion Middlewareドキュメント

コンポーネント

参照先

Oracle Fusion Middleware

『Oracle Fusion Middleware管理者ガイド』

Oracle WebLogic Server

『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』

『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』

Oracle SOA Suite

『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』

『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』

Oracle WebCenter

『Oracle Fusion Middleware Oracle WebCenter Portal管理者ガイド』

Oracle Fusion Middleware Enterprise Oracle WebCenter Portalデプロイメント・ガイド

Oracle ADF

『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』

『Oracle Fusion Middleware Oracle Application Development Framework Webユーザー・インタフェース開発者ガイド』

Oracle Fusion Middlewareのバックアップとリカバリ

『Oracle Fusion Middleware管理者ガイド』

Oracle Web Cache

『Oracle Fusion Middleware Oracle Web Cache管理者ガイド』

Oracle Identity Management

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

Oracle Fusion Middleware Oracle Identity Managementのエンタープライズ・デプロイメント・ガイド

Oracle Virtual Directory

『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』

Oracle HTTP Server

『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』

Oracle Internet Directory

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

Oracle Repository Creation Utility(RCU)

『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』

Oracle Portal

Oracle Fusion Middleware Oracle Portalの管理者ガイド

29.2 Oracle Fusion Middlewareでのクラスタの使用

アプリケーションのパフォーマンス、スループットまたは高可用性の向上が求められる本番環境では、2つ以上の管理対象サーバーがクラスタとして機能するように構成できます。クラスタとは、複数のOracle WebLogic Serverサーバー・インスタンスの集合です。これらのインスタンスは並行して稼働し、相互に連携してスケーラビリティおよび信頼性の向上を実現します。

Oracle Fusion Middlewareでのクラスタの使用の詳細は、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware管理者ガイド』の管理対象サーバーと管理対象サーバー・クラスタの理解に関する項

- 『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』

- 『Oracle Real Application Clusters管理およびデプロイメント・ガイド』

29.3 Oracle Fusion Middlewareでの高可用性機能の使用

Fusion Middlewareコンポーネントでのクラスタ・アーキテクチャの使用に加えて、ユーザーが継続的にアプリケーションにアクセスできるようにする組込みの高可用性機能が数多く用意されています。包括的な高可用性システムを構築するためのオプションをいくつか次に示します。実際に組み込むオプションは、全体的なパフォーマンス目標、およびシステムのアーキテクチャによって異なります。ここにあげた項目は単なる例です。

- プロセスの停止検出および自動再起動
プロセスは、構成やソフトウェアの問題が原因で、突然停止することがあります。プロセスの監視および再起動が適切に行われるシステムでは、アプリケーションの状態が継続的にチェックされ、問題が発生した場合はアプリケーションが再起動されます。

システム・プロセスでは、指定された時間間隔における再起動の回数も記録している必要があります。短時間のうちに再起動を繰り返すとさらなる異常や障害が発生する可能性があるため、これも重要な機能です。したがって、指定した時間間隔における再起動または再試行の最大回数も指定しておく必要があります。

- 状態のレプリケーションおよびルーティング
ステートフル・アプリケーションでは、クライアントの状態をレプリケートして、リクエストを処理するプロセスに障害が発生したときにリクエストのステートフル・フェイルオーバーを実行することができます。

- フェイルオーバー
ロード・バランシング・メカニズムを導入すると、インスタンスが冗長化されます。いずれかのインスタンスに障害が発生した場合は、障害が発生したインスタンスへのリクエストを、障害が発生していないインスタンスに送ることができます。

- サーバーのロード・バランシング
同じサーバー・コンポーネントのインスタンスが複数存在する場合は、これらのコンポーネントへのクライアント・リクエストをロード・バランシングして、各インスタンスのワークロードがほぼ同一になるようにすることができます。

- 障害時リカバリ
障害時リカバリ・ソリューションでは通常、2つの同種のサイト(1つはアクティブ・サイト、もう1つはパッシブ・サイト)を設定します。サイトはそれぞれが自己完結型のシステムです。一般に、アクティブ・サイトを本番サイト、パッシブ・サイトをスタンバイ・サイトと呼びます。通常の運用では、本番サイトがリクエストを処理しますが、サイトでフェイルオーバーやスイッチオーバーが発生すると、スタンバイ・サイトが本番サイトを引き継ぎ、すべてのリクエストがそのサイトにルーティングされます。フェイルオーバー用のスタンバイ・サイトを保持するには、スタンバイ・サイトに同種のインストールおよびアプリケーションを含めるだけでなく、データおよび構成を本番サイトからスタンバイ・サイトに常時同期化する必要もあります。

詳細は、『Oracle Fusion Middleware高可用性ガイド』を参照してください。

索引

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W

A

アドバンスト・レプリケーション・ベースのレプリケーション

チューニング, 23.3.1

DBMS_STATSパッケージのANALYZEファンクション, 23.8 アナウンスメント・サービス

パフォーマンス・チューニング, 27.4.1

属性

ガベージ・コレクション

チューニング, 23.13

orclskewedattribute, 23.7.2 スキュー, 検索の最適化, 23.7.2 チューニング, 23.3.1, 23.3.2 自動再起動, 29.3

B

バルク・ツール

パフォーマンス, 23.3.1

bulkdeleteコマンド

パフォーマンス・チューニング, 23.3.1

データベース・パラメータのチューニング, 23.6.2

bulkloadコマンド

Oracle RACデータベース, 23.4.4

パフォーマンス・チューニング, 23.3.1

チューニング, 23.6.1

C

キャッシュ

サーバー・エントリ, 23.4.5

変更ログ

生成, チューニング, 23.3.2

パージ

チューニング, 23.4.3

パージ構成エントリ

チューニング, 23.13

生成を無効にする条件, 23.6.3 同時実行性管理, 27.3.7 競合解決

チューニング, 23.4.2

接続タイムアウト

チューニング, 23.5.3

D

データベース

問合せ, 最適化, 23.7.2

REDOログ・ファイル

チューニング, 23.6.3

SQL実行計画

パフォーマンスへの影響, 23.3.3

統計

チューニング, 23.3.3

db_cache_sizeデータベース・インスタンス・パラメータ

チューニング, 23.3.1

DBMS_STATSパッケージ, 23.8 停止検出, 29.3 Oracle Directory Integration Platformおよびレプリケーション専用のLDAPサーバー

チューニング, 23.4.4

ディレクティブ

「httpd.confディレクティブ」も参照

障害時リカバリ, 29.3 ディスカッション・サービス

パフォーマンス・チューニング, 27.4.2

DMS

イベント・センサー, 6.1.1.3.2

PhaseEventセンサー, 6.1.1.3.1

センサー

定義, 6.1.1.3

状態センサー, 6.1.1.3.2 メトリックのテスト, 6.8 DMS実行コンテキスト, 6.6, 6.6 DNS

ドメイン・ネーム・サーバー, 5.3.2

E

エントリ

検索で返される

チューニング, 23.5.1

エントリ・キャッシュ, 23.4.5

最適化, 23.4.6.3

使用する条件, 23.4.5

イベント・センサー, 6.1.1.3.2 イベント追跡

チューニング, 23.4.6.3

実行コンテキスト, 6.3

F

フェイルオーバー, 29.3

Oracle RACデータベース, 23.4.4

G

ガベージ・コレクション

チューニング, 23.4.3

ガベージ・コレクタ, 27.2.3 グループ・キャッシュ, 有効化

チューニング, 23.5.2

グループ・エントリ

大きい

検索の最適化, 23.7.1

H

ヒープ・サイズ, 27.2.3

負荷の高いLDAP書込み操作

チューニング, 23.6.3

HIQ

「管理者操作キュー」を参照

HostNameLookups

ディレクティブ, 5.3.2

httpd.conf

ディレクティブ

HostNameLookups, 5.3.2

KeepAlive, 5.2

KeepAliveTimeout, 5.2, 5.2.1

ListenBacklog, 5.2

MaxClients, 5.2

MaxKeepAliveRequests, 5.2, 5.2.1

MaxRequestsPerChild, 5.2

Timeout, 5.2

管理者操作キュー

変更

チューニング, 23.4.2

I

IBM WebSphere, 6.4.6

アイドル接続タイムアウト

チューニング, 23.3.2

IMP(インスタント・メッセージおよびプレゼンス)サービス

パフォーマンス・チューニング, 27.4.3

検索フィルタのメモリー内処理, 23.7.3 iostatユーティリティのパフォーマンス評価, 23.8

J

job_queue_processesデータベース・インスタンス・パラメータ

チューニング, 23.3.1

JSPページ・タイムアウト, 27.3.3 JVM引数, 27.2.3

K

KeepAliveディレクティブ, 5.2

KeepAlive httpd.confディレクティブ, 5.2.1, 5.2.1

KeepAliveTimeout httpd.confディレクティブ, 5.2, 5.2.1

L

大きいグループ・エントリ

検索の最適化, 23.7.1

ListenBacklog httpd.confディレクティブ, 5.2 ロード・バランシング

Oracle RACデータベース, 23.4.4

ロギング

パフォーマンスへの影響, 5.3

M

メール・サービス

パフォーマンス・チューニング, 27.4.4

matchDN情報

チューニング, 23.3.2

max_commit_propagation_delayデータベース・インスタンス・パラメータ

チューニング, 23.3.1

MaxClientsディレクティブ, 5.2 MaxKeepAliveRequests httpd.confディレクティブ, 5.2, 5.2.1 MaxRequestsPerChild httpd.confディレクティブ, 5.2 MDSキャッシュ・サイズ, 27.3.6 MDSリポジトリ

MDSキャッシュ・サイズの設定, 27.3.6

MDSパージ頻度の設定

MDSパージ頻度, 27.3.6

mpstatユーティリティのパフォーマンス評価, 23.8

N

Noun

タイプ, 6.1.1.2

プロセスおよびスレッドの数

チューニング, 23.3.2

O

ODSM

変更ログのパージの構成, 23.13.2

変更ログ・パージ構成エントリへの移動, 23.13.2

OmniPortlet

パフォーマンス・チューニング, 27.5.11

open-files-limit, 27.2.1 最適化

「チューニング」も参照

検索の最適化, 23.7

大きいグループ・エントリ, 23.7.1

Oracle Business Rules, 12.1 Oracle Directory Integration Platform

チューニング, 23.4.1

Oracle Process Manager and Notification Server(OPMN), 4.7 Oracle RAC

フェイルオーバー, 23.4.4

ロード・バランシング, 23.4.4

Oracle RACデータベース

bulkoadコマンド, 23.4.4

Oracle Internet Directoryのチューニング, 23.4.4

Oracle WebLogic Scripting Tool(WLST)

「WLSTコマンド」も参照

orclchangeretrycount属性

チューニング, 23.4.2, 23.4.2

orclconflresolution属性

チューニング, 23.4.2, 23.4.2

orclecacheenabled属性

サーバー・エントリ・キャッシュの最適化, 23.4.6.3

orclecachemaxentries属性

サーバー・エントリ・キャッシュの最適化, 23.4.6.3

orclecachemaxentsize属性

大きいグループ・エントリの検索の最適化, 23.7.1.1

サーバー・エントリ・キャッシュの最適化, 23.4.6.3

orclecachemaxsize属性

サーバー・エントリ・キャッシュの最適化, 23.4.6.3

orclenablegroupcache属性

グループ・キャッシュのチューニング, 23.5.2

orclgeneratechangelog属性

チューニング, 23.3.2

orclhiqschedule属性

チューニング, 23.4.2

orclinmemfiltprocess属性

例, 23.7.3

複雑な検索フィルタのパフォーマンスの最適化, 23.7.3

orclldapconntimeout属性

チューニング, 23.3.2, 23.3.2

orclmatchdnenabled属性

チューニング, 23.3.2, 23.3.2

orclmaxcc属性

サーバー・エントリ・キャッシュの最適化, 23.4.6.3

チューニング, 23.3.2, 23.3.2

orclnwrwtimeout属性

接続タイムアウトのチューニング, 23.5.3

orcloptrackmaxtotalsize属性

セキュリティ・イベント追跡, 23.4.8

orcloptracknumelemcontainers属性

セキュリティ・イベント追跡, 23.4.8

orclpurgeinterval属性

チューニング, 23.4.3, 23.13

orclpurgetargetage属性

チューニング, 23.4.3, 23.13

orclserverprocs属性

サーバー・エントリ・キャッシュの最適化, 23.4.6.3

チューニング, 23.3.2, 23.3.2

orclskewedattribute属性, 23.7.2

スキュー属性の検索の最適化, 23.7.2

orclskiprefinsql属性

チューニング, 23.3.2, 23.3.2

orclthreadspersupplier属性

チューニング, 23.4.2, 23.4.2

orclupdateschedule属性

チューニング, 23.4.2, 23.4.2

P

パラメータ

KeepAlive, 5.2, 5.2.1

KeepAliveTimeout, 5.2

ListenBacklog, 5.2

MaxClients, 5.2

MaxKeepAliveRequests, 5.2

MaxRequestsPerChild, 5.2

Timeout, 5.2

パスワード・ポリシー

チューニング, 23.4.5

PDK-Javaプロデューサ

パフォーマンス・チューニング, 27.5.5

パフォーマンス

「チューニング」も参照

チューニング, ツール, 23.8

パフォーマンス・チューニング

スレッド数, 20.3

永続的な接続

KeepAliveディレクティブ, 5.2.1

個人イベント・サービス

パフォーマンス・チューニング, 27.4.5

pga_aggregate_targetデータベース・パラメータ

bulkloadのチューニング, 23.3.1, 23.6.1

PhaseEventセンサー, 6.1.1.3.1 ポートレット

キャッシュ・サイズ, 27.5.2

ロケール・サポート, 27.5.1

タイムアウト, 27.5.10

チューニング, 27.5.1

プロセスの停止検出, 29.3 processesデータベース・インスタンス・パラメータ

チューニング, 23.3.1

Q

問合せ, データベース

最適化, 23.7.2

R

RACデータベース

デプロイメント

チューニング, 23.3.1

REDOログ・ファイル

チューニング, 23.6.3

レプリケーション

パフォーマンス・チューニング, 23.4.2

チューニング, 23.4.1, 23.4.2

RSSニュース・フィード・サービス

パフォーマンス・チューニング, 27.4.6

ルール・エンジン, 12.2.1 ルール・パターン, 12.2.5

S

sarユーティリティのパフォーマンス評価, 23.8

検索

フィルタ

メモリー内処理, 23.7.3

返されるエントリの数

チューニング, 23.5.1

検索サービス

パフォーマンス・チューニング, 27.4.7

セキュリティ・イベント追跡

チューニング, 23.4.6.3

サーバー属性

チューニング, 23.3.1

サーバー・エントリ・キャッシュ, 23.4.5

属性の設定, 23.4.6.3

最適化, 23.4.6.3

チューニング, 23.4.5

使用する条件, 23.4.5

サーバーのロード・バランシング, 29.3 session_cached_cursorsデータベース・インスタンス・パラメータ

チューニング, 23.3.1

setDomainEnv.sh, 27.2.3 SGA自動チューニング, 23.3.1 sga_max_sizeデータベース・インスタンス・パラメータ

チューニング, 23.3.1

sga_targetデータベース・パラメータ

チューニング, 23.3.1

bulkdeleteのチューニング, 23.6.2

shared_pool_sizeデータベース・インスタンス・パラメータ

チューニング, 23.3.1

サイズ設定ウィザード, 23.9 スキュー属性, 23.7.2

検索の最適化, 23.7.2

検索の参照のスキップ

チューニング, 23.3.2

状態のレプリケーションおよびルーティング, 29.3 状態センサー, 6.1.1.3.2

T

Timeout httpd.confディレクティブ, 5.2

タイムアウト

同時実行性管理, 27.3.7

JSPページ, 27.3.3

ポートレット, 27.5.10

サービスおよびポートレット, 27.4

ツール

パフォーマンスの評価, 23.8

チューニング, 23.8

topユーティリティ

パフォーマンス評価, 23.8

チューニング

拡張構成, 23.3.3

アドバンスト・レプリケーション・ベースのレプリケーション, 23.3.1

アナウンスメント・サービス, 27.4.1

bulkload, 23.6.1

変更ログの生成, 23.6.3

ディスカッション・サービス, 27.4.2

負荷の高いLDAP書込み操作, 23.6.3

IMPサービス, 27.4.3

メール・サービス, 27.4.4

ガベージ・コレクション属性の変更, 23.13

プロセスおよびスレッドの数, 23.3.2

Omniportletプロデューサ, 27.5.11

大きいグループ・エントリの検索の最適化, 23.7.1

スキュー属性の検索の最適化, 23.7.2

パスワード・ポリシー, 23.4.5

PDK-Javaプロデューサ, 27.5.5

パフォーマンス評価ツール, 23.8

個人イベント・サービス, 27.4.5

ポートレット, 27.5.1

RACデータベースのデプロイメント, 23.3.1

推奨事項

チューニングとサイズ設定ウィザード, 23.9

レプリケーション, 23.4.2 RSSサービス, 27.4.6 検索サービス, 27.4.7 セキュリティ・イベント追跡, 23.4.6.3 サーバー属性, 23.3.1 サーバー・エントリ・キャッシュ, 23.4.5 SGA自動チューニング, 23.3.1 スキュー属性

検索の最適化, 23.7.2

書込み操作のタイムアウト, 23.5.3 ツール, 23.8, 23.8 検証ポリシー, 23.4.5 レプリケーションまたはDirectory Integration Platformがデプロイされている場合, 23.4.1 チューニングとサイズ設定ウィザード, 23.9 検索で返されるエントリのチューニング, 23.5.1

U

UNDO表領域のサイズ

LDAP書込み操作の負荷が高い場合のチューニング, 23.6.3

UTLBSTAT.SQL, 23.8 UTLESTAT.SQL, 23.8

V

検証ポリシー

チューニング, 23.4.5

vmstatユーティリティのパフォーマンス評価, 23.8

W

WebCenterアプリケーション

チューニング, 27.3

WebSphere

IBM WebSphere, 6.4.6

Windows

タスク マネージャ

パフォーマンスの評価, 23.8

Windowsパフォーマンス モニター

パフォーマンス評価, 23.8

ウィザード

チューニングとサイズ設定, 23.9

書込み操作のタイムアウト

チューニング, 23.5.3

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.