Oracle® Fusion Middleware

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

12c (12.2.1)

E70023-02(原本部品番号:E55161-02)

2016年2月

このドキュメントは、WebLogic Server環境でパフォーマンスのモニターとコンポーネントのチューニングを担当する方を対象としています。

Oracle Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニング, 12c (12.2.1)

E70023-02

Copyright © 2007, 2016, Oracle and/or its affiliatesAll rights reserved.

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

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

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

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

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

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

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

目次

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

はじめに

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

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- このリリースのパフォーマンス機能

2 WebLogic Serverのチューニングにおける重要推奨事項

- プール・サイズのチューニング

- プリペアド文キャッシュの使用

- ロギング・ラスト・リソースの最適化の使用

- 接続バックログのバッファリングのチューニング

- OptimisticまたはRead-only並行性の使用

- ローカル・インタフェースの使用

- eager-relationship-cachingの使用

- HTTPセッションのチューニング

- メッセージング・アプリケーションのチューニング

3 パフォーマンス・チューニングのロードマップ

- パフォーマンス・チューニングのロードマップ

- パフォーマンスに関する目標の設定

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

- ディスクおよびCPUの使用状況のモニター

- ネットワーク上のデータ転送のモニター

- システムにおけるボトルネックの特定

- ボトルネックによる影響の軽減

- アプリケーションのチューニング

- DBのチューニング

- WebLogic Serverパフォーマンス・パラメータのチューニング

- JVMのチューニング

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

- パフォーマンス目標の達成

- チューニングのヒント

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

- JVMのチューニングの考慮事項

- 他のJVMへの変更

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

- VMのヒープ・サイズとガベージ・コレクション

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

- verboseガベージ・コレクションを使用したヒープ・サイズの決定

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

- ヒープ・サイズのチューニングのヒント

- Java HotSpot VMヒープ・サイズのオプション

- Java HotSpot VMのその他のオプション

- 低メモリー状態の自動的なロギング

- ガベージ・コレクションの手動によるリクエスト

- スレッド・スタックのリクエスト

- 管理対象サーバーのJavaヒープ・サイズの増加

- 管理コンソールを使用したJavaヒープ・サイズの設定

- startManagedWebLogicスクリプトの変更によるJavaヒープ・サイズの設定

- コマンド行を使用したJavaヒープ・サイズの設定

- 管理対象サーバーによって使用されるメモリー値の決定

5 WebLogic診断フレームワークとJavaフライト・レコーダとの統合のチューニング

- Javaフライト・レコーダの使用

- WLDFの使用

- チューニングの考慮事項

6 WebLogic Serverのチューニング

- WebLogic Serverを起動するためのJavaパラメータの設定

- 開発モードと本番モードのデフォルトのチューニング値

- デプロイメント

- 内部アプリケーションのオンデマンド・デプロイメント

- FastSwapデプロイメントによる再デプロイメント時間の短縮

- 汎用オーバーライド

- スレッド管理

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

- 必要なワーク・マネージャの数

- 各ワーク・マネージャのSLA要件

- ワーク・マネージャと実行キューの相違の理解

- 以前のリリースからの移行

- スタック・スレッドの検出動作のチューニング

- ネットワークI/Oのチューニング

- マキサーのチューニング

- 非ブロッキングIOマキサー

- その他のマキサー

- ネットワーク・チャネル

- サービス妨害攻撃の可能性の低減

- メッセージ・サイズのチューニング

- 完了メッセージ・タイムアウトのチューニング

- ファイル記述子数のチューニング

- 接続バックログのバッファリングのチューニング

- キャッシュされた接続のチューニング

- マルチテナンシ・チューニング推奨事項

- Java式の最適化

- WebLogic Serverクラスタを使用したパフォーマンスの向上

- スケーラビリティと高可用性

- WebLogicクラスタのスケーラビリティを確保する方法

- データベースのボトルネック

- セッション・レプリケーション

- 非同期HTTPセッション・レプリケーション

- エンティティEJBの無効化

- HTTPセッションの無効化

- JNDIのバインド、アンバインド、およびリバインド

- マルチ・コア・マシン上でのマルチ・サーバー・インスタンスの実行

- XAトランザクション・クラスタ・アフィニティを使用したクラスタ・スループットの向上

- WebLogic Serverドメインのモニター

- 管理コンソールでのWebLogic Serverのモニター

- WebLogic診断フレームワークの使用

- JMXでのWebLogic Serverのモニター

- WLSTでのWebLogic Serverのモニター

- WebLogic Serverをモニターするためのリソース

- クラスおよびリソースのロードのチューニング

- フィルタリング・ローダー・メカニズム

- クラス・キャッシング

- SSLの考慮事項

7 WebLogic永続ストアのチューニング

- 永続ストアの概要

- デフォルト永続ストアの使用方法

- カスタム・ファイル・ストアとJDBCストアの使用方法

- JDBC TLOGストアの使用

- JMSページング・ストアの使用方法

- フラッシュ・ストレージを使用したJMSメッセージのページング

- 診断ストアの使用方法

- 永続ストア使用時のベスト・プラクティス

- JDBCストアのチューニング

- ファイル・ストアのチューニング

- 基本的チューニングの情報

- ファイル・ストアの直接書込み - キャッシュありポリシーのチューニング

- フラッシュ・ストレージの使用によるパフォーマンスの向上

- 追加の考慮事項

- ファイル・ストアの直接書込みポリシーのチューニング

- ファイル・ストア・ブロック・サイズのチューニング

- ファイル・ストアのブロック・サイズの設定

- ファイル・ストア・ブロック・サイズの確認

- ファイル・システム・ブロック・サイズの確認

- 既存のファイルが存在するストアの変換

- ネットワーク・ファイル・システムの使用

- 同期書込みポリシーの構成

- サーバーの再起動の動作のテスト

- NFSのロック・エラーの処理

- 方法1: データ・ファイルをコピーしてNFSロックの削除

- 方法2: WebLogic Serverのファイル・ストア内のファイル・ロックの無効化

8データベースのチューニング

- 一般的な推奨事項

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

- Oracle

- Microsoft SQL Server

- Sybase

9 WebLogic Server EJBのチューニング

- 一般的なEJBチューニングのヒント

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

- ステートフル・セッションBeanキャッシュのチューニング

- エンティティBeanキャッシュのチューニング

- トランザクション・レベルのキャッシング

- トランザクション間のキャッシング

- READY Beanのキャッシング

- 問合せキャッシュのチューニング

- EJBプールのチューニング

- ステートレス・セッションBeanプールのチューニング

- MDBプールのチューニング

- エンティティBeanプールのチューニング

- CMPエンティティBeanのチューニング

- 積極的なリレーションシップ・キャッシングの使用

- 内部結合の使用

- JDBCバッチ処理の使用

- 調整更新

- フィールド・グループの使用

- include-updates

- call-by-reference

- Beanレベルのペシミスティックなロック

- 並行性戦略

- モニター統計に応じたチューニング

- キャッシュ・ミス率

- ロック待機率

- ロック・タイムアウト率

- プール・ミス率

- Bean破棄率

- プール・タイムアウト率

- トランザクション・ロールバック率

- トランザクション・タイムアウト率

10メッセージ駆動型Beanのチューニング

- トランザクション・バッチの使用

- MDBスレッド管理

- 同時MDBの数の確定

- 並行性戦略の選択

- WebLogic宛先を使用する場合のスレッドの利用

- マルチスレッド・トピックMDBの制限

- 分散トピックを使用したMDBの構成およびデプロイのベスト・プラクティス

- 外部宛先におけるMDBの使用

- 外部宛先からのメッセージを処理するMDB並行性

- 外部宛先からのメッセージを処理するMDBのスレッド使用率

- キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング

- WLS 10.0以前のバージョン方式のポーリングに対する互換性

11 データ・ソースのチューニング

- データベース接続数のチューニング

- 浪費の回避

- 予約時の接続テストの慎重な使用

- プリペアド文と呼出し可能文のキャッシュ

- Pinned-To-Threadプロパティの使用によるパフォーマンスの向上

- サーバーの負荷が重い状態でのデータベース・リスナー・タイムアウト

- データ型オブジェクトのラッピングの無効化

- Oracleドライバとデータベースの詳細構成

- 設計のベスト・プラクティスの使用

12 トランザクションのチューニング

- グローバル・トランザクション・チューニング

- XAトランザクション・クラスタ・アフィニティ

- ロギング・ラスト・リソース・トランザクションの最適化

- LLRチューニング・ガイドライン

- 読取り専用の1フェーズ・コミットの最適化

- TLogを使用しないXAトランザクションの構成

13 WebLogic JMSのチューニング

- JMSパフォーマンス&チューニング・チェック・リスト

- 大きなメッセージ・バックログの処理

- メッセージ処理パフォーマンスの向上

- メッセージ生成の制御

- メッセージ生成の制御に関する短所

- クライアント・リソースのキャッシュと再利用

- 分散キューのチューニング

- トピックのチューニング

- 非恒久トピック・パブリッシャのチューニング

- サイズの大きなメッセージのチューニング

- 割当ての定義

- 割当てリソース

- 宛先レベルの割当て

- JMSサーバー・レベルの割当て

- 割当て条件内での送信者のブロック

- 接続ファクトリでの送信タイムアウトの定義

- JMSサーバーでのブロッキング時の送信ポリシーの指定

- MessageMaximumのチューニング

- MessageMaximum制限のチューニング

- ネットワーク・プロトコルの最大メッセージ・サイズの設定

- メッセージの圧縮

- メッセージのページングによるメモリーの解放

- メッセージ・ページング・ディレクトリの指定

- 「メッセージ・バッファ・サイズ」オプションのチューニング

- JMSサーバーおよび宛先のメッセージのフロー制御

- フロー制御の仕組み

- フロー制御の構成

- フロー制御のしきい値

- 期限切れメッセージの処理

- メッセージ有効期限ポリシーの定義

- トピックの有効期限ポリシーを構成する

- キューの有効期限ポリシーを構成する

- テンプレートの有効期限ポリシーを構成する

- 有効期限ロギング・ポリシーを定義する

- 有効期限ログの出力形式

- アクティブなメッセージ有効期限のチューニング

- 宛先をアクティブにスキャンして期限切れメッセージを処理するようにJMSサーバーを構成する

- 順序単位を使用したアプリケーションのチューニング

- ベスト・プラクティス

- UOOと分散宛先の使用

- UOOを使用するための古いアプリケーションの移行

- 一方向のメッセージ送信の使用

- 接続ファクトリでの一方向送信の構成

- 宛先が1つの場合のクラスタにおける一方向送信のサポート

- 宛先が複数の場合のクラスタにおける一方向送信のサポート

- 一方向送信がサポートされないケース

- 異なるクライアントと宛先ホスト

- クライアントのホスト接続ファクトリでのXA対応

- 高度なQOSの検出

- 宛先割当ての超過

- サーバー・セキュリティ・ポリシーにおける変更

- JMSサーバーまたは宛先ステータスにおける変更

- 論理分散宛先名のルックアップ

- ハードウェア障害

- 一方向送信のQOSのガイドライン

- メッセージング・パフォーマンスのプリファレンス・オプションのチューニング

- メッセージング・パフォーマンスの構成パラメータ

- 非同期メッセージ・パイプラインとの互換性

- クライアント側スレッド・プール

- JMS .NETクライアント・アプリケーションのベスト・プラクティス

- Oracle Data Guard環境の考慮事項

- 計画停止時間の宛先の停止

- 予期しない停止に対するJMSサービスの移行

14 WebLogic JMSストア・アンド・フォワードのチューニング

- JMS SAFのベスト・プラクティス

- JMS SAFのチューニングのヒント

15 WebLogicメッセージング・ブリッジのチューニング

- ベスト・プラクティス

- バッチ・サイズの変更

- バッチ間隔の変更

- サービス品質の変更

- 複数のブリッジ・インスタンスの使用

- スレッド・プール・サイズの変更

- 恒久サブスクリプションの無効化

- ソースまたはターゲット宛先とブリッジの同じ場所への配置

- 「非同期モードを有効化」属性の変更

- 多くのブリッジを使用する環境のチューニング

16リソース・アダプタのチューニング

- リソース・アダプタのクラスローディングの最適化

- 接続の最適化

- スレッド管理

- InteractionSpecインタフェース

17 Webアプリケーションのチューニング

- ベスト・プラクティス

- ページ・チェックの無効化

- カスタムJSPタグの使用

- JSPのプリコンパイル

- HTMLテンプレート圧縮の使用

- サービス・レベル・アグリーメントの使用

- 関連情報

- セッション管理

- セッションの永続性の管理

- セッションの最小化

- セッション・データの集約

- Pub-Subチューニング・ガイドライン

- GZIP圧縮の有効化

18 Webサービスのチューニング

- Webサービスのベスト・プラクティス

- Web Service Reliable Messagingエージェントのチューニング

- Webサービスのパフォーマンス改善のための負荷の大きいシステムのチューニング

- ワーク・マネージャのスレッド・プールの最小サイズ制約の設定

- バッファリング・セッションの設定

- 非同期リソースの解放

19 WebLogic Tuxedo Connectorのチューニング

- 構成のガイドライン

- ベスト・プラクティス

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

- キャパシティ・プランニングの要因

- プログラムに基づくクライアントとWebベースのクライアント

- RMIとサーバーのトラフィック

- SSL接続とパフォーマンス

- WebLogic Serverプロセスの負荷

- データベース・サーバーのキャパシティとユーザー・ストレージ要件

- 同時セッション

- ネットワーク負荷

- クラスタリングされた構成

- サーバーの移行

- アプリケーションの設計

- アプリケーション・パフォーマンスの目標の評価

- ハードウェアのチューニング

- パフォーマンスを評価するためのベンチマーク

- サポートされるプラットフォーム

- ネットワークのパフォーマンス

- ネットワーク帯域幅の決定

- 関連ドキュメント

はじめに

ここでは、このガイド『Oracle WebLogic Serverのパフォーマンスのチューニング』で使用されるドキュメントのアクセシビリティ機能と表記規則について説明します。

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

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

Oracleサポートへのアクセス

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

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

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

斜体

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

固定幅フォント

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

1 概要とロードマップ

この章では、『Oracle WebLogic Serverのパフォーマンスのチューニング』の内容と構成について説明します。

この章には次の項が含まれます:

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- このリリースのパフォーマンス機能

ドキュメントのスコープと対象読者

このドキュメントは、WebLogic Server環境でパフォーマンスのモニターとコンポーネントのチューニングを担当する方を対象としています。サーバーの管理とハードウェアのパフォーマンス・チューニングの基礎、WebLogic Server、XML、およびJavaプログラミング言語について読者が理解していることを前提としています。

このドキュメントの手引き

- この章、第1章「概要とロードマップ」では、このガイドの構成を紹介します。

- 第2章「WebLogic Serverのチューニングにおける重要推奨事項」では、WebLogic Server上で動作するアプリケーションに対して最適なパフォーマンス・チューニングを行うために最も推奨される手順について説明します。

- 第3章「パフォーマンス・チューニングのロードマップ」では、現在のアプリケーション環境をチューニングしてパフォーマンスを最適化するのに役立つロードマップを示します。

- 第4章「Java仮想マシン(JVM)のチューニング」では、JVMのチューニングにおける考慮事項について説明します。

- 第5章「WebLogic診断フレームワークとJavaフライト・レコーダとの総合のチューニング」では、WebLogic診断フレームワーク(WLDF)がJavaフライト・レコーダとともに機能する仕組みについて説明します。

- 第6章「WebLogic Serverのチューニング」では、アプリケーションのニーズにあわせてWebLogic Serverをチューニングする方法について説明します。

- 第7章「WebLogic永続ストアのチューニング」では、永続ストアをチューニングする方法について説明します。

- 第8章「データベースのチューニング」では、使用しているデータベースをチューニングする方法について説明します。

- 第9章「WebLogic Server EJBのチューニング」では、EJBを使用するアプリケーションのチューニング方法について説明します。

- 第10章「メッセージドリブンBeanのチューニング」では、メッセージドリブンBeanのチューニング方法について説明します。

- 第11章「データ・ソースのチューニング」では、JDBCアプリケーションをチューニングする方法について説明します。

- 第12章「トランザクションのチューニング」では、ロギング・ラスト・リソースのトランザクション最適化をチューニングする方法について説明します。

- 第13章「WebLogic JMSのチューニング」では、WebLogic JMSを使用するアプリケーションのチューニング方法について説明します。

- 第14章「WebLogic JMSストア・アンド・フォワードのチューニング」では、WebLogic JMSストア・アンド・フォワードを使用するアプリケーションのチューニング方法について説明します。

- 第15章「WebLogicメッセージング・ブリッジのチューニング」では、WebLogicメッセージング・ブリッジを使用するアプリケーションのチューニング方法について説明します。

- 第16章「リソース・アダプタのチューニング」では、リソース・アダプタを使用するアプリケーションのチューニング方法について説明します。

- 第17章「Webアプリケーションのチューニング」では、WebLogic Webアプリケーションおよびアプリケーション・リソースをチューニングするためのベスト・プラクティスを示します。

- 第18章「Webサービスのチューニング」では、Webサービスを使用するアプリケーションのチューニング方法について説明します。

- 第19章「WebLogic Tuxedo Connectorのチューニング」では、WebLogic Tuxedo Connectorを使用するアプリケーションのチューニング方法について説明します。

- 付録A「キャパシティ・プランニング」では、キャパシティ・プランニングの概要を示します。

このリリースのパフォーマンス機能

このリリースのWebLogic Serverでは、次のパフォーマンス機能が拡張されました。

- XAトランザクション・クラスタ・アフィニティを使用したクラスタ・スループットの向上

- TLogを使用しないXAトランザクションの構成

2 WebLogic Serverのチューニングにおける重要推奨事項

この章では、パフォーマンス・チューニングにおける重要推奨事項を簡単に示します。WebLogic ServerおよびWebLogic Serverアプリケーションのチューニングは、複雑で繰返し実施しなければならない作業です。ここでは、チューニングを始めるにあたり、アプリケーションのパフォーマンスを最適化する際の推奨事項について簡単に説明します。ここで説明するチューニング方法は、ほとんどのWebLogicアプリケーションに適用できます。

この章には次の項が含まれます:

- プール・サイズのチューニング

- プリペアド文キャッシュの使用

- ロギング・ラスト・リソースの最適化の使用

- 接続バックログのバッファリングのチューニング

- OptimisticまたはRead-only並行性の使用

- ローカル・インタフェースの使用

- eager-relationship-cachingの使用

- HTTPセッションのチューニング

- メッセージング・アプリケーションのチューニング

プール・サイズのチューニング

予想されるスレッドの利用に対して、並行性を最大化するプール・サイズ(JDBC接続、ステートレス・セッションEJB、およびMDBのプールなど)を指定します。

- WebLogic Serverリリース9.0以降の場合、サーバー・インスタンスでは自動チューニング・スレッド・プールが使用されます。適切なプール・サイズを決定する最良の方法は、プールの現在のサイズ、縮小数、拡大数、および待機数をモニターすることです。「スレッド管理」を参照してください。MDBのチューニングは特殊なケースです。第10章「メッセージドリブンBeanのチューニング」を参照してください。

プリペアド文キャッシュの使用

プリペアド文キャッシュは、メモリーにコンパイル済SQL文を保持するため、後で同じ文が使用された場合に、データベースとの往復を回避できます。第11章「データ・ソースのチューニング」を参照してください。

ロギング・ラスト・リソースの最適化の使用

トランザクション対応のデータベース・アプリケーションを使用する場合、XAではなく、JDBCデータ・ソースのロギング・ラスト・リソース(LLR)トランザクション・ポリシーの使用を検討してください。LLRの最適化を使用すると、特に2フェーズ・コミット・データベースの挿入、更新、および削除処理など、データベース処理の2PC XAオーバーヘッドの一部が安全に除去されるため、トランザクションのパフォーマンスを大幅に向上することができます。詳細は、第11章「データ・ソースのチューニング」を参照してください。

接続バックログのバッファリングのチューニング

WebLogic Serverインスタンスが受け入れる接続リクエストの数(それ以上のリクエストは拒否されます)をチューニングできます。この調整可能なパラメータは、主にWebアプリケーションに適用されます。「接続バックログのバッファリングのチューニング」を参照してください。

OptimisticまたはRead-only並行性の使用

可能なかぎり、CMP EJBのquery-cachingではRead-only並行性を、cache-between-transactionsではOptimistic並行性を使用してください。これらの2つのオプションでは、EJBコンテナによって提供されるエンティティBeanキャッシュが利用されます。

- cache-between-transactionsでのOptimistic並行性は、read-mostly Beanに対して最も正常に機能します。これらと読込みの検証を組み合せて使用すると、データの高整合性が保証され、キャッシングのパフォーマンスも向上します。第9章「WebLogic Server EJBのチューニング」を参照してください。

- 問合せキャッシングはWebLogic Server 9.0以降の機能。EJBコンテナはこの機能によって、読取り専用EJBに対して定義された任意の非主キー・ファインダの結果をキャッシュできます。これらのパラメータはすべて、アプリケーションまたはモジュールのデプロイメント記述子で設定できます。「並行性戦略」を参照してください。

ローカル・インタフェースの使用

同じアプリケーション内で、あるEJBがサーブレットまたはJSPによって呼び出されたり、別のEJBに呼び出される場合は、local-interfacesを使用するか、call-by-referenceセマンティクスを使用して、シリアライゼーションのオーバーヘッドを回避します。次の点に注意してください。

- WebLogic Server 8.1より前のリリースでは、call-by-referenceはデフォルトでオンになっています。WebLogic Server 8.1以降のリリースでは、call-by-referenceはデフォルトでオフになっています。call-by-referenceが明示的にオンにされない8.1以降のWebLogic Serverに移行する古いアプリケーションでは、パフォーマンスが低下する場合があります。

- この最適化は、異なるアプリケーション間の呼出しには適用されません。

eager-relationship-cachingの使用

可能なかぎり、eager-relationship-caching (積極的なリレーションシップ・キャッシング)を使用してください。この機能を使用すると、EJBコンテナは、単一のSQL文を使用して関連Beanをロードできます。この機能を使用すると、トランザクションの関連Beanをロードするデータベース呼出し数が減少するため、Beanとその関連Beanがそのトランザクションで使用されるものと考えられる場合にパフォーマンスが向上します。第9章「WebLogic Server EJBのチューニング」を参照してください。

HTTPセッションのチューニング

セッションの永続性およびセッションを処理する場合、アプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化してください。また、環境およびアプリケーションに合わせてセッション管理戦略を設計する必要もあります。「セッション管理」を参照してください。

メッセージング・アプリケーションのチューニング

メッセージング・ユーザー用に、パフォーマンスを調整可能なパラメータが豊富に提供されています。一般的に、割当てとページングは常に構成する必要があります。次を参照してください:

- 第7章「WebLogic永続ストアのチューニング」

- 第13章「WebLogic JMSのチューニング」

- 第14章「WebLogic JMSストア・アンド・フォワードのチューニング」

- 第15章「WebLogicメッセージング・ブリッジのチューニング」

3 パフォーマンス・チューニングのロードマップ

この章では、システム・パフォーマンスの向上に利用できるチューニングのロード・マップおよびヒントを示します。

この章には次の項が含まれます:

- パフォーマンス・チューニングのロードマップ

- チューニングのヒント

パフォーマンス・チューニングのロードマップ

ここでは、現在のアプリケーション環境をチューニングしてパフォーマンスを最適化するのに役立つロードマップを示します。

1. パフォーマンスに関する目標の設定

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

3. システムにおけるボトルネックの特定

4. ボトルネックによる影響の軽減

5. パフォーマンス目標の達成

パフォーマンスに関する目標の設定

パフォーマンスの目標を決めるには、デプロイされているアプリケーションや、システム環境の制約について理解する必要があります。アプリケーションのコンポーネントの条件にかなうアクティビティのレベルに関する情報を収集してください。これには次のものが含まれます。

- 予想されるユーザーの数

- リクエストの数とサイズ

- データの量と一貫性

- 目標とするCPU使用率
目標とするCPU使用率を100%にすることはできません。目標とするCPU使用率は、使用しているアプリケーションのニーズ(ピーク使用時のCPUサイクルなど)に基づいて決定する必要があります。通常の負荷時にCPU使用率が100%に最適化されている場合、ピーク時の負荷を処理するキャパシティが残っていないことになります。待機時間に敏感なアプリケーションでは、高速なレスポンス時間を実現できることが重要になります。CPU使用率が高い(使用率が100%に近づく)と、レスポンス時間が長くなる場合があります。一方、スループットは一定に保たれるか、サーバーで処理がキューイングされるため増大します。このようなアプリケーションでは、CPU使用率を70 - 80%にすることをお薦めします。待機時間に敏感でないアプリケーションにおいては、90 %程度を目標に設定することをお薦めします。

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

- CPUの種類、ディスク・サイズとディスク速度の関係、メモリーが足りているかどうかなど、ソフトウェアおよびハードウェアの構成
ハードウェア要件を決定する式は、1つではありません。キャパシティ・プランニングとは、アプリケーションのニーズによってハードウェアおよびソフトウェアの構成のタイプを決定するプロセスです。キャパシティ・プランニングでは、システムのパフォーマンス目標の評価およびアプリケーションの理解が必要です。サーバーのハードウェアのキャパシティ・プランニングでは、最大パフォーマンス要件に重点をおく必要があります。付録A「キャパシティ・プランニング」を参照してください。

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

- 開発、実装、およびメンテナンスの費用

こうした情報を使用して、特定のハードウェアにおけるレスポンス時間、スループット、および負荷など、現在のアプリケーション環境における現実的なパフォーマンス目標を設定します。

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

「パフォーマンス目標の理解」でパフォーマンスの基準を決定した後、パフォーマンス目標の定量化に使用するメトリックを計測します。次の項では、基本パフォーマンス・メトリックの計測に関する情報が提供されています。

- ディスクおよびCPUの使用状況のモニター

- ネットワーク上のデータ転送のモニター

ディスクおよびCPUの使用状況のモニター

高い負荷をかけた状態でアプリケーションを実行して以下をモニターします。

- アプリケーション・サーバー(ディスクおよびCPUの使用率)

- データベース・サーバー(ディスクおよびCPUの使用率)

目的は、設定した目標のCPU使用率をアプリケーション・サーバーが達成することです。アプリケーション・サーバーのCPU使用率が低い場合は、データベースにボトルネックがないかどうかを確認します。データベース・サーバーのCPU使用率が100%に達する場合は、アプリケーションのSQL呼出し問合せのプランを見直します。たとえば、SQL呼出しで、索引を使用したりリニア検索を実行したりしていないかを確認します。また、データベース・サーバーのCPUに負荷がかかるORDER BY句を、アプリケーションで使用しすぎていないかどうかも確認します。

データベース・サーバーのディスクがボトルネックになっている(ディスクの使用率が100%に達している)ことが判明したら、アプリケーションで必要とされるだけの書込みが実行できていないとみなし、より高速なディスクに交換するか、RAID (redundant array of independent disks)構成に変更します。

データベース・サーバーがボトルネックではないと判明したら、アプリケーション・サーバーのディスクがボトルネックになっていないかどうかを確認します。アプリケーション・サーバーのディスクがボトルネックになる原因としては以下が考えられます。

- 永続ストアの書込み

- トランザクション・ロギング(tlog)

- HTTPロギング

- サーバー・ロギング

アプリケーション・サーバーでのディスクI/Oを最適化する方法としては、より高速なディスクやRAIDの使用、JMSの同時書込みの無効化、tlogへのJTA直接書込みの使用、HTTPログ・バッファの増設などがあります。

ネットワーク上のデータ転送のモニター

アプリケーションとアプリケーション・サーバーの間、およびアプリケーション・サーバーとリモート・エンドポイントの間で転送されるデータの量を確認します。このデータ量は、ネットワークの帯域幅を超えてはいけません。超えると、ネットワークがボトルネックになる可能性があります。

システムにおけるボトルネックの特定

ネットワークおよびデータベース・サーバーがボトルネックになっていないことが判明したら、オペレーティング・システム、JVM、およびWebLogic Serverの構成を調べます。もっとも重要なのは、クライアントの負荷が高い状態で、WebLogic Serverを実行するマシンのCPU使用率が目標値に達するかどうかです。目標値に達しない場合は、アプリケーション内でロックが発生していないかどうかを確認します。ボトルネックを特定してアプリケーションのパフォーマンスを向上させるには、アプリケーションをプロファイリングします。「Java Mission Control」を参照してください。

ヒント:
CPU使用率が100%に達している場合でも、アプリケーションをプロファイリングしてパフォーマンスを向上させることをお薦めします。

ボトルネックによる影響の軽減

この手順では、現在の環境をチューニングして、設定したパフォーマンス目標に対するボトルネックの影響を軽減します。この手順では、ボトルネックの影響を排除するのではなく、軽減するという点に注意してください。チューニングでは、リソースを調整して設定したパフォーマンス目標を達成できます。このドキュメントで説明する範囲は次のとおりです(重要性の高い項目からリストされています)。

- アプリケーションのチューニング

- DBのチューニング

- WebLogic Serverパフォーマンス・パラメータのチューニング

- JVMのチューニング

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

- WebLogic永続ストアのチューニング

アプリケーションのチューニング

『Oracle WebLogic Server: Optimizing WebLogic Server Performance』の著者を引用すると、「アプリケーションの設計がよい場合、パフォーマンスもよくなります。複雑すぎるアプリケーションまたは設計の悪いアプリケーションは、システム・レベル・チューニングおよびパフォーマンスを向上させるためにベストなプラクティスを行ったとしても、パフォーマンスは悪くなります。」つまり、設計の悪いアプリケーションでは、不必要なボトルネックが発生する可能性があります。たとえば、リソース競合は、アプリケーション・ドメインに伴うものではなく、悪い設計によるものである場合があります。

詳細は、次を参照してください:

- 第9章「WebLogic Server EJBのチューニング」

- 第10章「メッセージドリブンBeanのチューニング」

- 第11章「データ・ソースのチューニング」

- 第12章「トランザクションのチューニング」

- 第13章「WebLogic JMSのチューニング」

- 第14章「WebLogic JMSストア・アンド・フォワードのチューニング」

- 第15章「WebLogicメッセージング・ブリッジのチューニング」

- 第16章「リソース・アダプタのチューニング」

- 第17章「Webアプリケーションのチューニング」

- 第18章「Webサービスのチューニング」

- 第19章「WebLogic Tuxedo Connectorのチューニング」

DBのチューニング

データベースがエンタープライズ・レベルのボトルネックになる可能性もあります。データベースの最適化は複雑となる場合があるため、ベンダーに依存する場合があります。「データベースのチューニング」を参照してください。

WebLogic Serverパフォーマンス・パラメータのチューニング

WebLogic Serverでは、実際の環境やアプリケーションにあわせて細かくチューニングできるパフォーマンス関連の多数のOOTB (out-of-the-box)パラメータを使用しています。これらのパラメータをシステム要件に基づいてチューニングすることで、デフォルト設定のまま実行する場合に比べ、単一ノードのパフォーマンスおよびアプリケーションのスケーラビリティ特性を大きく向上させることができます。第6章「WebLogic Serverのチューニング」を参照してください。

JVMのチューニング

Java仮想マシン(JVM)は、マイクロプロセッサ上でJavaクラス・ファイルのバイト・コードを実行する仮想の「実行エンジン」インスタンスです。第4章「Java仮想マシン(JVM)のチューニング」を参照してください。

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

ご使用のアプリケーション環境に基づいたオペレーティング・システム・ドキュメントに従って、オペレーティング・システムをチューニングします。

パフォーマンス目標の達成

パフォーマンス・チューニングは反復操作です。システム上でボトルネックの影響を軽減したら、2つ目の手順の「パフォーマンス・メトリックの測定」に進み、パフォーマンス目標を満たしているかどうかを判断します。

チューニングのヒント

この項では、システム・パフォーマンス全体をチューニングする際のヒントおよびガイドラインを示します。

- パフォーマンス・チューニングは特効薬ではありません。すなわち、優れたシステム・パフォーマンスは、優れた設計、優れた実装、明確なパフォーマンス目標、およびパフォーマンス・チューニングに基づきます。

- パフォーマンス・チューニングは継続的操作です。設定したパフォーマンス目標に対して比較可能なパフォーマンス・メトリックを提供するメカニズムを実装します。これによって、システムに障害が発生する前にチューニング局面をスケジュールできます。

- 目的は、設定したパフォーマンス目標を満たすことであって、すべてのボトルネックを排除することではありません。システム内のリソースは有限です。本質的に、少なくとも1つのリソース(CPU、メモリー、またはI/O)がシステムのボトルネックになります。チューニングすることによって、設定したパフォーマンス目標に対するボトルネックの影響を軽減できます。

- 次の点を考慮したパフォーマンスを発揮するアプリケーションを設計します。

- 何事もシンプルに保つ - 公開されているパターンを不適切に使用しないでください。

- Java EEのパフォーマンス・パターンを適用します。

- Javaコードを最適化します。

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

この章では、WebLogic Server用にJVMチューニング・オプションを構成する方法について説明します。Java仮想マシン(JVM)は、マイクロプロセッサ上でJavaクラス・ファイルのバイト・コードを実行する仮想の「実行エンジン」インスタンスです。JVMのチューニングは、WebLogic Serverとアプリケーションのパフォーマンスに影響を与えます。

この章には次の項が含まれます:

- JVMのチューニングの考慮事項

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

- 管理対象サーバーのJavaヒープ・サイズの増加

JVMのチューニングの考慮事項

次の表は、WebLogic ServerにおけるJVMのチューニングに関する一般的な考慮事項を示しています。

表4-1 JVMのチューニングの一般的な考慮事項

チューニング事項

参照情報

JVMのベンダーおよびバージョン

WebLogic Serverの動作が確認されている製品JVMだけを使用します。

各プラットフォームの最新の動作確認情報へのリンクは、『Oracle WebLogic Server 12.2.1の新機能』のサポートされている構成に関する項を参照してください。

ヒープ・サイズおよびガベージ・コレクションのチューニング

WebLogic Serverのヒープ・サイズ・チューニングの詳細は、「ガベージ・コレクション」を参照してください。

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

システム・メモリーの管理に使用できるガベージ・コレクションの方式は、アプリケーションによって異なります。詳細は、「ガベージ・コレクションの方式の選択」を参照してください。

クライアント/サーバーJVMの混在

WebLogic Serverでは、クライアントとサーバー用に異なるJVMバージョンを使用したデプロイメントがサポートされています。サポートされているクライアント/サーバーJVMの混在の最新の情報へのリンクは、『Oracle WebLogic Server 12.2.1の新機能』のサポートされている構成に関する項を参照してください。

UNIXスレッディング・モデル

Solarisスレッディング・モデルに関する選択は、Solaris上のJVMのパフォーマンスに大きく影響します。モデル内で複数のスレッディング・モデルと異なる同期方式を選択できますが、これはJVMによって異なります。

Java Hotspot仮想マシンのスレッド用のパフォーマンス・ドキュメント(http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html)を参照してください。

他のJVMへの変更

ドメインを作成する場合、ドメインを実行するJVMを選択すると、構成ウィザードではその選択に基づいてOracle起動スクリプトを構成します。ドメインの作成後、別のJVMを使用する場合、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーを実行するJVMの変更に関する項を参照してください。

ガベージ・コレクション

ガベージ・コレクションは、Javaヒープ内の使用されていないJavaオブジェクトを解放するVMのプロセスです。次の項では、VMのガベージ・コレクションのチューニングに関する情報を示します。

- VMのヒープ・サイズとガベージ・コレクション

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

- verboseガベージ・コレクションを使用したヒープ・サイズの決定

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

- 低メモリー状態の自動的なロギング

- ガベージ・コレクションの手動によるリクエスト

- スレッド・スタックのリクエスト

VMのヒープ・サイズとガベージ・コレクション

Javaヒープは、Javaプログラムのオブジェクトが存在する場所です。ライブ・オブジェクト、デッド・オブジェクト、およびフリー・メモリーのリポジトリです。実行中のプログラムでどのポインタからもアクセスされなくなると、オブジェクトは「ガベージ(廃棄物)」と見なされ、コレクションの対象となります。ベスト・プラクティスとしては、ガベージ・コレクションに費やされる時間を、実行時間の5%以内にチューニングします。

JVMヒープ・サイズによって、ガベージ・コレクションを行う頻度とその時間が決定されます。ガベージ・コレクションの適切な実行頻度はアプリケーションによって異なるので、ガベージ・コレクションの実際の時間と頻度を解析して調整する必要があります。大きいヒープ・サイズを設定した場合、完全ガベージ・コレクションは低速化しますが、実行頻度が低くなります。メモリーのニーズに合わせてヒープ・サイズを設定した場合、完全ガベージ・コレクションは高速化しますが、実行頻度が高くなります。

ヒープ・サイズのチューニングの目標は、WebLogic Serverで所定の時間に処理できるクライアントの数を最大限に増やしつつ、JVMによるガベージ・コレクションの実行時間を最小限に抑えることです。ベンチマーク時に最高のパフォーマンスを確保するには、大きいヒープ・サイズ値を設定し、ベンチマークの実行中にガベージ・コレクションが実行されないようにします。

ヒープ領域が不足している場合、次のJavaエラーが表示されます。

java.lang.OutOfMemoryError <<no stack trace available>>
java.lang.OutOfMemoryError <<no stack trace available>>
Exception in thread "main"

ヒープ領域値を変更するには、「ヒープ・サイズ値の指定」を参照してください。

ヒープ領域の不足を自動的に検出して、サーバーの低メモリー状態を解決するようWebLogic Serverを構成するには、「低メモリー状態の自動的なロギング」および「ヒープ・サイズ値の指定」を参照してください。

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

システム・メモリーの管理に使用するガベージ・コレクションは、どのJVMを使用しているかに応じて複数の方式の中から選択できます。たとえば、特定のタイプのアプリケーションには、それに適したガベージ・コレクションの方式があります。アプリケーションの負荷や、JVMによって使用されるガベージ・コレクション・アルゴリズムの違いを理解すると、ガベージ・コレクションの構成を最適化できます。

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

- SunのHotSpot VMで使用できるガベージ・コレクション方式の概要については、Java SE 6 HotSpot[tm]仮想マシンのガベージ・コレクションのチューニング(http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html)を参照してください。

- コレクション方式の利用に関する全般的な説明については、「Improving Java Application Performance and Scalability by Reducing Garbage Collection Times and Sizing Memory Using JDK 1.4.1」(http://www.oracle.com/technetwork/java/index-jsp-138820.html)を参照してください。

verboseガベージ・コレクションを使用したヒープ・サイズの決定

verboseガベージ・コレクション・オプション(verbosegc)を使用すると、ガベージ・コレクションに費やされる時間とリソースを正確に測定できます。最も効率的なヒープ・サイズを判断するには、診断を目的としてverboseガベージ・コレクションを有効にし、出力をログ・ファイルにリダイレクトします。

次に、この手順を簡単に示します。

1. アプリケーション実行中に、最大の負荷をかけた状態でWebLogic Serverのパフォーマンスをモニターします。

2. -verbosegcオプションを使用してJVMのverboseガベージ・コレクション出力を有効にし、標準エラーおよび標準出力の両方をログ・ファイルにリダイレクトします。
リダイレクトすることにより、スレッド・ダンプ情報がWebLogic Serverの情報メッセージとエラー・メッセージに関連してログに記録されるので、診断する際にログ・ファイルがさらに役立ちます。

たとえば、WindowsおよびSolarisでは次のように入力します。

% java -ms32m -mx200m -verbosegc -classpath $CLASSPATH
-Dweblogic.Name=%SERVER_NAME% -Dbea.home="C:\Oracle\Middleware"
-Dweblogic.management.username=%WLS_USER%
-Dweblogic.management.password=%WLS_PW%
-Dweblogic.management.server=%ADMIN_URL%
-Dweblogic.ProductionModeEnabled=%STARTMODE%
-Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy" weblogic.Server >> logfile.txt 2>&1

logfile.txt 2>&1コマンドは、標準エラーと標準出力の両方をログ・ファイルにリダイレクトします。

3. 次のデータ・ポイントを解析します。

1. ガベージ・コレクションの実行頻度。weblogic.logファイルで、ガベージ・コレクション前後のタイム・スタンプを比較します。

2. ガベージ・コレクションの実行時間。完全ガベージ・コレクションの実行時間は3 - 5秒を上回ってはいけません。

3. 平均メモリー占有量。つまり、各完全ガベージ・コレクション後にヒープがどのような状態になるかです。ヒープの空きが常に85%になる場合、ヒープ・サイズを小さくしてもかまいません。

4. New世代のヒープ・サイズを確認します。「Java HotSpot VMヒープ・サイズのオプション」を参照してください。

5. ヒープ・サイズがシステムの使用可能な空きRAMより大きくならないようにします。
ページがディスクに「スワップ」されない範囲で、できるだけ大きいヒープ・サイズを設定します。システムの空きRAMの容量は、ハードウェアの構成と、そのマシン上で実行されているプロセスのメモリー要件によって異なります。システムの空きRAMの容量の決定については、システム管理者に問い合わせてください。

6. システムがガベージ・コレクションに費やす時間が長すぎる場合(割り当てられた仮想メモリーをRAMが処理できない場合)、ヒープ・サイズを小さくします。
通常、使用可能なRAM (オペレーティング・システムまたはその他のプロセスによって占有されないRAM)の80%をJVMに割り当てます。

7. 使用可能な空きRAMが大量に残っている場合は、そのマシンでより多くのWebLogic Serverインスタンスを実行します。
もう一度確認しますが、ヒープ・サイズのチューニングの目標は、WebLogic Serverで所定の時間に処理できるクライアントの数を最大限に増やしつつ、JVMによるガベージ・コレクションの実行時間を最小限に抑えることです。

ヒープ・サイズ値の指定

システム・パフォーマンスは、JVMで利用可能なJavaヒープのサイズによって大きく影響されます。この節では、ヒープ・サイズ値の定義に使用するコマンド行オプションについて説明します。Javaヒープ・サイズ値は、WebLogic Serverのインスタンスを起動するたびに指定する必要があります。ヒープ・サイズ値は、javaコマンド行から指定するか、WebLogic Server起動用にWebLogic配布キットに付属しているサンプル起動スクリプトのデフォルト値を変更して指定します。

- ヒープ・サイズのチューニングのヒント

- Java HotSpot VMヒープ・サイズのオプション

ヒープ・サイズのチューニングのヒント

次の項では、VMヒープ・サイズのチューニングに関する一般的なガイドラインを示します。

- ヒープ・サイズは、VMによって使用される最大メモリー量が、利用可能な物理的なRAM量を超えないような値に設定する必要があります。この値を超えると、OSがページングを開始するため、パフォーマンスが大幅に低下します。VMでは、常にヒープ・サイズより多いメモリーが消費されます。内部VM機能に必要なメモリー、VMの外部のネイティブ・ライブラリのメモリー、および永続世代メモリー(Sun VMのみ。クラスおよびメソッドの格納に必要なメモリー)が、ヒープ・サイズの設定の他に割り当てられます。

- 世代別ガベージ・コレクション方式を使用する場合、保護領域のサイズは、合計Javaヒープ・サイズの半分を超えないようにする必要があります。一般的には、ヒープ・サイズの25 - 40%が適切です。

- 本番環境では、ヒープを常に拡張したり縮小したりするために使用されるVMリソースを浪費しないように、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定します。これは、New世代のヒープ・サイズにも適用されます。

Java HotSpot VMヒープ・サイズのオプション

最高のパフォーマンスは、アプリケーションを個別にチューニングすることで実現されます。ただし、WebLogic Serverの起動時に、次の表のJava HotSpot VMヒープ・サイズ・オプションを構成すると、ほとんどのアプリケーションでパフォーマンスを向上させることができます。

これらのオプションは、使用するアーキテクチャおよびオペレーティング・システムによって異なります。プラットフォーム別のJVMチューニング・オプションについては、ベンダーのドキュメントを参照してください。

表4-2 Javaヒープ・サイズ・オプション

タスク

オプション

説明

New世代領域のヒープ・サイズを設定する

-XX:NewSize

一般に-XX:NewSizeは、ヒープ・サイズの4分の1のサイズになるように設定します。有効期間の短いオブジェクトが多い場合ほど、このオプションの値を大きくします。

プロセッサ数が増加するほど、New世代領域を大きく設定する必要があります。メモリーの割当ては並列処理できますが、ガベージ・コレクションは並列処理されません。

New世代領域の最大ヒープ・サイズを設定する

-XX:MaxNewSize

New世代領域のヒープ・サイズの最大サイズを設定します。

New世代領域のヒープ・サイズ比率を設定する

-XX:SurvivorRatio

New世代領域は、3つのサブ領域、つまりEdenと、同じサイズの2つのサバイバル領域に分割されます。

Edenとサバイバル領域の比率を構成します。この値は8に設定し、その後、ガベージ・コレクションをモニターするようにします。

ヒープ・サイズの初期値を設定する

-Xms

一般的なルールとしては、ガベージ・コレクションを最小限にするために、ヒープ・サイズの初期値(-Xms)をヒープ・サイズの最大値(-Xmx)と等しく設定します。

最大ヒープ・サイズを設定する

-Xmx

ヒープ・サイズの最大サイズを設定します。

たとえば、javaコマンド行からWebLogic Serverインスタンスを起動する場合、HotSpot VMヒープ・サイズの値は次のように指定できます。

$ java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xms512m -Xmx512m

これらの値のデフォルト・サイズはバイト単位で指定されます。KB (キロバイト)を示すには、値に「k」または「K」を付加します。同様に、MB (メガバイト)を示すには「m」または「M」を、GB (ギガバイト)を示すには「g」または「G」を付加します。上記の例では、New世代およびNew世代の最大ヒープ・サイズに128MB、JVMで実行しているWebLogic Serverインスタンスの最小および最大ヒープ・サイズに512MBを割り当てています。

Java HotSpot VMのその他のオプション

VMのパフォーマンスを向上させるその他の標準および非標準のコマンド行オプションが用意されています。これらのオプションの使用方法は、使用するアプリケーションのコーディングによって異なります。

クライアントJVMとサーバーJVMの両方をテストすると、特定のアプリケーションに対してよりパフォーマンスの優れたオプションを調べることができます。Java HotSpot仮想マシンのパフォーマンス特性に影響を及ぼすコマンド行オプションと環境変数の詳細は、http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.htmlを参照してください。

HotSpot VMオプションのその他の例については次を参照してください:

- Windows (Win32) VM用標準オプション(http://docs.oracle.com/javase/6/docs/technotes/tools/windows/java.html)。

- Solaris VMおよびLinux VM用標準オプション(http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/java.html)。

Java SEのJava仮想マシンのクライアントおよびサーバーの実装の詳細は、Java仮想マシンのドキュメント(http://docs.oracle.com/javase/6/docs/technotes/guides/vm/)に記載されています。

低メモリー状態の自動的なロギング

WebLogic Serverでは、サーバーによって監視した低メモリー状態を自動的にログに記録できます。WebLogic Serverは、使用可能な空きメモリーをある時間間隔内に一定回数サンプリングし、低メモリーを検出します。各間隔の経過時に空きメモリーの平均がログに記録され、次の間隔で取得した平均と比較されます。サンプルの間隔の経過時の平均がユーザーが構成した値より低い場合、サーバーは低メモリー警告をログ・ファイルに記録し、サーバーのヘルス状態を「警告」に設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの低メモリー状態のロギングに関する項を参照してください。

ガベージ・コレクションの手動によるリクエスト

WebLogic Server管理コンソールから完全ガベージ・コレクションを手動でリクエストする必要が生じる場合があります。その場合、JVMがヒープ内のすべての有効なオブジェクトを調べることが多くあるため、ガベージ・コレクションに対してコストがかかることに注意してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのガベージ・コレクションの手動によるリクエストに関する項を参照してください。

スレッド・スタックのリクエスト

アプリケーションをチューニングするときに、スレッド・スタックを表示する必要がある場合があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのスレッド・スタックの表示に関する項を参照してください。

管理対象サーバーのJavaヒープ・サイズの増加

パフォーマンスを向上させるため、環境内の各管理対象サーバーのヒープ・サイズの引き上げが必要になる場合があります。

次の項では、管理対象サーバーのJavaヒープ・サイズを変更する方法について説明します。

- 管理コンソールを使用したJavaヒープ・サイズの設定

- startManagedWebLogicスクリプトの変更によるJavaヒープ・サイズの設定

- コマンド行を使用したJavaヒープ・サイズの設定

- 管理対象サーバーによって使用されるメモリー値の決定

『Oracle WebLogic Serverノード・マネージャの管理』のリモート起動引数の構成に関する項を参照してください。

管理コンソールを使用したJavaヒープ・サイズの設定

ノード・マネージャを使用して管理対象サーバーを起動する場合、「サーバーの起動」タブで、管理対象サーバーごとにヒープ・サイズをJava引数として指定できます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーのJavaヒープ・サイズの増加に関する項を参照してください。ヒープ・サイズ値は、サーバーのstartup.propertiesファイルに保存されます。

startManagedWebLogicスクリプトの変更によるJavaヒープ・サイズの設定

JAVA_OPTIONSに必要なヒープ・サイズを指定して、startManagedWebLogicスクリプトを更新できます。例:

JAVA_OPTIONS="-Xms2g -Xmx2g" ${JAVA_OPTIONS}

『Oracle WebLogic Serverサーバーの起動と停止の管理』の起動スクリプトによる管理対象サーバーの起動に関する項を参照してください。

コマンド行を使用したJavaヒープ・サイズの設定

管理対象サーバーの起動時にJVMパラメータを渡すには、Javaコマンドでweblogic.Serverクラスを起動します。『Oracle WebLogic Serverコマンド・リファレンス』のweblogic.Serverコマンド行リファレンスに関する項を参照してください。

管理対象サーバーによって使用されるメモリー値の決定

起動スクリプトおよび管理コンソール(startup.propertiesファイル)は、管理対象サーバーのメモリー引数を構成するための一般的な方法です。多くの場合、それらは複数の場所で、異なる値で設定されます。実行中の管理対象サーバーで実際にどの値を使用するのかをどのように決定するのでしょうか。

実行中の管理対象サーバーは、常に、起動時にそのサーバーに最後に渡されたメモリー引数のセットを使用します。これは、ログ・ファイルを調べることで確認できます。メモリー引数が複数回リストされている場合、出力の最後のセットに、サーバーによって使用された値が含まれています。管理コンソールを使用して値を設定した場合は、「管理コンソールを使用したJavaヒープ・サイズの設定」を参照してください。startup.propertiesファイルは、常に、すべてのスクリプトの後で最後に処理されています。これは、共通のスクリプトを使用する場合に個別の管理対象サーバーのメモリー・サイズをチューニングする便利な方法を提供します。環境で実際に使用されていないメモリー引数を含めたくない場合、管理対象サーバーの起動に使用されるスクリプトから、MEM_ARGSやJAVA_OPTONSなどの無関係なメモリー引数を削除する必要があります。

5 WebLogic診断フレームワークとJavaフライト・レコーダとの統合のチューニング

この章では、WLDFとJavaフライト・レコーダのチューニング方法について説明します。『Oracle WebLogic Server診断フレームワークの構成と使用』のJavaフライト・レコーダとWLDFの使用に関する項を参照してください。

この章には次の項が含まれます:

- Javaフライト・レコーダの使用

- WLDFの使用

- チューニングの考慮事項

Javaフライト・レコーダの使用

Javaフライト・レコーダは、パフォーマンス監視とプロファイリングを行うツールで、システム・クラッシュなどの壊滅的な障害が発生しても、常に利用可能な状態で継続的に診断情報を記録します。Javaフライト・レコーダは、Oracle HotSpotで使用できます。WebLogic ServerがHotSpotで構成される場合、Javaフライト・レコーダはデフォルトで有効ではありません。WebLogic ServerでJavaフライト・レコーダを有効にする方法については、『Oracle WebLogic Server診断フレームワークの構成と使用』のOracle HotSpotでのJavaフライト・レコーダの使用に関する項を参照してください。

WLDFの使用

WebLogic ServerがOracle HotSpotで構成され、Javaフライト・レコーダを有効にしている場合、Javaフライト・レコーダ・データも診断イメージのキャプチャで自動的に取得されます。このデータは、診断イメージのキャプチャから抽出して、Java Mission Controlで表示できます。Javaフライト・レコーダを有効にしていない場合、またはWebLogic Serverを別のJVMで構成した場合、Javaフライト・レコーダ・データが診断イメージのキャプチャで取得されません。

取得されるJavaフライト・レコーダ・データのボリュームは、WebLogic Server管理コンソールの「診断ボリューム」属性を使用して構成できます。『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDF診断ボリュームの構成に関する項を参照してください。WLSTを使用してもボリュームを設定できます。

チューニングの考慮事項

多くの環境では、「診断ボリューム」を「低」に設定すると、パフォーマンスにほとんど影響はありません。「診断ボリューム」を「高」に設定すると、パフォーマンスに大きな影響があります。WebLogic Serverによって生成された診断データのボリュームを可能性のあるパフォーマンスの損失と比較して検討する必要があります。

6 WebLogic Serverのチューニング

この章では、アプリケーションのニーズに合せてWebLogic Serverをチューニングする方法について説明します。

この章には次の項が含まれます:

- WebLogic Serverを起動するためのJavaパラメータの設定

- 開発モードと本番モードのデフォルトのチューニング値

- デプロイメント

- スレッド管理

- ネットワークI/Oのチューニング

- マルチテナンシ・チューニング推奨事項

- Java式の最適化

- WebLogic Serverクラスタを使用したパフォーマンスの向上

- WebLogic Serverドメインのモニター

- クラスおよびリソースのロードのチューニング

- SSLの考慮事項

WebLogic Serverを起動するためのJavaパラメータの設定

WebLogic Serverを起動するたびに、Javaパラメータを指定する必要があります。簡単な呼出しとしては、コマンド行にweblogic.Serverコマンドを実行して呼出しを行うことができます。ただし、コマンド行からWebLogic Serverを起動するために必要な引数は長くて、間違いやすいため、コマンドをスクリプトに組み込むことをお薦めします。この処理を簡単にするには、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWebLogic ServerインスタンスのJavaオプションの指定に関する項に記載されているように、WebLogic配布によって提供されたサンプル・スクリプトのデフォルト値を変更して、WebLogic Serverを起動します。

構成ウィザードを使用してドメインを作成した場合、WebLogic起動スクリプトはそのドメインを指定したdomain-nameディレクトリに格納されます。このディレクトリは、デフォルトではORACLE_HOME\user_projects\domain\domain-nameとなります。ORACLE_HOMEは、Oracle WebLogic ServerをインストールしたときにOracleホームとして指定したディレクトリ、domain-nameは、選択した構成テンプレートで定義されるドメイン・ディレクトリの名前です。

それらのスクリプトのいくつかのデフォルトJava値は、実際の環境やアプリケーションに合わせて修正する必要があります。これらのファイル内で重要なパフォーマンス・チューニング・パラメータは、JAVA_HOMEパラメータとJavaヒープ・サイズ・パラメータです。

- 変数JAVA_HOMEの値をJDKの位置に変更します。例:

set JAVA_HOME=myjdk_location

ここで、myjdk_locationは、このリリースでサポートされているJDKへのパスです。Oracle Fusion Middlewareのサポートされるシステム構成を参照してください。

- パフォーマンスとスループットをより高めるには、最小Javaヒープ・サイズを最大ヒープ・サイズと同じ大きさに設定します。例:

"%JAVA_HOME%\bin\java" -server –Xms512m –Xmx512m -classpath %CLASSPATH% -

ヒープ・サイズ・オプションの設定の詳細は、「ヒープ・サイズ値の指定」を参照してください。

開発モードと本番モードのデフォルトのチューニング値

ドメインを使用する環境として、開発環境または本番環境のどちらかを指定できます。WebLogic Serverでは、指定した環境の種類に応じて、各種サービスのデフォルト値に異なる値が使用されます。次の表の説明に従って、ドメインの起動モードを指定します。

表6-1起動モード

選択するモード

条件

開発

アプリケーションを作成する場合。このモードではセキュリティの構成がかなり緩和されるので、アプリケーションを自動デプロイできます。

本番

アプリケーションを最終的な形で実行する場合。このモードでは、セキュリティは完全に構成されます。

次の表に、開発起動モードと本番起動モードで異なるパフォーマンス関連の構成パラメータを示します。

表6-2 開発モードと本番モードの相違点

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

開発モード

本番モード

SSL

WebLogic Serverセキュリティ・サービスによって提供されるデモンストレーション・デジタル証明書とデモンストレーション・キーストアを使用できます。これらの証明書を使用すると、SSLで保護された環境で動作するアプリケーションを設計できます。

セキュリティ管理の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。

デモンストレーション・デジタル証明書とデモンストレーション・キーストアは使用しないでください。これを行うと、警告メッセージが表示されます。

アプリケーションのデプロイ

domain_name/autodeployディレクトリにあるアプリケーションをWebLogic Serverインスタンスで自動的にデプロイおよび更新できます(domain_nameはドメイン名)。

この方法は、単一サーバーの開発環境でのみ使用することを推奨します。

詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の開発ドメインでのアプリケーションの自動デプロイに関する項を参照してください。

自動デプロイメントの機能は無効化されているので、WebLogic Server管理コンソール、weblogic.DeployerツールまたはWebLogic Scripting Tool (WLST)を使用する必要があります。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のWebLogic Serverのデプロイメントの理解に関する項を参照してください。

Webサービスのテスト・クライアント

デフォルトで有効になっています。

デフォルトで無効(およびアンデプロイ)になっています。『Webサービスの管理』のWebサービスのテスト・クライアントの有効化と無効化に関する項を参照してください。

開発から本番への起動モードの切替えについては、『Oracle WebLogic Serverサーバー環境の管理』のドメイン・モードに関する項を参照してください。

デプロイメント

次の項では、デプロイメントのパフォーマンスを向上させる方法について説明します。

- 内部アプリケーションのオンデマンド・デプロイメント

- FastSwapデプロイメントによる再デプロイメント時間の短縮

- 汎用オーバーライド

内部アプリケーションのオンデマンド・デプロイメント

WebLogic Serverでは、起動時に、多くの内部アプリケーションがデプロイされます。この内部アプリケーションの多くは、すべてのユーザーに必要なわけではありません。これらのアプリケーションをサーバーの起動時に常にデプロイするのではなく、最初のアクセス時に(必要に応じて)待機およびデプロイするようにWebLogic Serverを構成できます。これにより、デプロイメント時のメモリーとCPU時間が節約されるとともに、サーバーの起動時間が向上しメモリー占有量が少なくなります。開発ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってオンデマンドでデプロイされます。本番モード・ドメインの場合、デフォルトでは、内部アプリケーションがWLSによってサーバー起動時にデプロイされます。この機能を使用および構成する方法については、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の内部アプリケーションのオンデマンド・デプロイメントに関する項を参照してください。

FastSwapデプロイメントによる再デプロイメント時間の短縮

デプロイメント・モードでは、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するようWebLogic Serverを設定できます。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。

汎用オーバーライド

汎用オーバーライドでは、アプリケーション固有のファイルをオプションのAppFileOverridesサブディレクトリにオーバーライドすることで、jarファイルを展開せずにアプリケーション固有のプロパティ・ファイルをオーバーライドできます。この機能を使用および構成する方法については、『WebLogic Serverへのアプリケーションのデプロイ』の汎用ファイル・ロード・オーバーライドに関する項を参照してください。

スレッド管理

WebLogic Serverは、作業を実行するスレッドを管理するための次のメカニズムを備えています。

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

- ワーク・マネージャと実行キューの相違の理解

- 以前のリリースからの移行

- スタック・スレッドの検出動作のチューニング

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

このリリースのWebLogic Serverでは、アプリケーションがどのような優先度で作業を実行するかを構成できます。ユーザーが定義したルールと実際の実行時パフォーマンスのモニター結果に基づいて、アプリケーションのパフォーマンスが最適化され、サービス・レベル・アグリーメント(SLA)が維持されます。

サーバー・インスタンスによるスレッドの利用方法をチューニングするには、ワーク・マネージャを定義して、WebLogic Serverドメインにグローバルに適用するか、特定のアプリケーション・コンポーネントに適用することにより、アプリケーションに対してルールや制約を定義します。主なチューニングの考慮事項は以下のとおりです。

- 必要なワーク・マネージャの数

- 各ワーク・マネージャのSLA要件

『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。

必要なワーク・マネージャの数

各SLA要件ごとに一意のワーク・マネージャが必要です。

各ワーク・マネージャのSLA要件

サービス・レベル合意の(SLA)の要件は、リクエスト・クラスのインスタンスによって定義されます。リクエスト・クラスは、サーバー・インスタンスによってスレッドの割当てのために使用されるスケジューリング・ガイドラインを表します。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャの理解に関する項を参照してください。

ワーク・マネージャと実行キューの相違の理解

以前のリリースの実行キューとワーク・マネージャの相違点を概念的に理解する最も簡単な方法は、実行キュー(厳密に言えば、実行キュー・マネージャ)をワーク・マネージャと関連付けて、実行キューとスレッド・プールの間の1対1の関係を切り離すことです。

WebLogic Server 9.0より前のリリースでは、着信するリクエストはデフォルトの実行キューまたはユーザー定義の実行キューに入れられます。各実行キューには実行キュー・マネージャが関連付けられています。実行キュー・マネージャは、一定数のスレッドを持つ排他的な専用のスレッド・プールを制御します。リクエストは先着順でキューに追加されます。実行キュー・マネージャは、キューから最初のリクエストを取り出し、関連付けられたスレッド・プールから使用可能なスレッドを1つ取得して、そのスレッドで実行するようにリクエストをディスパッチします。

WebLogic Server 9.0以降のリリースでは、優先度に基づいた実行キューがサーバー内に1つ用意されます。着信するリクエストには、アプリケーションが実行する作業を管理するためにユーザーが作成するワーク・マネージャの構成に基づいて、内部的な優先度が割り当てられます。サーバーでは、様々なワーク・マネージャのリクエストに応じて、実行キューで使用できるスレッドを増やしたり減らしたりします。実行キュー内のリクエストの位置は、そのリクエストの内部的な優先度によって決まります。

- 優先度が高いほど、実行キューの先頭近くに置かれます。

- キューの先頭に近いほど、使用するスレッドに早くディスパッチされます。

ワーク・マネージャを使用すると、実行キューの場合より、スレッドの利用方法(サーバーのパフォーマンス)をうまく制御できます。その主な理由は、優先度に基づいたスレッド・プールに対してスケジューリング・ガイドラインを指定する様々な方法が用意されていることです。スケジューリング・ガイドラインは、数値として設定することも、サーバーが管理するリソース(JDBC接続プールなど)の容量として設定することもできます。

以前のリリースからの移行

実行キューを含む以前のリリースからアプリケーション・ドメインをアップグレードすると、移行後の9.xドメインにも実行キューが含まれています。

- 以前のリリースからWebLogic Server 9.xにアプリケーション・ドメインを移行する場合、実行キューはワーク・マネージャに自動的に変換されません。

- アップグレードされたアプリケーション構成に実行キューが存在する場合、サーバー・インスタンスは作業リクエストをdispatch-policyで指定された実行キューに適切に割り当てます。

- dispatch-policyのないリクエストでは、自動チューニング・スレッド・プールが使用されます。

『Oracle WebLogic Serverのアップグレード』のアプリケーション環境をアップグレードするためのロードマップに関する項を参照してください。

スタック・スレッドの検出動作のチューニング

WebLogic Serverは、実行キューのスレッドが「スタック」状態になるとこれを自動的に検出します。スタック・スレッドは現在の作業を終了したり新しい作業を承認したりできないため、サーバーはスタック・スレッドを診断するたびに、メッセージのロギングを行います。

WebLogic Serverは、一定の時間にわたって継続して動作している(アイドル状態ではない)スレッドをスタックしていると診断します。スレッドがスタック・スレッドと診断されるまでの時間を変更すること、および、サーバーがスタック・スレッドを確認する頻度を変更することで、サーバーのスレッド検出動作をチューニングできます。スレッドがスタックされているかどうかを判断するためにWebLogic Serverが使用する基準は変更できますが、特定の実行キューのすべてのスレッドがスタック状態になったときに「警告」および「クリティカル」のヘルス状態を設定するデフォルトの動作は変更できません。詳細は、『Oracle WebLogic Serverサーバー環境の管理』の過負荷状態を回避するためのWebLogic Serverの構成に関する項を参照してください。スタック・スレッド検出動作を構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの実行スレッド検出動作のチューニングに関する項を参照してください。

ネットワークI/Oのチューニング

次の項では、クライアントとサーバーの間のネットワーク通信(T3やIIOPプロトコル、およびそれらのセキュア・バージョン)に関して説明します。

- マキサーのチューニング

- ネットワーク・チャネル

- サービス妨害攻撃の可能性の低減

- 接続バックログのバッファリングのチューニング

- キャッシュされた接続のチューニング

マキサーのチューニング

WebLogic Serverは、マキサーと呼ばれるソフトウェア・モジュールを使用して、サーバーでの受信リクエストとクライアントでの受信レスポンスを読み込みます。WebLogic Serverは、次のマキサー・タイプをサポートします。

- 非ブロッキングIOマキサー

- その他のマキサー

非ブロッキングIOマキサー

WebLogic Serverでは、非ブロッキングIOマキサー実装がデフォルトのマキサー構成として用意されています。デフォルト構成では、MuxerClassはweblogic.socket.NIOSocketMuxerに設定されます。

その他のマキサー

ネイティブ・マキサーおよびJava Muxerは、大部分の環境では推奨されません。これらのマキサーを有効化する必要がある場合は、MuxerClass属性の値を次のように明示的に設定する必要があります。

- Solaris/HP-UXネイティブ・マキサー: weblogic.socket.DevPollSocketMuxer

- POSIXネイティブ・マキサー: weblogic.socket.PosixSocketMuxer

- Windowsネイティブ・マキサー: weblogic.socket.NTSocketMuxer

- Java Muxer: weblogic.socket.JavaSocketMuxer

たとえば、WindowsプラットフォームでネイティブNTソケット・マキサーに切り替えると、WebLogic Serverインスタンスへのソケット接続が1つの場合に、大きなメッセージ/ペイロードに対して、パフォーマンスを向上できる可能性があります。

-Dweblogic.MuxerClass=weblogic.socket.NTSocketMux

POSIXネイティブ・マキサーは、SolarisやHP-UXなどポーリング・システム呼出しをサポートするUNIXに類似したシステムにおける大きなメッセージ/ペイロードに対して、同様のパフォーマンスの向上を提供します。

-Dweblogic.MuxerClass=weblogic.socket.PosixSocketMuxer

ネイティブ・マキサー

一方、ネイティブ・マキサーは、プラットフォーム固有のネイティブ・バイナリを使用して、ソケットからデータを読み込みます。大多数のプラットフォームには、データに関してソケットをポーリングする何らかのメカニズムがあります。たとえば、UNIXシステムではポーリング・システム呼出しが使用され、Windowsアーキテクチャでは完了ポートが使用されます。ネイティブ・マキサーでは、非ブロッキング・スレッド・モデルが実装されているため、優れたスケーラビリティが提供されます。ネイティブ・マルチプレクサが使用されると、サーバーでは受信リクエストの読取り専用の固定数のスレッドが作成されます。

ネイティブ・マキサーでは、次の設定を使用すると、CPUにバインドされたアプリケーション(SpecJAppServerなど)のスループットを向上できる場合があります。

-Dweblogic.socket.SocketMuxer.DELAY_POLL_WAKEUP=xx

xxは、データが使用可能かどうかをチェックする前に遅延する時間です(マイクロ秒単位)。デフォルト値は0で、遅延なしに相当します。

Javaマキサー

Javaマキサーには次の特徴があります。

- ソケットからのデータの読込みにpure-Javaが使用されます。

- RMIクライアントで利用可能な唯一のマキサー。

- ソケットから読み込まれるデータが現れるまで読込みはブロックされます。この動作は、ソケットが大量に存在する場合や、ソケットにデータが到達する頻度が低い場合は、あまり効率がよくありません。これは、クライアントでは通常問題になりませんが、サーバーで大きなボトルネックになる場合があります。

これらの特徴は、クライアントの数が少なく、サーバーに届く要求のレートが非常に高いときに受諾できる場合があります。これらの条件下では、Java Muxerはネイティブ・マキサーと同様のパフォーマンスを発揮し、Javaネイティブ・インタフェース(JNI)のオーバーヘッドが解消されます。ネイティブ・マキサーと異なり、Java Muxerでは、リクエストの読込みに使用されるスレッドの数は固定されず、WebLogic Server管理コンソールのPercent Socket Readersパラメータ設定を構成することで調整できます。理想的には、スレッドの数がリモートの同時に接続されたクライアントの数とほぼ同じ(最高でも合計スレッド・プール・サイズの50%まで)となるようにこのパラメータを構成する必要があります。各スレッドは、ソケットでデータが利用できるようになるまで一定の時間だけ待機します。到着するデータがない場合、スレッドは次のソケットに移動します。

ネットワーク・チャネル

ネットワーク・チャネル(ネットワーク・アクセス・ポイントとも呼ばれる)では、ネットワーク通信の様々なサービス品質(QOS)パラメータを指定できます。各ネットワーク・チャネルは、固有IPアドレスおよびポートを使用して、排他的な独自のソケットに関連付けられます。デフォルトでは、マルチスレッド・クライアントからのT3リクエストが同じリモート接続に対して多重化され、サーバー・インスタンスがソケットからのリクエストを1つずつ読み込みます。リクエストのサイズが大きい場合、これがボトルネックになります。

ネットワーク・チャネルの主な役割はサーバー・インスタンスのネットワーク・トラフィックを制御することですが、複数のカスタム・チャネルを作成できる機能を利用すると、マルチスレッド・クライアントが、複数の接続に対してサーバー・インスタンスと通信でき、ボトルネックの危険性が軽減されます。カスタム・マルチチャネル通信を構成するには、次の手順に従います。

1. 様々なIPおよびポート設定を使用して複数のネットワーク・チャネルを構成します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください。

2. クライアント側のコードで、クラスタ環境で使用されるパターンに似たJNDI URLパターンを使用します。次に、2つのネットワーク・チャネルを使用したクライアントでの例を示します。

t3://<ip1>:<port1>,<ip2>:<port2>

『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

サービス妨害攻撃の可能性の低減

WebLogic Serverでは、システムの可用性を最適化すると同時にサービス妨害(DoS)攻撃の可能性を低減するために次の設定を指定することができます。

- 受信メッセージの最大サイズ

- 完了メッセージ・タイムアウト

- ファイル記述子数(UNIXシステム)

システムのパフォーマンスを最大限にするために、次の項に記載されているように、WebLogic Serverをホストする特定のシステムでこれらの設定が適切で、お互いにバランスが取れてる必要があります。

メッセージ・サイズのチューニング

WebLogic Serverを使用すると、一連の大きなリクエストが攻撃に遭わないように受信リクエスト最大のサイズを指定できます。別々のプロトコルとネットワーク・チャネルに対してグローバルの値または特定の値を設定できます。パフォーマンスには直接的に影響しませんが、宛先へ送信する前にJMSアプリケーションに収集されたメッセージのサイズが指定した値より大きい場合、そのJMSアプリケーションは拒否される場合があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: プロトコル: 一般に関する項、および順序単位を使用したアプリケーションのチューニングに関する項を参照してください。

完了メッセージ・タイムアウトのチューニング

「完了メッセージ・タイムアウト」パラメータがシステムで正しく構成されていることを確認します。このパラメータを使用すると、サーバーが完了メッセージを受信するまでに待機する最大秒数を設定できます。

デフォルト値は60秒で、デフォルト・ネットワーク・チャネルのすべての接続プロトコルに適用されます。サーバーに待機時間の長いクライアントが多くある場合、この設定が適切である場合があります。ただし、システムの可用性を侵害することなく、この設定を可能なかぎり小さな値にする必要があります。

特定のプロトコルのために完了メッセージ・タイムアウトを指定する必要がある場合、かわりに、そのプロトコルに対して新しいネットワーク・チャネルを構成できます。

完了メッセージ・タイムアウト・パラメータを指定できる「WebLogic Server管理コンソール」ページの表示の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのプロトコルの構成に関する項を参照してください。

ファイル記述子数のチューニング

UNIXシステムでは、WebLogic Serverへの各ソケット接続がファイル記述子を消費します。可用性を最適化するには、ホスト・マシン上のWebLogic Serverのファイル記述子数が適切である必要があります。デフォルトでは、WebLogic Serverには、1024個ファイル記述子数が構成されています。ただし、特に本番システムでは、この値は小さく設定される場合があります。

WebLogic Serverのファイル記述子数をチューニングする場合、ファイル記述子に行った変更は「完了メッセージ・タイムアウト」パラメータに行った変更とバランスが取れている必要があります。「完了メッセージ・タイムアウト」パラメータの値が大きい場合、メッセージ・タイムアウトが発生するまでソケットが閉じられません。これにより、ファイル記述子の保留時間が長くなります。したがって、「完了メッセージ・タイムアウト」パラメータの値が大きい場合、ファイル記述子数の制限も大きく設定する必要があります。これにより、システムの可用性が最適化され、サービス妨害攻撃の可能性を低減できます。

使用可能なファイル記述子数のチューニング方法については、UNIXベンダーのドキュメントを参照してください。

接続バックログのバッファリングのチューニング

追加のリクエストを拒否する前にWebLogic Serverのインスタンスが受け取る接続リクエスト数をチューニングできます。「バックログの受入れ」パラメータは、待機キューにバッファできるTransmission Control Protocol (TCP)接続数を指定します。この固定サイズ・キューは、TCPスタックで受信し、アプリケーションではまだ受け取られていない接続リクエストに追加されます。

WebLogic Serverのインスタンスで追加のリクエストを否定する前に、受け取る接続リクエスト数をチューニングできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続バックログ・バッファのチューニングに関する項を参照してください。

キャッシュされた接続のチューニング

HTTP 1.1プロトコルでキープ・アライブが有効な場合に、キャッシュからソケット接続を返す動作のチューニング用のhttp.keepAliveCache.socketHealthCheckTimeoutシステム・プロパティを使用します。デフォルトでは、キャッシュされた接続がクライアントに返され使用できるようになるまで、キャッシュはヘルス状態をチェックしません。ネットワーク接続が不安定な場合などの一定の条件では、クライアントに返す前にシステムが接続ヘルス状態をチェックする必要があります。この動作(ヘルス状態のチェック)を有効にするには、http.keepAliveCache.socketHealthCheckTimeoutを0より大きい値に設定します。

マルチテナンシ・チューニング推奨事項

多数のコアを持つシステムの重い負荷で複数のパーティションを実行している場合、CPU使用率を向上するためにWLSスレッド・プールの設定をいくつか変更する必要がある場合があります。スレッド・プールのチューニングはスループットを向上し、レスポンス時間を削減し、CPU使用率を向上します。

次のガイドラインを開始点として考慮する必要があります。特定のワークロードの最適設定を見つけるためには、様々な値を試みる必要があります。

- マルチプレクサ・スレッド(ソケット・リーダー)
マルチプレクサ・スレッドには、受信するネットワーク・リクエストを処理し、それを適切なワーク・スレッドにディスパッチする役割があります。ネイティブ・マルチプレクサ(通常、デフォルト・マルチプレクサ)では、WLSはかなり少ない(4つの)マルチプレクサ・スレッドを使用しますが、この値はコアの高いカウント・システムのスループット容量を保つには十分ではありません。

WLSサーバーでマルチプレクサ・スレッドの数を増やす方法は次のとおりです。

- ServerMBean.setSocketReaders(N)を使用して設定するか、

- サーバーの起動時に次のJAVA_OPTIONを渡して設定します: -Dweblogic.SocketReaders=N

ソケット・リーダーの数を確認するには、サーバーの起動時にログ・メッセージ: Allocating N reader threadsを参照します。

はじめに、マルチプレクサ・スレッドの数をシステム・ハードウェア・スレッドの数のおよそ20%になるように設定してみます。

- スレッド・プール
スレッド・プールは、マルチプレクサ・スレッドによってリクエストがディスパッチされた後、WLSで作業するようにスレッドを割り当てる役割を持ちます。デフォルトでは、WLSは自動チューニング・プールを使用し、これは一般的に様々なワークロードで良好に動作しますが、一定の高負荷の環境では、スレッド・プール・サイズをチューニングしてサーバーのコアの数と適合させた方が効率的な場合があります。

WLSサーバーでスレッド・プール設定を変更する手順は次のとおりです。

- ServerMBean.setSelfTuningThreadPoolSizeMin(N)およびsetSelfTuningThreadPoolSizeMax(N)を使用して設定するか、

- サーバーの起動時に次のJAVA_OPTIONを渡して設定します: -Dweblogic.threadpool.MinPoolSize=N -Dweblogic.threadpool.MaxPoolSize=N

はじめに、スレッド・プールの最小サイズと最大サイズをシステム・ハードウェア・スレッドの数のおよそ80%になるように設定してみます。

様々な数のパーティションに対してリソース消費管理(RCM)が有効な場合、パフォーマンスを向上させるために、WLSではシステム・プロパティweblogic.work.rcm.perPartitionPoolSizeが導入され、各パーティション・プール・サイズをチューニングできます。

RCMが有効な場合、WLS自己チューニング・スレッド・プールは、以前にパーティションで作業リクエストを実行したスレッドを使用して、同一のパーティションで次の作業リクエストを実行します。WLSでは、各パーティションのスレッドのキャッシュが保持されます。このキャッシュのデフォルト・サイズは、16スレッドです。weblogic.work.rcm.perPartitionPoolSizeシステム・プロパティを使用して、キャッシュ・サイズを構成できます。指定する場合、1から256の間の値に指定し、これは最も近い2の倍数に切り捨てられます。値が小さいとメモリー使用量が減少し、大きい値は作業リクエストを実行するためのキャッシュ済スレッドを同一パーティションから検出できるチャンスが高くなります。

リソース共有のトピックに関する詳細は、『WebLogic Server MTの使用』のリソース消費管理の構成に関する項を参照してください。

Java式の最適化

optimize-java-expression要素を設定すると、Java式を最適化して実行時パフォーマンスを向上させることができます。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のjsp-descriptorに関する項を参照してください。

WebLogic Serverクラスタを使用したパフォーマンスの向上

WebLogic ServerクラスタはWebLogic Serverインスタンスのグループで、互いに連携してフェイルオーバーおよびレプリケーション・サービスを提供することにより、ドメイン内のクライアントに対してスケーラブルで可用性の高い運用をサポートします。クラスタはそのクライアントにとって単一のサーバーに見えますが、実際にはスケーラビリティと信頼性を向上するために一体で機能するサーバー群です。

ドメインには複数のWebLogic Serverクラスタと、クラスタリングされないWebLogic Serverインスタンスが存在できます。ドメイン内でクラスタリングされるWebLogic Serverインスタンスの動作は、フェイルオーバーとロード・バランシングの機能を備えること以外は、クラスタリングされないインスタンスと同様です。インスタンスのすべての構成パラメータは、そのインスタンスがクラスタリングされるかどうかにかかわらず、そのドメインの管理サーバーによって管理されます。

クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogic Serverクラスタの理解に関する項を参照してください。

スケーラビリティと高可用性

スケーラビリティとは、リソースの追加に伴ってシステムが1つまたは複数の側面において拡張していく能力です。通常、これらの側面としては(他にも多数ありますが)サポート可能な同時接続ユーザーの数や、一定時間に処理可能なトランザクションの数などが挙げられます。

優れたアプリケーションであれば、単にリソースを追加することによってパフォーマンスが向上します。WebLogic Serverの負荷処理の機能を強化するには、新しいWebLogic Serverインスタンスをクラスタに追加します。その際、アプリケーションを変更する必要はありません。クラスタは、単一のサーバーでは提供できない、スケーラビリティと可用性という2つの大きなメリットをもたらします。

WebLogic Serverクラスタは、アプリケーション開発者からは見えないように、Java EEアプリケーションにスケーラビリティと高可用性を提供します。スケーラビリティにより中間層の能力が拡張され、単一のWebLogic Serverまたはコンピュータの能力を超過することができます。クラスタ・メンバーシップの唯一の制限は、すべてのWebLogic ServerがIPマルチキャストで通信できなければならないということです。新しいWebLogic Serverをクラスタに動的に追加して能力を増大させることもできます。

WebLogic Serverクラスタは、複数サーバーの冗長性を利用してクライアントを障害から保護することで高可用性を確保します。クラスタ内の複数のサーバーで、同じサービスを提供できます。1つのサーバーで障害が発生しても、別のサーバーが引き継ぎます。障害が発生したサーバーから機能しているサーバーへのフェイルオーバー機能によって、クライアントに対するアプリケーションの可用性が増大します。

注意:
すべてのアプリケーションおよび環境上のボトルネックが解決済という条件下で初めて、クラスタへの新しいサーバーの追加により、直線的なスケーラビリティが実現されます。ベンチマークまたは初期構成テストを実行するときには、単一サーバー環境における問題を洗い出した後で、クラスタリングされた環境に移行してください。

メッセージング・サービスでのクラスタ化は、分散宛先、接続のコンセントレータ、接続のロード・バランシング(接続ファクトリのターゲット指定によって決定されます)、およびクラスタリング・ストア・アンド・フォワード(SAF)を介して提供されます。分散宛先に関するクライアントのロード・バランシングは、接続ファクトリで調整できます。分散宛先をホストする同じクラスタにターゲット指定されている分散宛先のメッセージドリブンBean (MDB)は、分散宛先のメンバーをホストするクラスタ・サーバーでのみ自動的にデプロイし、それらのローカル宛先からのメッセージのみ処理します。分散宛先のホストとは異なるサーバーまたはクラスタにターゲット指定されている分散キューMDBは、各分散宛先メンバーに対してコンシューマを自動的に作成します。たとえば、実行中の各MDBは、各分散宛先キュー・メンバーに対して1つのコンシューマを持ちます。

WebLogicクラスタのスケーラビリティを確保する方法

一般的に、クラスタ内のサーバー間で通信を必要とする処理は、スケーラビリティの潜在的な障害となります。次の項では、クラスタリングWebLogicサーバーを直線的にスケーリングする際に影響のある問題について説明します。

- データベースのボトルネック

- セッション・レプリケーション

- 非同期HTTPセッション・レプリケーション

- エンティティEJBの無効化

- HTTPセッションの無効化

- JNDIのバインド、アンバインド、およびリバインド

データベースのボトルネック

WebLogicサーバーのクラスタがスケーリングに失敗する多くの状況では、データベースがボトルネックとなっています。こうした状況における唯一のソリューションとして、データベースをチューニングするか、他のオプションを調査してデータベース上の負荷を軽減します。第8章「データベースのチューニング」および第11章「データ・ソースのチューニング」を参照してください。

セッション・レプリケーション

ユーザー・セッション・データは、2つの標準的な方法(ステートフル・セッションEJBまたはHTTPセッション)で、Java EEアプリケーションに格納できます。これらだけで、クラスタのスケーラビリティが影響されることはほとんどありません。ただし、高可用性を提供するために必要なセッション・レプリケーション・メカニズムと組み合わされると、ボトルネックが発生します。Java EEアプリケーションにWebおよびEJBコンポーネントがある場合、次の理由から、ユーザー・セッション・データはHTTPセッションに格納する必要があります。

- HTTPセッション管理では、レプリケーション、共有DBまたは共有ファイルなど、フェイルオーバーを処理するためのオプションが多数提供されます。

- スケーラビリティが優れています。

- HTTPセッションの状態のレプリケーションは、すべてのトランザクションの外部で発生します。一方、ステートフル・セッションBeanのレプリケーションは、よりリソースが消費されるトランザクション内部で発生します。

- HTTPセッションのレプリケーション・メカニズムは高度に洗練され、ステートフル・セッションBeanのレプリケーションよりも広範な状況で最適化を実現します。

「セッション管理」を参照してください。

非同期HTTPセッション・レプリケーション

HTTPセッションの非同期レプリケーションでは、以下を使用する非同期セッション・レプリケーションを選択できます。

- セカンダリ・サーバーを使用する非同期HTTPセッション・レプリケーション

- データベースを使用する非同期HTTPセッション・レプリケーション

セカンダリ・サーバーを使用する非同期HTTPセッション・レプリケーション

PersistentStoreTypeをasync-replicatedまたはasync-replicated-if-clusteredに設定して、プライマリ・サーバーとセカンダリ・サーバー間でのデータの非同期レプリケーションを指定します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータを調整します。

レプリケーションの動作は、クラスタのタイプによって異なります。次の表では、特定のクラスタ・トポロジでの非同期レプリケーションの動作について説明します。

表6-3 クラスタ・トポロジでの非同期レプリケーションの動作

トポロジ

動作

LAN

同一クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。

MAN

リモートのクラスタのセカンダリ・サーバーにレプリケートされます。これは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。

WAN

クラスタ内のセカンダリ・サーバーへのレプリケーションは、Webアプリケーションで「async-replication」が設定されていると非同期的に発生します。リモートのクラスタを介するデータベースの永続性は、「async-replication」と「replication」のどちらが選択されていても非同期的に発生します。

次に、非同期レプリケーション・セッションの動作の概要を示します。

- アンデプロイメント時または再デプロイメント時は、次のように動作します。

- セッションが登録解除され、更新キューから削除されます。

- セカンダリ・サーバー上のセッションが登録解除されます。

- アプリケーションが管理モードに移行している場合、セッションはフラッシュされてセカンダリ・サーバーへレプリケートされます。セカンダリ・サーバーが停止している場合は、システムは別のサーバーへのフェイルオーバーを試みます。

- セッション情報の消失の可能性を最小限に抑えるため、サーバーが停止したり障害が発生したりするとバッチ処理されたセッションのレプリケーションが発生します。

データベースを使用する非同期HTTPセッション・レプリケーション

PersistentStoreTypeをasync-jdbcに設定して、データのデータベースへの非同期レプリケーションを指定します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「session-descriptor」を参照してください。バッチ処理されたレプリケーションをチューニングするには、SessionFlushThresholdパラメータおよびSessionFlushIntervalパラメータを調整します。

次に、非同期レプリケーション・セッションの動作の概要を示します。

- アンデプロイメント時または再デプロイメント時は、次のように動作します。

- セッションが登録解除され、更新キューから削除されます。

- セッションがデータベースから削除されます。

- アプリケーションが管理モードに移行している場合、セッションはフラッシュされてデータベースへレプリケートされます。

エンティティEJBの無効化

これは、読み書きパターン付きReadOnlyまたはOptimisticの並行性戦略を使用するエンティティEJBに適用されます。

Optimistic - Optimistic並行性が更新されると、EJBコンテナはマルチキャスト・メッセージを他のクラスタ・メンバーに送信し、それらのBeanのローカル・コピーを無効化します。これは、オプティミスティックな並行性の例外が他のサーバーによってスローされるのを防ぐ(それによってトランザクションを再試行する必要性を回避する)ために行われます。EJBに対する更新が頻繁に行われる場合、お互いのローカル・キャッシュを無効化するためにサーバーによって行われる処理が、重大なボトルネックになります。こうした無効化をオフにするには、cluster-invalidation-disabledと呼ばれるフラグ(デフォルトはfalse)を使用します。これは、rdbms記述子ファイルで設定します。

読み書きパターン付きReadOnly - このパターンでは、さもなければ単一EJBによって表される永続データが、実際には次の2つのEJBによって表されます。読込み専用EJBと更新可能EJBです。更新可能Beanの状態が変更されると、コンテナは対応する読取り専用EJBインスタンスを自動的に無効化します。EJBに対する更新が頻繁に行われる場合、読取り専用EJBを無効化するためにサーバーによって行われる処理が、重大なボトル・ネックになります。

HTTPセッションの無効化

「エンティティEJBの無効化」と同様、HTTPセッションも無効化できます。これについては、無効化する必要があるのはセカンダリ・サーバーに格納されているセッション・データのみなので、エンティティEJBの無効化ほどコストがかかりません。HTTPセッションがもう使用されていない場合、無効化する必要があります。

JNDIのバインド、アンバインド、およびリバインド

一般的に、JNDIのバインド、アンバインド、およびリバインドは高価な処理です。ただし、これらの処理は、クラスタ環境ではJNDIツリーの変更をクラスタのすべてのメンバーに伝播する必要があるため、大きなボトルネックになります。こうした処理が頻繁に実行される場合、クラスタのスケーラビリティが大幅に縮小する場合があります。

マルチ・コア・マシン上でのマルチ・サーバー・インスタンスの実行

マルチ・コア・マシンについては、クラスタリングされたWebLogic Serverインスタンスと使用可能なコア数の比率を考慮する必要があります。WebLogic Serverには、クラスタ内のサーバー・インスタンス数の制限が組み込まれていないため、大規模なマルチ・コア・サーバーでは、非常に大規模なクラスタまたは多くのクラスタをホストする可能性があります。

WebLogic Serverインスタンスに対するコアの最適な比率を決定するときに次の事項を考慮してください。

- アプリケーションのメモリー要件。個別インスタンスのヒープ・サイズとインスタンスの総合数を選択して、アプリケーションに十分なメモリーが提供されていて、よいガベージ・コレクション(GC)パフォーマンスが達成できることを確認します。いくつかのアプリケーションでは、単一のインスタンスに非常に大きなヒープ・サイズを割り当てると、ガベージ・コレクション(GC)の休止時間が長くなる場合があります。この場合は、インスタンス数を増加し、各インスタンスに小さいヒープを割り当てると、パフォーマンスが向上する場合があります。

- CPUの最大使用。WebLogic Serverでは、インスタンスごとに複数のコアを使用できるので、いくつかのアプリケーションにおいて指定したマシン上のインスタンス数を増加(インスタンスごとにコア数の減少)すると、CPUの使用とパフォーマンスを向上できます。

XAトランザクション・クラスタ・アフィニティを使用したクラスタ・スループットの向上

XAトランザクション・クラスタ・アフィニティによって、グローバル・トランザクションに参加しているサーバー・インスタンスが、関連するリクエストを他のメンバー・サーバーにロード・バランシングしないで処理できるようになります。Enable Transaction Affinity=trueの場合、クラスタ・スループットは次のようにすることによって増加します。

- サーバー間トランザクション調整トラフィックの削減

- JDBC接続の削減など、リソース使用率の向上

- トランザクションの非同期処理の単純化

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成に関する項および『Oracle WebLogic Serverクラスタの管理』のXAトランザクション・アフィニティに関する項を参照してください。

WebLogic Serverドメインのモニター

次の項では、WebLogic Serverドメインのモニター方法を説明します。

- 管理コンソールでのWebLogic Serverのモニター

- WebLogic診断フレームワークの使用

- JMXでのWebLogic Serverのモニター

- WLSTでのWebLogic Serverのモニター

管理コンソールでのWebLogic Serverのモニター

管理コンソールは、WebLogic Serverドメインのヘルス状態とパフォーマンスをモニターするツールです。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバーの監視に関する項を参照してください。

WebLogic診断フレームワークの使用

WebLogic診断フレームワーク(WLDF)は、監視および診断フレームワークであり、WebLogic Serverのプロセス内で実行する一連のサービスの定義および実装を行い、標準サーバー・ライフ・サイクルに参加します。『Oracle WebLogic Server診断フレームワークの構成と使用』のWLDFアーキテクチャの概要に関する項を参照してください。

JMXでのWebLogic Serverのモニター

WebLogic Serverでは、独自の一連のMBeansが提供されています。これらを使用して、WebLogic Serverリソースを構成、モニターおよび管理することができます。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。

WLSTでのWebLogic Serverのモニター

WebLogic Scripting Tool (WLST)はコマンド行スクリプト・インタフェースです。システム管理者およびオペレータは、このインタフェースでWebLogic Serverのインスタンスやドメインの監視と管理を行います。『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。

WebLogic Serverをモニターするためのリソース

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

クラスおよびリソースのロードのチューニング

WebLogic Serverにおけるデフォルトのクラスおよびリソースのロードでは、デフォルトでクラスローダーの階層がルートから検索されます。その結果、クラスまたはリソースがアプリケーションに属している場合でも、クラスまたはリソースのロードが要求されるたびにシステム・クラスパス全体が検索されます。一度だけルックアップされるクラスやリソース(デプロイメント時のクラス・ロードなど)の場合は、classpath全体の検索にかかる負荷が重大な問題となることは通常はありません。実行時にアプリケーションによって繰返し要求されるクラスやリソース(loadClassまたはgetResourceの明示的な呼出し)の場合は、システムやアプリケーションの長いclasspathが繰り返し検索されることでCPUやメモリーのオーバーヘッドが増大する可能性があります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。クラスまたはリソースが見つからない場合はclasspathの全体スキャンの負荷が発生し、アプリケーションがクラス/リソースの検索に失敗するとリクエストが繰り返される可能性があるため、さらに負荷が高まります。要求されたクラスまたはリソースが見つからない場合、問題はさらに重大となります。

見つからないクラスまたはリソースのリクエストおよび同じクラス/リソースをロードするために頻繁に繰り返される呼出しは回避されるよう、アプリケーション・コードが最適化されているのが理想です。サード・パーティのライブラリなど、アプリケーション・コードの修正が可能でない場合は、WebLogic Serverの「フィルタリング・ローダー・メカニズム」を使用します。

フィルタリング・ローダー・メカニズム

WebLogic Serverでは、ローダーをフィルタするメカニズムが用意されています。このメカニズムを使用すると、アプリケーションのclasspathにある特定のアプリケーション・クラスとリソースを検索するときにシステムclasspathの検索を省略できます。このメカニズムでは、ユーザーはシステム・クラスパスの検索を省略する特定のクラスとリソースを指定する必要があります。『Oracle WebLogic Serverアプリケーションの開発』のフィルタリング・クラスローダーの使用に関する項を参照してください。

このリリースでは、リソースをロードするリクエストをフィルタリングできる機能が追加されました。リソース・フィルタリングの基本的な構成は、META-INF/weblogic-application.xmlファイルで指定します。クラス・フィルタリングの場合も同様です。リソースをフィルタリングする構文の例を以下に示します。

<prefer-application-resources>
<resource-name>x/y</resource-name>
<resource-name>z*</resource-name>
</prefer-application-resources>

この例では、「x/y」という名前のリソースと「z」で名前が始まるリソースにリソース・フィルタリングが構成されています。使用できるワイルド・カードのパターンは「*」のみです。これらのパターンに一致する名前を持つリソースはアプリケーション・クラスパス上でのみ検索され、システム・クラスパスの検索はスキップされます。

注意:
フィルタリング構成にクラスまたはリソースを追加した後で、クラスまたはリソースが見つからないことを示す例外が発生した場合は、クラスまたはリソースがアプリケーション・クラスパス上ではなくシステム・クラスパス上に存在している可能性があります。

クラス・キャッシング

WebLogic Serverは、起動を高速化するためにクラス・キャッシングを有効にできます。キャッシングを有効にすると、サーバーは特定の基準に達するまでロードされるすべてのクラスを記録し、クラス定義を非表示のファイルに保持します。サーバーを再起動すると、キャッシュの有効性が既存のコード・ソースによりチェックされます。そして、サーバーは実行回数に記録されたクラスと同じ一連のクラスをバルク・ロードするためキャッシュ・ファイルを使用します。システム・クラスパスまたはその内容を変更すると、キャッシュは無効になり、サーバー再起動時に再作成されます。

クラス・キャッシングを使用する利点は次のとおりです。

- サーバーの起動時間が短縮されます。

- パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。

詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシングの構成に関する項を参照してください。

注意:
startWebLogicスクリプトを使用することで、クラス・キャッシュはサーバーの起動時に開発モードでサポートされます。デフォルトでは、クラス・キャッシングは無効になっており本番モードではサポートされません。開始時間の短縮はJREベンダーによって異なります。

SSLの考慮事項

WebLogic ServerがJDK 7で構成される場合、即時利用可能なSSLのパフォーマンス速度が以前のWebLogic Serverリリースよりも低下する場合があります。このパフォーマンスの変化は、JDK 7がWebLogic ServerでJSSEベースのSSLプロバイダとともに使用される場合にデフォルトで使用される、より強力な暗号とMACアルゴリズムが原因で起こります。『Oracle WebLogic Serverセキュリティの管理 12c (12.2.1)』のSSLパフォーマンスの考慮事項に関する項を参照してください。

7 WebLogic永続ストアのチューニング

この章では、永続ストアをチューニングする方法について説明します。永続ストアは、永続性が必要なWebLogic Serverのサブシステムおよびサービスに高性能な組込みストレージ・ソリューションを提供します。

この章には次の項が含まれます:

- 永続ストアの概要

- 永続ストア使用時のベスト・プラクティス

- JDBCストアのチューニング

- ファイル・ストアのチューニング

- ネットワーク・ファイル・システムの使用

この章を読み込む前に、WebLogicストアの管理と監視についてよく知っておくことをお薦めします。WebLogic永続ストアの管理のWebLogic永続ストアの使用方法に関する項を参照してください。

永続ストアの概要

次の項では、永続ストアの使用方法について説明します。

- デフォルト永続ストアの使用方法

- カスタム・ファイル・ストアとJDBCストアの使用方法

- JDBC TLOGストアの使用

- JMSページング・ストアの使用方法

- 診断ストアの使用方法

デフォルト永続ストアの使用方法

管理サーバーを含め、すべてのサーバー・インスタンスには、構成が不要なデフォルトの永続ストアがあります。デフォルト・ストアはファイルベースのストアで、サーバー・インスタンスのdata\store\defaultディレクトリに格納された一連のファイルにデータを保持します。デフォルト・ストア用のディレクトリは、存在しない場合には自動的に作成されます。このデフォルト・ストアは、特定のストアを明示的に選択する必要がなく、システムのデフォルトのストレージ・メカニズムを使用することで最適に動作するサブシステムから使用することができます。たとえば、永続ストアが構成されていないJMSサーバーは、管理対象サーバー用のデフォルトのストアを使用して永続メッセージングをサポートします。次を参照してください:

- WebLogic永続ストアの管理のWebLogic永続ストアの使用方法に関する項。

- Oracle WebLogic Server管理オンライン・コンソール・オンライン・ヘルプのデフォルト・ストアの設定の変更に関する項。

カスタム・ファイル・ストアとJDBCストアの使用方法

デフォルトのファイル・ストアを使用するだけでなく、特定のニーズに合わせてファイル・ストアやJDBCストアを構成することもできます。デフォルト・ファイル・ストアと同様、カスタム・ファイル・ストアもディレクトリに格納された一連のファイルにデータを保持します。一方、特定のストレージ・デバイスにデータを保持するカスタム・ファイル・ストアを作成することもできます。ファイル・ストアのディレクトリを構成する場合は、そのファイル・ストアが配置されているサーバー・インスタンスにアクセスできるディレクトリを設定する必要があります。

JDBCストアは、リレーショナル・データベースをストレージとして使用している場合に構成できます。JDBCストアを使用することで、指定のJDBCデータ・ストアを介してアクセスできる標準のJDBC対応データベースに永続メッセージを格納できます。JDBCストアのデータベース表に格納されたデータには、WLStoreという論理名が付けられます。データベースの高可用性とパフォーマンスを構成するかどうかは、データベース管理者の判断です。次を参照してください:

- WebLogic永続ストアの管理のカスタム永続ストアの使用タイミングに関する項。

- WebLogic永続ストアの管理のファイル・ストアとJDBCストアの比較に関する項。

- WebLogic永続ストアの管理のカスタム(ユーザー定義)ファイル・ストアの作成に関する項。

- WebLogic永続ストアの管理のJDBCストアの作成に関する項。

JDBC TLOGストアの使用

JDBC TLOGストアを構成してトランザクション・ログがデータベースに永続化されるようにできます。これによって、ベースとなるデータベースのレプリケーションとHA特性を利用したり、障害時リカバリを簡易化したり、トランザクション・リカバリ・サービスの移行を改善できます。WebLogic永続ストアの管理のJDBC TLogストアの使用に関する項を参照してください。

JMSページング・ストアの使用方法

各JMSサーバーではファイルベースのページング・ストアが暗黙的に作成されます。このストアは、WebLogic Server JVMが低メモリー状態で動作しているときに、非永続性メッセージおよび永続メッセージのページングに使用されます。ページング・ストアを使用すると、アプリケーションによってはディスク・アクティビティが増大することがあります。

オプションで、ページングが開始するしきい値設定およびディレクトリの場所を変更できます。可能な場合、一時ディレクトリなどローカルなファイル・システムにページング・ストア・ディレクトリの場所を指定すると、パフォーマンスを向上できます。ページング・ストア・ファイルはJMSサーバーを再起動するたびに自動的に再読込みされるので、どこからでもアクセスできる場所にバックアップ、レプリケートまたは配置する必要はありません。『Oracle WebLogic Server JMSリソースの管理』のWebLogic Server 9.x以上でのJMSサーバー動作に関する項を参照してください。

注意:
ページングされた永続メッセージは、次の2つの場所に格納される可能性があります。

- 通常は、デフォルト・ストアまたはカスタム・ストア。

- 場合によっては、ページング・ディレクトリ。

フラッシュ・ストレージを使用したJMSメッセージのページング

ローカルでマウントされたエンタープライズクラスのフラッシュ・ストレージ・デバイス上のディレクトリを参照するようJMSサーバーのページング・ディレクトリを構成すると、多くの場合、JMSメッセージ(永続または非永続)のページングのパフォーマンスを向上させることができます。これは、他のテクノロジよりも大幅に速い可能性があります。

注意:
ほとんどのフラッシュ・ストレージ・デバイスは単一障害点で、通常、ローカル・デバイスとしてのみアクセス可能です。障害の後にデータをリカバリしたり、必要に応じて自動的に再構築したりしないJMSサーバーのページング・ディレクトリとしては適しています。
安全にリカバリできる必要のあるデータが通常含まれるカスタム・ストアやデフォルト・ストアとしては、ほとんどの場合、フラッシュ・ストレージ・デバイスは適していません。デフォルト・ストアまたはカスタム・ストアのDirectory属性の構成で、通常は単一障害点のデバイス上のディレクトリを参照しないようにします。

フラッシュ・ストレージ・デバイスを使用してJMSメッセージをページングするには、次の手順を使用します。

1. JMSサーバーのメッセージ・ページング・ディレクトリ属性をフラッシュ・ストレージ・デバイスのパスに設定します。「メッセージ・ページング・ディレクトリの指定」を参照してください。

2. 「メッセージ・バッファ・サイズ」属性(ページングのアクティブ化を制御)をチューニングします。高速のI/O処理によって負荷を吸収できる場合、より低いしきい値を使用できます。「「メッセージ・バッファ・サイズ」オプションのチューニング」を参照してください。

3. JMSサーバーの割当てをチューニングし、フラッシュ・ストレージの領域の制限に対応します。これによって、JMSサーバーで、デバイスに格納できる以上のメッセージをページングしなくなります。場合によっては、実行時エラーや自動停止が発生することがあります。控えめな目安として、ページ・ファイルの使用量は、最低1.5 * ((アクティブなメッセージの最大数) * (512 + メッセージ本文の最大サイズ)) (16MB単位で切上げ)と想定します。「割当ての定義」を参照してください。

診断ストアの使用方法

診断ストアは、ファイル・ストアで、暗黙的に「無効化された」同期書込みポリシーを使用します。診断ストアは、WebLogicサーバーの診断情報を格納します。WebLogicサーバーのインスタンスごとに1つの診断ストアが構成されています。『Oracle WebLogic Server診断フレームワークの構成と使用』の診断アーカイブの構成を参照してください。

永続ストア使用時のベスト・プラクティス

- 同じサーバー・インスタンスを共有するサブシステムでは、サブシステムごとにストアを使用するのではなく複数のサブシステムで1つのストアを共有します。ストアを共有すると、次の理由から効率性が高まります。

- 同時発生する複数のリクエストを1つのストアで1つのI/Oにまとめることで、全体のディスク使用率が減少します。

- 参加するリソースが1つだけのトランザクションは軽量の1フェーズ・トランザクションです。逆に、複数のストアが関与するトランザクションは、より重い2フェーズ・トランザクションになります。

たとえば、同じサーバー・インスタンスで動作するすべてのSAFエージェントやJMSサーバーは、同じストアを共有するように構成します。

- 古いストア(群)を拡張しなくなった場合にのみ、新しいストアを追加します。

JDBCストアのチューニング

次の項では、JDBCストアのチューニングについて説明します。

- JDBCストアのI/O負荷が高い場合、複数のJDBC接続を使用してI/O操作を同時に処理するようJDBCストアを構成すると、パフォーマンスが向上します。WebLogic永続ストアの管理のJDBCストアのI/Oマルチスレッドの有効化に関する項を参照してください。

- Oracle BLOBを使用する場合、ThreeStepThreshold値をチューニングすると、パフォーマンスが向上することがあります。WebLogic永続ストアの管理のOracle BLOBレコード列の有効化に関する項を参照してください。

- 空のストアを初期化するために使用されるJDBCストアDDLの場所は、構成できるようになっています。これにより、データベース表を作成するためのカスタムDDLを簡単に使用できるようになっています。このDDLはデータベースの特定のパフォーマンス・チューニングに使用されることもあります。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストアの作成に関する項と、WebLogic永続ストアの管理のWebLogic永続ストアの使用に関する項を参照してください。

ファイル・ストアのチューニング

次の項では、ファイル・ストアのチューニングについて説明します。

- 基本的チューニングの情報

- ファイル・ストアの直接書込み - キャッシュありポリシーのチューニング

- ファイル・ストアの直接書込みポリシーのチューニング

- ファイル・ストア・ブロック・サイズのチューニング

基本的チューニング情報

次の項では、ファイル・ストアのチューニングに関する一般的な情報を提供します。

- 基本的な(非RAIDの)ディスク・ハードウェアの場合、ファイル・ストアごとに1つの専用のディスクを使用することを検討します。ディスク上の別のストアと競合しなくてよい場合、ストアの処理速度は4 - 5倍上昇します。構成された各ストアや各JMSサーバー用のJMSページング・ストアの他に、デフォルト・ファイル・ストアがあることに留意してください。

- カスタムとデフォルトのファイル・ストアの場合は、同期書込みポリシーをチューニングします。

- 「直接書込み - キャッシュあり」、「直接書込み」および「キャッシュ・フラッシュ」の3つのトランザクションの安全な同期書込みポリシーがあります。「直接書込み - キャッシュあり」は、これらのポリシーのうち最もパフォーマンスがよく、「キャッシュ・フラッシュ」は、最もパフォーマンスの悪いポリシーです。「直接書込み」は、デフォルトです。他のポリシーとは異なり、「直接書込み - キャッシュあり」は、プライマリ・ファイルに加えてキャッシュ・ファイルを作成します。

- 「無効化された」同期書込みポリシーは、トランザクションで安全ではありません。「無効化された」書込みポリシーを使用すると、特にクライアント負荷が低いときに、パフォーマンスを大幅に向上します。ただし、書込みポリシーは、システムの開始時および停電のときに非同期になって、データが失われる可能性があるので、安全ではありません。

- WebLogic永続ストアの管理の同期書込みポリシーの構成のガイドラインに関する項を参照してください。

注意:
以前のバージョンのMicrosoft Windowsでは、WindowsのデフォルトのWrite Cache Enabled設定を使用すると、ストレージ・デバイスの同期書込みの完了は正しく報告されません。システム・クラッシュや停電が発生したときは、レコードやメッセージが失われたり、重複されたりするからです。これにより、直接書込み(デフォルト)または直接書込み - キャッシュありポリシーで構成されたファイル・ストアを含む、トランザクション製品(Oracleに固有でない)のトランザクション・セマンティクスが違反されます。ストレージ・デバイスの物理的な機能を超える高い永続メッセージ/トランザクション・スループットの場合、この問題が現れます。この問題を対処するには、Microsoftが提供するパッチを適用するか、WindowsのWrite Cache Enabled設定を無効にするか、または電源保護のあるストレージ・デバイスを使用します。http://support.microsoft.com/kb/281672およびhttp://support.microsoft.com/kb/332023を参照してください。

- ベンダーを直接的に比較する場合、永続ストアの書込みポリシーをすべて同等のポリシーにします。WebLogic以外の一部のベンダーには、デフォルトで「無効」に相当する動作をするものがあります。

- 同期書込みポリシーに応じて、カスタム・ストアとデフォルト・ストアには、複数の追加のチューニング可能な属性があります。これにより、パフォーマンスが向上する可能性があります。これには、CacheDirectory、MaxWindowBufferSize、IOBufferSize、BlockSize、InitialSizeおよびMaxFileSizeなどがあります。詳細は、Oracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。

注意:
JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。

- ディスク・パフォーマンスがボトルネックの状況が続く場合、組込みのライトバック・キャッシュを備えたディスク・コントローラ・ハードウェアまたはRAIDコントローラ・ハードウェアの購入を検討します。これらのキャッシュで一時的に永続データを揮発性のメモリーへ保存すると、大幅にパフォーマンスが向上します。ライトバック・キャッシュでのトランザクションを確実に安全なものにするには、ライトバック・キャッシュを停電、ホスト・マシン障害、およびオペレーティング・システム障害から保護する必要があります。このような保護機能は通常、バッテリ・バックアップのあるライトバック・キャッシュで提供されます。

ファイル・ストアの直接書込み - キャッシュありポリシーのチューニング

「直接書込み - キャッシュあり」同期書込みポリシーは、通常最もパフォーマンスのよいオプションで、トランザクション上安全なディスク書込みが行われます。通常は、「無効」同期書込みポリシーほどパフォーマンスはよくありませんが、「無効」ポリシーは、システム障害の発生時にバッファされた書込みが失われないようにする方法がない場合、本番システムに対して安全なオプションではありません。

直接書込み - キャッシュありファイル・ストアは、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期して書込みます。また、ファイル・ストアは、ファイル・ストアの構成のCacheDirectory属性で定義された場所にある、対応するキャッシュ・ファイルにも非同期に書込みます。キャッシュ・ディレクトリとプライマリ・ファイルは、別々の目的に使用され、異なる場所に存在する必要があります。多くの場合は、プライマリ・ファイルは、高可用性のためにリモート記憶域に格納されている必要があります。キャッシュ・ファイルは、高可用性ではなく、厳密にパフォーマンスのために使用されるので、ローカルな場所に格納できます。

「直接書込み - キャッシュあり」同期書込みポリシーを選択すると、次の複数の追加のチューニング・オプションを考慮する必要があります。

- CacheDirectoryの設定。パフォーマンスのためにキャッシュ・ディレクトリがローカルなファイル・システムに存在する必要があります。デフォルトでは、オペレーティング・システムのtempディレクトリに存在しています。

- MaxWindowBufferSizeおよびIOBufferSize属性の増加。これらの属性は、ファイル・ストアのネイティブなメモリー使用量をチューニングします。

- InitialSizeおよびMaxFileSize属性の増加。これらの属性は、それぞれストアの初期サイズとストア内の特定のファイルの最大サイズをチューニングします。

- BlockSize属性のチューニング。「ファイル・ストアのブロック・サイズのチューニング」を参照してください。

個別のチューニング・パラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項を参照してください。

フラッシュ・ストレージの使用によるパフォーマンスの向上

エンタープライズクラスのフラッシュ・ドライブを使用すると、リアルタイム・アプリケーションでのデータのアクセスが回転式ディスクより大幅に速くなり、他のタスクの処理にメモリーを使用できるため、I/Oのパフォーマンスを向上させることができます。

単に、フラッシュ・ストレージ・デバイスのパスを使用してCacheDirectory属性を更新するのみです。ストアのプライマリ・ファイルの完全なコピーを格納するのに十分な空き領域が、デバイスにあることを確認します。Oracle WebLogic Server MBeanリファレンスのCacheDirectory属性に関する項を参照してください。

追加の考慮事項

直接書込み - キャッシュありポリシーをチューニングする際には、次の項目を考慮する必要があります。

- 直接書込み - キャッシュあり同期書込みポリシーを使用する場合は、さらにセキュリティおよびファイル・ロッキングの考慮事項がある場合があります。『Oracle WebLogic Server本番環境の保護』、およびOracle WebLogic Server MBeanリファレンスのJMSFileStoreMBeanに関する項のCacheDirectory属性とLockingEnabled属性を参照してください。

- JMSFileStoreMBeanは非推奨ですが、個別のbean属性が、カスタムとデフォルト・ファイル・ストアの非推奨ではないbeansに適用されます。

- ストアが実行されていないときにキャッシュ・ディレクトリを削除すると安全ですが、次回ストアを起動するときに時間がかかる場合があります。ストアのホストWebLogicサーバーが(kill -9の後でもOS/JVMのクラッシュの後でもなく)現在の起動の前に正常にシャットダウンされた場合かつプライマリ・ファイル(たとえば、ストアの管理圧縮ファイル)にオフライン変更がなかった場合は、キャッシュ・ファイルを再利用して、ファイル・ストアの起動とリカバリ・プロセスを迅速化することができます。既存のキャッシュ・ファイルを起動するときに安全に使用できない場合、それらは自動的に破棄されて新しいファイルが作成されます。また、「ログ280102」という警告が作成されます。移行またはフェイルオーバーのイベント後、同じ警告メッセージが作成されますが、無視できます。

- 直接書込み - キャッシュありファイル・ストアを使用して、wlfileioのネイティブ・ドライバのロードに失敗した場合、同期書込みポリシーは自動的に同等の直接書込みに変更され、AvoidDirectIO=trueになります。実行中のカスタムまたはデフォルトのファイル・ストアの構成済および実際の同期書込みポリシーとドライバを表示する場合は、サーバーのログでWL-280008およびWL-280009のメッセージを参照してください。

- 未使用のキャッシュ・ファイルがディスク領域を消費しないようにする場合、一時的に作成されたドメインに残されたキャッシュ・ファイルを定期的に削除するようにテスト環境と開発環境を変更する必要がある場合があります。本番環境では、ファイル・ストアによってキャッシュ・ファイルが自動的に管理されます。

ファイル・ストアの直接書込みポリシーのチューニング

非推奨の注意:
この項に記載されているAvoidDirectIOのプロパティは、このリリースでもサポートされていますが、11gR1PS2以降は非推奨になります。「直接書込み」ポリシーの代替として、構成可能な「直接書込み - キャッシュあり」同期書込みポリシーを使用してください。

直接書込みの同期書込みポリシーによるファイル・ストアの場合は、Oracleサポートまたはリリース・ノートにおいて、weblogic.Serverのオプションをコマンド行設定するか、またはストアを実行するJVMのスクリプトを起動するように指示されます。

- JVMで実行しているすべてのストアをグローバルに変更します。

-Dweblogic.store.AvoidDirectIO=true

- シングル・ストアの場合に使用します。ここでは、store-nameは、ストアの名前を示します。

-Dweblogic.store.store-name.AvoidDirectIO=true

- デフォルトのストアの場合に使用します。ここでは、server-nameは、ストアをホストするサーバーの名前を示します。

-Dweblogic.store._WLS_server-name.AvoidDirectIO=true

AvoidDirectIOを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.AvoidDirectIOの設定がオーバーライドされます。たとえば、AおよびBという2つのストアがあり、次のオプションを設定しているとします:

-Dweblogic.store.AvoidDirectIO=true
-Dweblogic.store.A.AvoidDirectIO=false

この場合、ストアBの場合のみAvoidDirectIO=trueの設定があります。

注意:
AvoidDirectIOオプションを設定すると、パフォーマンスに影響を及ぼします。これは、「ファイル・ストアのブロック・サイズのチューニング」に記載されているように、通常、ブロックのサイズを設定すると軽減されます。

ファイル・ストア・ブロック・サイズのチューニング

特にファイル・ストアの直接書込みポリシーのチューニングに記載されているように、直接書込みをAvoidDirectIO=trueで使用する場合、または物理記憶域待機時間によりパフォーマンスが限定されているハードライブ・ベースのライト・バック・キャッシュを持つシステムの場合は、同期書込みポリシーの直接書込み(デフォルト)、直接書込み - キャッシュありまたはキャッシュ・フラッシュを使用して構成されたファイル・ストアのファイル・ストア・ブロック・サイズをチューニングしてください。

次のケースについて検討します。

- 単一のWebLogic JMSプロデューサは永続メッセージを1つずつ送信します。

- ネットワークのオーバーヘッドは、ごくわずかであることが分かっています。

- ファイル・ストアのディスク・ドライブの回転速度は10,000 rpmです。

- ディスク・ドライブはバッテリ・バックアップのあるライトバック・キャッシュを備えています。

また、メッセージ・レートは1秒間に166メッセージと測定されています。

このケースでは、バッテリ・バックアップのあるライトバック・キャッシュによって高いメッセージ・レートが可能なように思われますが、実際のレートは低く、ディスク・ドライブの待機時間(10,000 rpm/60秒、つまり166 rps)と同じ数値になります。ストアのブロック・サイズをファイル・システムのブロック・サイズと一致するようチューニングすることで、大幅な改善が可能です。

以下のようなケースでは、ブロック・サイズをチューニングしても全く改善が見られなかったり、改善したとしても不十分であったりする可能性があります。

- キャッシュによって待機時間が小さくなっています(つまり、I/Oサブシステムは重大なボトルネックではありません)。

- ライトバック・キャッシングが使用されておらず、ディスク・ドライブの待機時間が大きいため、パフォーマンスが制限されています。

使用しているブロック・サイズが大きい場合は、パフォーマンスとファイル・スペースの間にトレード・オフが存在する可能性があります。複数のアプリケーション・レコードは、同時に書き込まれた場合にのみ、単一のブロックにまとめられます。そのためブロック・サイズを大きくすると、サーバー・アクティビティが同時に実行されることがほとんどなく、小さいレコードしか生成されないアプリケーションの場合、ストア・ファイルのサイズが大幅に増大することになります。この場合、小さいレコードがブロックごとに1つずつ格納され、各ブロックの残りのスペースは使用されません。例として、100バイト長の小さなメッセージを送信する単一のプロデューサを含む、Web Service Reliable Messaging (WS-RM)アプリケーションが挙げられます。ここでは、ストアを使用するのはアプリケーションだけです。

パフォーマンスを向上するために、ストアのブロック・サイズをファイル・ストアをホストするファイル・システムのブロック・サイズと一致するように、チューニングすることをお薦めします(一般的に、多くのファイル・システムの場合、4096)。または、ブロック・サイズをその他の値にチューニングしても(ページングおよびキャッシュ・ユニット)パフォーマンスを向上する場合があります。ブロック・サイズをチューニングして、パフォーマンスが向上されない場合、ブロック・サイズをデフォルトのままに設定しておくことをお薦めします。これにより、ファイル・システム・リソースの使用を最小化することができます。

ファイル・ストアのブロック・サイズの設定

非推奨の注意:
この項に記載されているBlockSizeコマンド行プロパティは、11gR1PS2でもサポートされていますが、非推奨です。かわりに、カスタムおよびデフォルトのファイル・ストアに構成可能なBlockSizeを使用することをお薦めします。

ストアのブロック・サイズを設定するには、次のいずれかのプロパティをコマンド行で使用するか、または、ストアを実行するJVMのスクリプトを起動してください。

- 既存するファイルを持たないすべてのファイル・ストアのブロック・サイズをグローバルに設定します。

-Dweblogic.store.BlockSize=block-size

- 既存のファイルを持たない特定のファイル・ストアのブロック・サイズを設定します。

-Dweblogic.store.store-name.BlockSize=block-size

- ファイル・ストアに既存のファイルがない場合、デフォルトのファイル・ストアのブロック・サイズを設定します。

-Dweblogic.store._WLS_server-name. BlockSize=block-size

ブロック・サイズは、512から8192の間の整数を設定します。最も近い2の倍数に自動的に切り捨てられます。

BlockSizeを個別のストアに設定すると、グローバルなオプションの-Dweblogic.store.BlockSizeの設定がオーバーライドされます。たとえば、AおよびBという2つのストアがあり、次のオプションを設定しているとします:

-Dweblogic.store.BlockSize=8192
-Dweblogic.store.A.BlockSize=512

この場合、ストアBのブロック・サイズは、8192になり、ストアAのブロック・サイズが512になります。

注意:
コマンド行プロパティを使用したブロック・サイズの設定は、既存のファイルを持たないファイル・ストアでのみ可能です。ストアに既存のファイルが存在する場合は、ストアの最初の作成時に設定されたブロック・サイズがそのまま使用されます。

ファイル・ストア・ブロック・サイズの確認

ファイル・ストアの現在のブロック・サイズおよび同期書込みポリシーは、ストアをホストするサーバーのサーバー・ログで確認することができます。「280009」のストアがオープンされたというメッセージを検索してください。

ファイル・システム・ブロック・サイズの確認

ファイル・システムの現在のブロック・サイズを確認するには、使用しているオペレーティング・システムのドキュメントを参照してください。例:

- Linux ext2およびext3ファイル・システムの場合: /sbin/dumpe2fs /dev/ボリューム名を実行し、「Block size」を検索します。

- Windows NTFSの場合: fsutil fsinfo ntfsinfo ボリューム名:を実行し、「Bytes Per Cluster」を検索します。

既存のファイルが存在するストアの変換

ストアの既存のファイルのデータを保持する必要がない場合は、ホストのWebLogic Serverインスタンスを停止してファイルを削除すれば、ストアを再起動した際にブロック・サイズを変更できます。データを保持する必要がある場合は、新しいブロック・サイズを指定したファイル・ストアを作成して、既存のファイルが存在するストアのブロック・サイズを変換します。その際は、コマンド行ストア管理ユーティリティのcompactコマンドを使用します。

1. java -Dweblogic.store.BlockSize=block-size weblogic.store.Admin

2. helpと入力して、使用可能なコマンドを確認します。

3. Storeadmin->compact -dir file-store-directory

WebLogic永続ストアの管理のJavaコマンド行を使用したストア管理に関する項を参照してください。

ネットワーク・ファイル・システムの使用

次の項では、ネットワーク・ファイル・システム(NFS)でのWebLogic永続ストアの使用方法について説明します。

- 同期書込みポリシーの構成

- サーバーの再起動の動作のテスト

- NFSのロック・エラーの処理

同期書込みポリシーの構成

NFS記憶域は、同期書込みリクエストが揮発性メモリーに警告なしでバッファされるように構成されているので、トランザクション・データを完全に保護しない場合があります。ファイル・ストアのディレクトリがNFSマウントに存在して、ファイル・ストアの同期書込みポリシーが「無効化された」以外である場合、NFS実装と構成をチェックして、同期の書込みがサポートされるように構成されていることを確認します。「無効化された」の同期書込みポリシーを使用すると、同期書込みが行われていないので、一般的にはトランザクションで安全ではありません。記憶域デバイスの物理機能を超える最大数の永続メッセージまたはトランザクション・スループットを表示すると、同期書込みリクエストの不要なバッファリングが発生する可能性があります。NFSサーバーで、ファイル・ストアをホストするエクスポート済のNFSディレクトリの同期書込み設定をチェックします。SANベースのファイル・ストアまたはJDBCストアでは、安全な集中型の記憶域を提供する簡単な方法が用意されている場合があります。

サーバーの再起動の動作のテスト

NFS搭載のディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンが不意に障害したら、サーバーの再起動の動作を検証することをお薦めします。NFS実装に応じて、フェイルオーバーまたは再起動後、様々な問題が発生する可能性があります。Web Logicサーバーの実行中に、Web Logicサーバーをホストするノードを突然にシャットダウンして、動作を検証できます。サーバーの移行のためにサーバーが構成されている場合、対応するフェイルオーバー期間後、フェイルオーバー・ノード上でサーバーが自動的に起動する必要があります。起動しない場合は、同じホスト(ノードが完全に起動した後)上のWebLogicサーバーを手動で再起動します。

NFSのロック・エラーの処理

注意:
サーバーの移行を完了するのに必要なおおよその時間内にロックを解放するよう、NFS v4ベースのネットワーク接続ストレージ(NAS)サーバーを構成できます。NFS v4環境をチューニングしてテストする場合、この項の手順に従う必要はありません。ストレージ・デバイス上のNFSマウントされたディレクトリに格納されたファイルのロックに関する情報については、ストレージ・ベンダーのドキュメントを参照してください。

NFSマウントされたディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンの突然の障害後、Oracle WebLogic Serverが再起動されないと、サーバーのログ・ファイルに次のエラーが表示されることがあります。

例7-1 ストアの再起動の失敗エラー・メッセージ

MMM dd, yyyy hh:mm:ss a z> <Error> <Store> <BEA-280061> <The persistent store "_WLS_server_soa1" could not be deployed:
weblogic.store.PersistentStoreException: java.io.IOException:
[Store:280021]There was an error while opening the file store file "_WLS_SERVER_SOA1000000.DAT"
at weblogic.store.io.file.Heap.open(Heap.java:168)
at weblogic.store.io.file.FileStoreIO.open(FileStoreIO.java:88)
...
java.io.IOException: Error from fcntl() for file locking, Resource temporarily unavailable, errno=11

NFSシステムがストア上のロックを解放しないために、このエラーが発生します。WebLogicサーバーでは、同じWebLogicサーバーの2つのインスタンスを誤って起動した場合、データが破損しないように、JMSデータとトランザクション・ログを格納するファイルでのロックが維持されます。NFSストレージ・デバイスは、マシンに障害が発生したことを適切なタイミングで認識しないので、ロックを解放しません。その結果、マシンに障害が発生しマシンの再起動後、WebLogicサーバーが前にロックされたファイルをロックしようとすると、失敗します。ストレージ・デバイス上のNFS搭載ディレクトリに格納されたファイルのロックに関する追加の情報については、ストレージ・ベンダーのドキュメントを参照してください。NFS環境でロック動作を適正にチューニングできない場合は、次の2つの方法で、ログ・ファイルおよびデータ・ファイルのロックを解除します。

次の2つの方法のいずれかで、ログ・ファイルおよびデータ・ファイルのロックを解除します。

- 方法1: データ・ファイルをコピーしてNFSロックの削除

- 方法2: WebLogic Serverのファイル・ストア内のファイル・ロックの無効化

方法1: データ・ファイルをコピーしてNFSロックの削除

ログおよびJMSデータ・ファイルを手動でロック解除し、ロック済の永続ストア・ファイルのコピーを作成してサーバーを起動し、その後の操作のために以前に作成したコピーを使用します。ロック済の永続ストア・ファイルのコピーを作成するには、ファイルの名前を変更し、再度元の名前にコピーします。次のサンプルでは、トランザクション・ログが/shared/tlogsディレクトリおよびJMSデータが/shared/jmsディレクトリに格納されると仮定します。

例7-2 NFSロックを削除するためのサンプル・ステップ

cd /shared/tlogs
mv _WLS_SOA_SERVER1000000.DAT _WLS_SOA_SERVER1000000.DAT.old
cp _WLS_SOA_SERVER1000000.DAT.old _WLS_SOA_SERVER1000000.DAT
cd /shared/jms
mv SOAJMSFILESTORE_AUTO_1000000.DAT SOAJMSFILESTORE_AUTO_1000000.DAT.old
cp SOAJMSFILESTORE_AUTO_1000000.DAT.old SOAJMSFILESTORE_AUTO_1000000.DAT
mv UMSJMSFILESTORE_AUTO_1000000.DAT UMSJMSFILESTORE_AUTO_1000000.DAT.old
cp UMSJMSFILESTORE_AUTO_1000000.DAT.old UMSJMSFILESTORE_AUTO_1000000.DAT

この方法を使用すると、WebLogicのファイル・ロック・メカニズムは、同じサーバーの複数のインスタンスが誤って起動されたときにデータが障害されないように、データの保護を続行します。ただし、マシンが突然の障害で停止したときは、サーバーを手動で再起動する必要があります。ファイル・ストアでは、ファイル・ストアを使用して大量のデータを格納する場合、複数の連番の付けられた.DATファイルが作成されます。この場合は、すべてのファイルをコピーし、名前を変更する必要があります。

方法2: WebLogic Serverのファイル・ストア内のファイル・ロックの無効化

注意:
この方法を使用すると、WebLogic Serverのロックが無効になっているので、自動サーバーを再起動して、フェイルオーバーに成功する必要があります。ただし、この方法を使用する場合は注意してください。WebLogicのファイル・ロック機能は、望ましくない並行性シナリオで発生するサーバー・ファイルの破損を避けるように設計されています。ファイル・ストアを使用するサーバーは、サーバーの移行のために構成されている場合、常に、データベースに基づくリース・オプションを構成します。これにより、データベース表を使用して追加のロック・メカニズムが実行され、同じWebLogic Serverの複数のインスタンスが自動的に再起動するのを防ぎます。人為的なエラーが発生しないようにし、ある時点でサーバーのインスタンスが1つのみ手動で起動されたことを確認するために、さらに手続き上の注意を払う必要があります。同じように、同じディレクトリを参照する同じ名前のストアを持つ2つのドメインが存在しないことを確認するためにも、さらに注意を払う必要があります。

次の項に記載されているように、WebLogic Server管理コンソールによっても、デフォルトのファイル・ストア、カスタム・ファイル・ストア、JMSページング・ファイル・ストアおよび診断ファイル・ストアのWebLogicファイル・ロック・メカニズムを無効化できます。

- デフォルトのファイル・ストアのファイル・ロックの無効化

- カスタム・ファイル・ストアのファイル・ロックの無効化

- JMSページング・ファイル・ストアのファイル・ロックの無効化

- 診断ファイル・ストアのファイル・ロックの無効化

デフォルトのファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用してデフォルトのファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。

1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。

2. 2.「ドメイン構造」ツリーで、「環境」ノードを拡張し、「サーバー」を選択します。

3. 「サーバーのサマリー」リストで、変更するサーバーを選択します。

4. 「構成」>「サービス」タブを選択します。

5. 「デフォルト・ストア」のセクションへスクロール・ダウンし、「詳細」をクリックします。

6. スクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

7. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

8. 変更したサーバーを再起動して、変更を反映します。

結果のconfig.xmlエントリは、次のようになります。

例7-3 デフォルトのファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<server>
<name>examplesServer</name>
...
<default-file-store>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
</default-file-store>
</server>

カスタム・ファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用してカスタム・ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。

1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「永続ストア」を選択します。

3. 「永続ストアのサマリー」リストで、変更するカスタム・ファイル・ストアを選択します。

4. カスタム・ファイル・ストアの「構成」タブで、「詳細」をクリックすると、ストアの詳細設定が表示されます。

5. ページの下部にスクロール・ダウンし、「ファイル・ロックの有効化」チェック・ボックスを選択解除します。

6. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

7. カスタム・ファイル・ストアが使用中であった場合、変更を反映するには、サーバーを再起動する必要があります。

結果のconfig.xmlエントリは、次のようになります。

例7-4 カスタム・ファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<file-store>
<name>CustomFileStore-0</name>
<directory>C:\custom-file-store</directory>
<synchronous-write-policy>Direct-Write</synchronous-write-policy>
<io-buffer-size>-1</io-buffer-size>
<max-file-size>1342177280</max-file-size>
<block-size>-1</block-size>
<initial-size>0</initial-size>
<file-locking-enabled>false</file-locking-enabled>
<target>examplesServer</target>
</file-store>

JMSページング・ファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用してJMSページング・ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。

1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「サービス」ノードを拡張し、「メッセージング」ノードを拡張して、「JMSサーバー」を選択します。

3. 「JMSサーバーのサマリー」リストで、変更するJMSサーバーを選択します。

4. JMSサーバーの「構成」>「一般」タブで、スクロール・ダウンして、「ページング・ファイル・ロックの有効化」チェック・ボックスを選択解除します。

5. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

6. 変更したサーバーを再起動して、変更を反映します。

結果のconfig.xmlエントリは、次のようになります。

例7-5 JMSページング・ファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<jms-server>
<name>examplesJMSServer</name>
<target>examplesServer</target>
<persistent-store>exampleJDBCStore</persistent-store>
...
<paging-file-locking-enabled>false</paging-file-locking-enabled>
...
</jms-server>

診断ファイル・ストアのファイル・ロックの無効化

WebLogic Server管理コンソールを使用して診断ファイル・ストアのファイル・ロックを無効にするには、次の手順に従います。

1. 必要に応じて、WebLogic Server管理コンソールの「チェンジ・センター」の「ロックして編集」(左上角)をクリックし、ドメインの編集ロックを取得します。

2. 「ドメイン構造」ツリーで、「診断」ノードを拡張し、「アーカイブ」を選択します。

3. 「診断アーカイブのサマリー」リストで、変更するアーカイブのサーバー名を選択します。

4. [server_name]の設定ページで、「診断ストアのファイル・ロックを有効化」チェック・ボックスを選択解除します。

5. 「保存」をクリックし、変更を保存します。必要に応じて、「チェンジ・センター」の「変更のアクティブ化」をクリックします。

6. 変更したサーバーを再起動して、変更を反映します。

結果のconfig.xmlエントリは、次のようになります。

例7-6 診断ファイル・ストアのファイル・ロックを無効化するconfig.xmlのエントリの例

<server>
<name>examplesServer</name>
...
<server-diagnostic-config>
<diagnostic-store-dir>data/store/diagnostics</diagnostic-store-dir>
<diagnostic-store-file-locking-enabled>false</diagnostic-store-file-lockingenabled>
<diagnostic-data-archive-type>FileStoreArchive</diagnostic-data-archive-type>
<data-retirement-enabled>true</data-retirement-enabled>
<preferred-store-size-limit>100</preferred-store-size-limit>
<store-size-check-period>1</store-size-check-period>
</server-diagnostic-config>
</server>

8データベースのチューニング

この章では、エンタープライズレベルの主なボトルネックにならないようにデータベースをチューニングする方法について説明します。この章のチューニング・ガイドラインと、使用しているデータベースの製品ドキュメントのチューニング・ガイドラインに従って、最適なパフォーマンスを実現できるようにデータベースを構成してください。

この章には次の項が含まれます:

- 一般的な推奨事項

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

一般的な推奨事項

この項では、データベースのチューニングに関する全般的な推奨事項を示します。

- 優れたデータベース設計 - データベースの負荷を複数のディスクに分散して、ディスクへの過負荷ができるだけ発生しないようにします。また、表、索引、およびログのサイズや構成を適切に設定することも重要です。

- ディスクのI/Oの最適化 - ディスクのI/Oの最適化は、スループットとスケーラビリティに直接影響します。最高速のディスクへのアクセスでも、メモリーへのアクセスに比べると大幅に時間がかかります。ディスクへのアクセス数は、可能なかぎり最適化する必要があります。通常は、I/Oに使用するブロックやバッファのサイズを大きくするとディスクへのアクセス数が減り、負荷の大きい本番環境でのスループットがかなり改善します。

- チェックポイント - チェックポイント・メカニズムでは、すべての不要なキャッシュ・データを定期的にディスクにフラッシュ(クリーン・アップ)することで、チェックポイントの期間のI/Oアクティビティおよびシステム・リソースの利用状況を改善します。チェックポイントの間隔を狭めると、ディスク上のデータの一貫性は保持されますが、データベースのパフォーマンスは低下します。チェックポイント・メカニズムはほとんどのデータベース・システムに備わっていますが、ユーザー・レベルの制御が許可されていないデータベース・システムもあります。たとえば、Oracleの場合、管理者はチェックポイントの間隔を設定できますが、ユーザーがSQLServer 7.xチェックポイントを制御することはできません。推奨設定については、使用しているデータベースの製品ドキュメントを参照してください。

- ディスクおよびデータベースのオーバーヘッドは、複数の処理をバッチとしてまとめるか、並列で実行される処理の数を増やす(並行性を高める)ことによって、大幅に削減できる場合もあります。次に例を示します。

- メッセージング・ブリッジのBatchSize、またはストア・アンド・フォワードのWindowSizeの値を増やすと、パフォーマンスが向上する場合があります。これは、バッチ・サイズを大きくすると、I/Oの数は減ますが、サイズが増えるためです。

- プログラム的にJDBCのバッチAPIを利用します。

- MDBトランザクション・バッチ機能を使用します。第10章「メッセージドリブンBeanのチューニング」を参照してください。

- max-beans-in-free-poolおよびMDBのスレッド・プール・サイズを増やす(またはバッチを利用できる場合は減らす)ことによって、並行性を高めます。

データベース固有のチューニング

この項では、Oracle、SQL Server、およびSybaseのチューニングに関する基本的な推奨事項を示します。

- Oracle

- Microsoft SQL Server

- Sybase

注意:
各データベースのベンダーが提供するドキュメントのチューニング・ガイドラインも必ず確認してください。

Oracle

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

- プロセス数 - ほとんどのオペレーティング・システムでは、Oracleサーバーへの接続ごとにシャドウ・プロセスを生成して接続をサービスします。したがって、Oracleで使用できるプロセスの最大数は、同時に処理できるユーザーの数と、Oracleサーバーが使用するバックグラウンド・プロセスの数をカバーできる値に設定しなければなりません。通常、デフォルトの最大数では、並行処理するオペレーションの数が多いシステムには対応できません。プラットフォーム固有の問題については、Oracleの管理者ガイドを参照してください。このパラメータの現在の設定値は、次の問合せを使用して取得できます。

SELECT name, value FROM v$parameter WHERE name = 'processes';

- バッファ・プール・サイズ - バッファ・プールは、OracleサーバーのSGA (system global area)の最も大きな部分です。これは、Oracleサーバーがディスクから読み込んだデータをキャッシュする場所です。read-mostlyアプリケーションの場合、データベースのパフォーマンスに影響する最も重要な統計は、バッファ・キャッシュ・ヒット率です。バッファ・プールのサイズは、キャッシュ・ヒット率が95%以上になる程度に大きくする必要があります。バッファ・プールのサイズは、init.oraファイルのdb_cache_sizeパラメータの値(データベース・ブロック数)を変更して設定します。

- 共有プール・サイズ - 共有プールは、OracleサーバーのSGA (system global area)の重要な部分です。SGAは、Oracleデータベース・インスタンスのデータおよび制御情報を格納する共有メモリーのグループです。複数のユーザーが同時に同じインスタンスに接続した場合、これらのユーザーはそのインスタンスのSGAのデータを共有します。SGAの共有プール部分には、2つの主な領域(ライブラリ・キャッシュとディクショナリ・キャッシュ)のデータがキャッシュされます。ライブラリ・キャッシュには、SQL関連の情報と制御構造(解析済のSQL文、ロックなど)が格納されます。ディクショナリ・キャッシュには、SQLの処理に必要なメタデータが格納されます。
ほとんどのアプリケーションでは、共有プール・サイズがOracleのパフォーマンスに対して重要です。共有プールが小さすぎると、限られた大きさの空間を管理するためだけにサーバーのリソースが消費されてしまいます。これによりCPUリソースが消費され、複数のキャッシュの並列管理に制限のあるOracleでは競合が発生する原因となります。トリガーやストアド・プロシージャを数多く使用すると、より大きな共有プールが必要となります。SHARED_POOL_SIZE初期化パラメータを使用して、共有プールのサイズをバイト単位で指定できます。

次の問合せを使用すると、共有プール内の空きメモリー量をモニターできます。

SELECT * FROM v$sgastat
WHERE name = 'free memory' AND pool = 'shared pool';

- 最大オープン・カーソル数 - Oracleサーバーのすべてのリソースが1つの接続によって消費されないようにするには、OPEN_CURSORS初期化パラメータを使用して接続ごとのオープン・カーソルの最大数を制限します。残念ながら、このパラメータのデフォルト値はWebLogic Serverのようなシステムには小さすぎます。カーソル情報は、次の問合せを使用してモニターできます。

SELECT name, value FROM v$sysstat
WHERE name LIKE 'opened cursor%';

- データベース・ブロック・サイズ - ブロックは、Oracleにおけるデータ格納の基本単位で、I/Oの最小単位でもあります。1つのデータ・ブロックは、ディスク上の物理データベースの特定のバイト数に相当します。このブロックという概念はOracle RDBMSに固有のものですので、基底のオペレーティング・システムのブロック・サイズと混同しないようにしてください。ブロック・サイズは物理的なストレージに影響するため、この値を設定できるのはデータベースの作成時に限られ、データベース作成後は変更できません。このパラメータの現在の設定値は、次の問合せを使用して取得できます。

SELECT name, value FROM v$parameter WHERE name = 'db_block_size';

- ソート領域のサイズ - ソート領域を大きくすると、問合せの処理中にメモリー内でソートを実行できるため、大規模なソートのパフォーマンスが向上します。ソート領域は接続ごとに1つしか確保できないため、このサイズの設定は重要になります。通常、このinit.oraパラメータのデフォルト値は6 - 8データ・ブロックです。この値は通常のOLTP処理には十分ですが、意思決定支援処理、大規模なバルク処理、大規模な索引関連の処理などを行う場合は、より大きな値を設定しておく必要があります。この種の処理を実行する場合は、init.oraパラメータを次のようにチューニングします(デフォルトの設定値は8Kデータ・ブロック)。

sort_area_size = 65536
sort_area_retained_size = 65536

Microsoft SQL Server

次に、Microsoft SQL Serverデータベースのパフォーマンス・チューニング・パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Microsoft SQL Serverのドキュメントを参照してください。

- 高速I/Oデバイスにはtempdbを格納します。

- perfmonがI/Oの増加を示す場合はリカバリ間隔を広くします。

- 2KB以上のI/Oブロック・サイズを使用します。

Sybase

次に、Sybaseデータベースのパフォーマンス・チューニング・パラメータに関するガイドラインを示します。これらのパラメータの詳細については、Sybaseのドキュメントを参照してください。

- リカバリ間隔を狭めると、チェックポイント処理がより頻繁に発生するためI/O処理が増加します。

- 2KB以上のI/Oブロック・サイズを使用します。

- Sybaseは、対称型マルチプロセッサ(SMP)環境内のエンジン数を制御します。この設定は「CPU数マイナス1」に等しくなるように構成することが推奨されます。

9 WebLogic Server EJBのチューニング

この章では、アプリケーション環境のWebLogic Server EJBのチューニング方法について説明します。

この章には次の項が含まれます:

- 一般的なEJBチューニングのヒント

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

- EJBプールのチューニング

- CMPエンティティBeanのチューニング

- モニター統計に応じたチューニング

一般的なEJBチューニングのヒント

- デプロイメント記述子は、スキーマ・ベースです。WebLogic Serverのこのリリースで新規の記述子は、DTDベースの記述子としては利用できません。

- RequiresNewトランザクション・パラメータの使用は避けてください。RequiresNewを使用すると、現在のすべてのトランザクションがEJBコンテナによって一時停止され、新しいトランザクションが開始されます。これは、別のデータベース接続を含む、追加のリソースが割り当てられることを意味します。

- 同じアプリケーション内で、あるEJBがサーブレットまたはJSPによって呼び出されたり、別のEJBに呼び出される場合は、local-interfacesを使用するか、call-by-referenceをtrueに設定して、シリアライゼーションのオーバーヘッドを回避します。次の点に注意してください。

- WebLogic Server 8.1より前のリリースでは、call-by-referenceはデフォルトでオンになっています。WebLogic Server 8.1以降のリリースでは、call-by-referenceはデフォルトでオフになっています。call-by-referenceが明示的にオンにされない8.1以降のWebLogic Serverに移行する古いアプリケーションでは、パフォーマンスが低下する場合があります。

- この最適化は、異なるアプリケーション間の呼出しには適用されません。

- 可能なかぎり、ステートフル・セッションBeanよりもステートレス・セッションBeanを使用します。ステートレス・セッションBeanは、維持すべき状態情報が存在しないため、ステートフル・セッションBeanよりもスケーラビリティが高くなります。

- WebLogic Serverでは、WebLogic Serverクラスタ内のEJBを使用するトランザクションのパフォーマンスも向上します。単一のトランザクションが複数のEJBを使用する場合、WebLogic Serverは異なるサーバーのEJBではなく、単一のWebLogic Serverインスタンスに存在するEJBインスタンスを使用します。この方法を使用すると、トランザクションのネットワーク・トラフィックを最小限に抑えることができます。場合によっては、トランザクションはクラスタ内の複数のWebLogic Serverインスタンスに存在するEJBを使用します。これは、すべてのEJBがすべてのWebLogic Serverインスタンスにデプロイされていない混成のクラスタで起こる場合があります。このような場合、WebLogic Serverは複数の直接接続ではなく1つの多層接続を使用してデータベースにアクセスします。この方法を使うと、リソースの使用量が減り、トランザクションのパフォーマンスが向上します。しかし、最高のパフォーマンスを得るには、クラスタを同一化する必要があります。

EJBキャッシュのチューニング

次の項では、EJBキャッシュのチューニング方法について説明します。

- ステートフル・セッションBeanキャッシュのチューニング

- エンティティBeanキャッシュのチューニング

- 問合せキャッシュのチューニング

ステートフル・セッションBeanキャッシュのチューニング

EJBコンテナは、weblogic-ejb-jar.xmlのmax-beans-in-cacheパラメータによって指定される数まで、ステートフル・セッションBeanをメモリーにキャッシュします。このパラメータは、同時ユーザーの数と等しくなるように設定する必要があります。これによって、ディスクに対するステートフル・セッションBeanのパッシブ化が最小になり、その後のディスクからのアクティベーションのパフォーマンスが向上します。

エンティティBeanキャッシュのチューニング

エンティティBeanは、EJBコンテナによって、次の2つのレベルでキャッシュされます。

- トランザクション・レベルのキャッシング

- トランザクション間のキャッシング

- READY Beanのキャッシング

トランザクション・レベルのキャッシング

エンティティBeanは、データベースからロードされ、findByPrimaryKeyを使用してリクエストされたり、そのトランザクションのキャッシュされた参照から呼び出されると、キャッシュから常に取得されます。非主キー・ファインダを使用したエンティティBeanの取得によって、データベースからBeanの永続的な状態が常に取得されます。

トランザクション間のキャッシング

エンティティBeanインスタンスは、トランザクション間でもキャッシュされます。ただし、デフォルトでは、エンティティBeanの永続的な状態は、トランザクション間ではキャッシュされません。トランザクション間でのキャッシングを有効にするには、cache-between-transactionsパラメータの値をtrueに設定します。

状態をキャッシュしても安全ですか?当該Beanの並行性戦略によります。エンティティBeanのキャッシュが本当に役立つのは、cache-between-transactionsを安全にtrueに設定できる場合のみです。ejbActivate()およびejbPassivate()コールバックのコストがかかる場合でも、エンティティ・キャッシュ・サイズを十分な大きさに保つことが推奨されます。永続的な状態がトランザクションごとに少なくとも1回、再ロードされる場合でも、キャッシュ内のBeanはすでにアクティブ化されています。キャッシュ・サイズの値は、デプロイメント記述子パラメータmax-beans-in-cacheによって設定し、キャッシュ・ヒット数が最大になるように設定する必要があります。多くの場合、この値は、エンティティBeanに関連付けられている表内の行数と、Beanに同時にアクセスすると予想されるスレッドの数の積より大きくする必要はありません。

READY Beanのキャッシング

キャッシュの失敗率が高いエンティティBeanの場合、READY Beanインスタンスを保持しておくと、パフォーマンスに悪影響を与える場合があります。

disable-ready-instancesフラグをentity-descriptorのentity-cache要素で設定すると、READYインスタンスはキャッシュに保持されません。この機能がデプロイメント記述子で有効にされている場合、キャッシュにはACTIVEインスタンスしか保持されません。Beanインスタンスは、関係するトランザクションがコミットされるかロールバックされるとすぐに、アクティブ・キャッシュからプールに移動されます。

問合せキャッシュのチューニング

問合せキャッシングはWebLogic Server 9.0からの新機能で、これによって、読取り専用CMPエンティティBeanが、任意のファインダの結果をキャッシュすることができます。問合せキャッシングは、prepared-queryファインダ以外のすべてのファインダに対してサポートされています。問合せキャッシュは、Beanレベルのキャッシュはもちろん、アプリケーション・レベルのキャッシュとなります。キャッシュのサイズは、weblogic-ejb-jar.xmlのmax-queries-in-cacheパラメータによって制限されます。weblogic-cmp-rdbms記述子ファイル内のファインダ・レベルのフラグのenable-query-cachingを使用して、ファインダの結果をキャッシュするかどうかを指定します。同じ名前のフラグは、weblogic-relationship-role要素に適用される際に、内部関係ファインダに対して同じ目的を持ちます。問合せは、次の状況で、問合せキャッシュから削除されます。

- その問合せが最も使用量が少なく、query-cacheのサイズ制限に到達しています。

- 問合せ条件を満たすEJBのうち少なくとも1つが、エンティティBeanキャッシュから理由にかかわらず削除されています。

- その問合せが、eager-relationship-cachingが有効化されたファインダに対応し、関連する内部関係ファインダの問合せが関連Beanの問合せキャッシュから削除されています。

エンティティBeanキャッシュのサイズを使用して、問合せキャッシュのサイズを制限することができます。これを行うには、max-queries-in-cacheパラメータを0に設定します。これは、対応するEJBが削除されると問合せがキャッシュから削除されるためです。こうすることで、問合せキャッシュにおけるロックの競合をある程度回避できる場合がありますが、パフォーマンスの大幅な向上は期待できません。

EJBプールのチューニング

次の項では、EJBプールのチューニング方法について説明します。

- ステートレス・セッションBeanプールのチューニング

- MDBプールのチューニング

- エンティティBeanプールのチューニング

ステートレス・セッションBeanプールのチューニング

EJBコンテナは、インスタンスの作成および破棄を回避するため、ステートレス・セッションBeanのプールを維持します。このプールは、通常でも便利ですが、ejbCreate()およびsetSessionContext()メソッドのコストがかかる場合のパフォーマンスにとって、さらに重要です。このプールは、上限値だけでなく、下限値も持ちます。上限値の方がより重要となります。

- 上限値は、max-beans-in-free-poolパラメータで指定します。この値は、EJBを同時に呼び出すものと考えられるスレッドの数と等しくする必要があります。あまりにも小さな値を設定すると、並行性に影響します。

- 下限値は、initial-beans-in-free-poolパラメータで指定します。initial-beans-in-free-poolの値を増やすと、EJBが含まれるアプリケーションのデプロイに費やされる時間が増し、サーバーの起動時間に影響します。メリットは、EJBインスタンスの作成コストが実行時にかからない点です。この値をあまりにも高く設定すると、メモリーが無駄に消費されます。

MDBプールのチューニング

MDBのライフサイクルは、ステートレス・セッションBeanによく似ています。MDBプールは、ステートレス・セッションBeanと同じチューニング・パラメータを持ち、チューニング時には同じ要素が適用されます。通常、ほとんどのアプリケーションにおいて、デフォルト値が適切です。第10章「メッセージドリブンBeanのチューニング」を参照してください。

エンティティBeanプールのチューニング

エンティティBeanプールには次の2つの目的があります。

- リフレクションによるファインダの呼出し用のターゲット・オブジェクト。

- キャッシュ内に特定の主キーのインスタンスが見つからない場合に、コンテナが補充できるBeanインスタンスのプール。

エンティティ・プールには匿名インスタンス(主キーを持たないインスタンス)が格納されます。これらのBeanはまだアクティブでありません(つまり、ejbActivate()がこれらのBeanに対してまだ呼び出されていません)が、EJBコンテキストは設定されています。エンティティ・キャッシュから削除されたエンティティBeanインスタンスは、パッシブ化され、プールに置かれます。チューニング可能なのは、initial-beans-in-free-poolとmax-beans-in-free-poolです。ステートレス・セッションBeanやMDBとは異なり、max-beans-in-free-poolには、スレッド数との関係がありません。エンティティBeanコンストラクタやsetEnityContext()メソッドのコストがかかる場合、max-beans-in-free-poolの値を増やす必要があります。

CMPエンティティBeanのチューニング

エンティティBeanでは、キャッシングを使用してデータベースとの対話の数を最小限にすることによって、パフォーマンスが最大限向上します。ただし、ほとんどの状況で、トランザクションの範囲外でエンティティBeanをキャッシュできるようにすることは現実的ではありません。次の項では、データベースとの対話を安全に最小限に抑えるために使用できるWebLogic Server EJBコンテナ機能について説明します。

- 積極的なリレーションシップ・キャッシングの使用

- JDBCバッチ処理の使用

- 調整更新

- フィールド・グループの使用

- include-updates

- call-by-reference

- Beanレベルのペシミスティックなロック

- 並行性戦略

積極的なリレーションシップ・キャッシングの使用

積極的なリレーションシップ・キャッシングを使用すると、EJBコンテナでは、単一のSQLの結合を使用して、関連エンティティBeanをロードできます。同じトランザクションは、関連Beanにアクセスする場合にのみ使用します。『Oracle WebLogic Server Enterprise JavaBeansバージョン2.1の開発』のリレーションシップ・キャッシングに関する項を参照してください。

このリリースのWebLogic Serverでは、CMRフィールドにrelationship-cachingとcascade-deleteの両方を指定すると、オーナーBeanおよび関連BeanがSQLにロードされ、パフォーマンスが向上します。

内部結合の使用

積極的なrelationship-cachingが有効になっている場合、EJBコンテナは常にCMP Beanファインダで外部結合を使用します。通常、内部結合の方が外部結合よりも実行が速くなりますが、内部結合の場合は、結合された対応する表内でデータが含まれていない行は返さないという難点があります。適用可能な場合は、非常に大規模なデータベースで内部結合を使用すると、CPUリソースを解放できる可能性があります。

WLS 10.3では、weblogic-cmp-rdbms-jar.xmlに、weblogic-rdbms-beanの属性としてuse-inner-joinが追加されました。

<weblogic-rdbms-bean>

<ejb-name>exampleBean</ejb-name>

...

<use-inner-join>true</use-inner-join>

</weblogic-rdbms-bean>

CMP Beanに関連するBeanをnullや空に設定できない場合は、この要素をtrueに設定してください。

デフォルト値はfalseです。この値をtrueに指定した場合、そのエンティティBeanに対するすべてのリレーションシップ・キャッシュ問合せでは、左外部結合の代わりに内部結合を使用して問合せ句を選択します。

JDBCバッチ処理の使用

JDBCバッチ処理は、EJBコンテナにおいてデフォルトでオンにされています。EJBコンテナは、データベースへのラウンド・トリップ数を減らすことによってパフォーマンスが向上する単一のバッチでの単純なデータベース操作を自動的に並べ替え、実行します。Oracleでは、バッチ処理を使用することをお薦めします。

調整更新

エンティティEJBが更新されると、EJBコンテナは、実際に変更されたフィールドのみデータベース内で自動的に更新します。その結果、Update文はより単純になり、Beanが変更されていない場合は、データベースの呼出しは行われません。様々なトランザクションによって、様々なフィールドのセットが変更される場合があるため、複数の形式のUpdate文が、データベースへのBeanの格納に使用される場合があります。重要なのは、JDBC接続プールのプリペアド文キャッシュ・サイズを設定する際に使用できるUpdate文の種類を把握しておくことです。「プリペアド文と呼出し可能文のキャッシュ」を参照してください。

フィールド・グループの使用

フィールド・グループを使用すると、よく使用されるフィールドを単一のグループに分離できます。グループ内のいずれかのフィールドが、アプリケーションやBeanコードによってアクセスされると、単一のSQL文を使用してグループ全体がロードされます。このグループは、ファインダと関連付けることもできます。ファインダが呼び出され、finders-load-beanがtrueの場合、フィールド・グループに属するフィールドのみがデータベースからロードされます。つまり、BLOBなど、ロードに時間のかかる特定のフィールドが、ほとんどのトランザクションで使用されない場合、フィールド・グループから除外できます。同様に、エンティティBeanに多くのフィールドがありますが、トランザクションではそれらのフィールドのごく一部しか使用されない場合、使用されないフィールドを除外できます。

注意:
同じトランザクションでアクセスされる複数のフィールドを、別々のフィールド・グループに構成しないように注意してください。別々のグループに構成すると、同じBeanをロードするのに1つの呼出しで十分だったところを、複数のデータベース呼出しが行われます。

include-updates

このフラグを使用すると、EJBコンテナはファインダを実行する前に、変更されたすべてのエンティティBeanをデータベースにフラッシュします。アプリケーションによって同じエンティティBeanが複数回変更され、同じトランザクションで非主キー・ファインダが途中で実行される場合、データベースに対する更新が複数回行われます。このフラグはデフォルトでオンになっており、EJBの仕様に準拠します。

同じファインダまたは異なるファインダの2回の呼出しによって、同じBeanインスタンスが返され、ファインダのその2回の呼出しの間にそのBeanインスタンスが変更されていたトランザクションがアプリケーションにある場合に、include-updatesをオンのままにしておく意味があります。それ以外の場合、このフラグは安全にオフにできます。こうすることで、2つ目のファインダの実行後に、Beanが再度変更される場合、データベースへの不必要なフラッシュを回避できます。このフラグは、cmp-rdbms記述子において各ファインダに対して指定します。

call-by-reference

このフラグをオフにすると、EJBのメソッド・パラメータが値で渡され、シリアライゼーションが伴います。可変で複合型の場合、これは大幅なコスト高になることがあります。以下の場合、優れたパフォーマンスを得るために、この使用を検討してください。

- アプリケーションがcall-by-valueセマンティクスを必要としていません(メソッド・パラメータがEJBによって変更されない場合など)。

または

- EJBによって変更される場合、メソッドの呼出し側に対してその変更を認識できないようにする必要がありません。

このフラグは、エンティティEJBだけでなく、すべてのEJBに適用されます。また、同じアプリケーションでのサーブレット/JSPとEJBとの間のEJB呼出しにも適用されます。このフラグはデフォルトでオフになっており、EJBの仕様に準拠します。このフラグは、WebLogic固有のデプロイメント記述子においてBeanレベルで指定します。

Beanレベルのペシミスティックなロック

Beanレベルのペシミスティックなロックは、Beanのロード時にデータベース・ロックを取得することによって、EJBコンテナ内に実装されます。実装されると、各エンティティBeanに一度にアクセスできるのは、単一サーバーの単一トランザクションのみとなります。その他すべてのトランザクションはブロックされ、自身のトランザクションが完了するまで待機します。これは、RDBMSレベルではコスト高となる場合のあるデータベースの高い分離レベルを使用する代わりの便利な手段です。このフラグは、cmp-rdbmsデプロイメント記述子においてBeanレベルで指定します。

注意:
ロックが排他的ロックでない場合、デッドロックの状態に陥ることがあります。データベース・ロックが共有ロックの場合、そのRDBMSを使用する際にデッドロックが発生する可能性があります。

並行性戦略

concurrency-strategyデプロイメント記述子は、同じサーバー・インスタンスの複数スレッドによる同じエンティティBeanへの同時アクセスを処理する方法をEJBコンテナに指示します。このパラメータは、以下の4つの値のいずれかに設定します。

- Exclusive - EJBコンテナは、特定の主キーに対してEJBのインスタンスが1つのみ存在するようにし、このインスタンスへのアクセスをシリアライズするコンテナを持つサーバー内のすべての同時トランザクション間でこのインスタンスが共有されます。この並行性の設定では、EJBが頻繁に使用され、同時アクセスの機会が多い場合、通常は優れたパフォーマンスは期待できません。

- Database: これがデフォルト値で、最もよく使われる並行性戦略です。EJBコンテナは、データベースへの並行性制御を保留します。コンテナは、特定の主キーに対して複数のEJBインスタンスを維持し、各トランザクションは自身のコピーを取得します。データベースのisolation-levelとBeanレベルのペシミスティックなロックは、この戦略と組み合わせることによって、永続の状態への同時アクセスを許可すべきかどうかの判断において主要な役割を果たします。cache-between-transactionsがtrueの場合に起こることがありますが、データベースにアクセスする必要がないかぎり、複数のトランザクションがBeanに同時にアクセスできます。ただし、cache-between-transactionsの値をtrueに設定するのは安全ではなく、Dababase並行性戦略では推奨されません。

- Optimistic: Optimistic並行性戦略の目標は、データベースでのロックを最小限に抑える一方で、データの一貫性を提供し続けることです。EJBの永続の状態がほとんど変更されないことが基本前提です。コンテナは、外部トランザクションのisolation-level設定によってデータベースでロックが取得されないように、ネスト・トランザクションのBeanのロードを試行します。コミット時にBeanが変更されている場合、その他のトランザクションによって永続の状態が変更されていないことを確認するために、指定された更新が使用されます。この場合、OptimisticConcurrencyExceptionがスローされ、アプリケーションによって処理されます。
この同時実行性方式を使用できるEJBはほとんど変更されないため、cache-between-transactionsをオンに設定すると、パフォーマンスが大幅に向上する場合があります。この戦略によって、読み込まれているが変更されてはいないBeanのコミット時の検証も可能になります。これを行うには、cmp-rdbms記述子で、verify-rowsパラメータをReadに設定します。これによって、非常に高いデータ一貫性が提供され、同時にデータベースでのロックが最小限に抑えられます。ただし、パフォーマンスはある程度低下します。バージョン列を使用してオプティミスティックな検証を実行することをお薦めします。これは、高速で、直後にタイムスタンプがとられ、その後で変更および読込みが行われるためです。verify-rowsがReadに設定されている場合、変更値は適用されません。

オプティミスティック並行性Beanが、クラスタの一部のあるサーバーで変更されると、そのサーバーは、OptimisticConcurrencyExceptionsを回避するため、そのBeanのすべてのインスタンスをクラスタ全体で無効化しようとします。場合によっては、単純に他のサーバーにOptimisticConcurrencyExceptionをスローさせる方が費用効果が高いこともあります。この場合、cmp-rdbms記述子のcluster-invalidation-disabledフラグを設定して、クラスタ全体の無効化をオフにします。

- ReadOnly - ReadOnly値が最もパフォーマンスが高くなります。この値を選択すると、コンテナは、EJBがトランザクショナル非対応であるとみなし、cache-between-transactionsを自動的にオンにします。Beanの状態は、構成可能な間隔でデータベースで定期的に更新されるか、Beanがプログラム的に無効化された場合に更新されます。更新間隔によっては、Beanの永続的な状態が無効になる場合があります。これは、query-cachingを使用できる唯一の並行性戦略です。「トランザクション間のキャッシング」を参照してください。

モニター統計に応じたチューニング

WebLogic Server管理コンソールでは、EJB実行時の様々なモニター統計が報告されます。それらの統計の多くがEJBのチューニングに役立ちます。この項では、統計の一部を利用してEJBのパフォーマンスをチューニングする方法について説明します。

WebLogic Server管理コンソールに統計を表示するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのEJBの監視に関する項を参照してください。カスタム監視アプリケーションを書き込む場合、JMXまたはWLSTを使用して該当するランタイムMBeanにアクセスして監視統計にアクセスできます。Oracle WebLogic Server MBeanリファレンスのRuntime MBeanに関する項を参照してください。

キャッシュ・ミス率

キャッシュ・ミス率とは、コンテナがキャッシュ内でBeanを見つけようと試行した回数(キャッシュ・アクセス)に対する、コンテナがキャッシュ内にBeanを見つけられなかった回数(キャッシュ・ミス)の比率です。

Cache Miss Ratio = (Cache Total Miss Count / Cache Total Access Count) * 100

高いキャッシュ・ミス率は、キャッシュ・サイズが適切に設定されていないことを示している場合があります。アプリケーションでBeanの特定のサブセット(読取り主キー)が他のBeanよりも頻繁に使用される場合、頻繁に使用されるBeanがキャッシュ内に残り、あまり使用されないBeanが要求に応じてキャッシュの内と外を循環できるように、キャッシュ・サイズを十分な大きさに設定することが理想的です。このような性質を持つアプリケーションの場合、キャッシュの最大サイズを増やすと、キャッシュ・ミス率を大幅に下げられる場合があります。

特定のBeanのサブセットを他のBeanよりも頻繁に使用する必要がないアプリケーションの場合、キャッシュの最大サイズを増やしても、キャッシュ・ミス率には影響しません。最も低いキャッシュ・ミス率が得られる最大キャッシュ・サイズを判断するには、様々な最大キャッシュ・サイズでアプリケーションをテストすることをお薦めします。また、サーバーのメモリーの容量は限られているため、キャッシュ・サイズを増やす場合は常にトレードオフが伴うことに注意することも重要です。

ロック待機率

Exclusive並行性戦略を使用する場合、ロック待機率とは、発行されたロック・リクエストの総数に対する、スレッドがBeanのロックを取得するために待機しなければならなかった回数の比率です。

Lock Waiter Ratio = (Current Waiter Count / Current Lock Entry Count) * 100

高いロック待機率は、Beanの並行性戦略が最適ではないことを示している場合があります。アプリケーションに適合している場合、DatabaseまたはOptimisticの並行性戦略を使用すると、Exclusive戦略を使用する場合よりも多くの並列処理が可能になり、EJBコンテナ・レベルでのロックが不要になります。

通常、トランザクションが継続している間はロックが保持されるため、トランザクションの継続時間を減らすとBeanがより短時間で解放され、その結果ロック待機率を下げることができる場合があります。トランザクションの時間を短縮するには、特別に必要な場合以外は、1つのトランザクションに多量の作業をグループ化することを避けます。

ロック・タイムアウト率

Exclusive並行性戦略を使用する場合、ロック・タイムアウト率とは、ロック・マネージャのアクセス数に対する、タイムアウト数の比率です。

Lock Timeout Ratio =(Lock Manager Timeout Total Count / Lock Manager Total Access Count) * 100

ロック・タイムアウト率は、ロック待機率と密接に関連しています。Beanのロック・タイムアウト率を改善する必要がある場合、最初にロック待機率を調べてこの率を下げる対処方法(並行性戦略の変更など)を考慮してください。スレッドがBeanのロックを待機しなければならない回数を削減するかゼロにすることができれば、待機中に発生するタイムアウトの回数も減少するかゼロになります。

また、高いロック・タイムアウト率は、トランザクションのタイムアウト値が不適切であることを示している場合もあります。スレッドがロックを待機する最大時間は、現在のトランザクション・タイムアウト値と同じです。

トランザクション・タイムアウト値が非常に低く設定されていると、スレッドはBeanへのアクセスが可能になるまで待機せずにタイムアウトする場合があります。その場合、Beanのtrans-timeout-seconds値を大きくすると、ロック・タイムアウト率を下げることができます。

ただし、trans-timeout-seconds値を大きくする場合は注意が必要です。この値を大きくすると、貴重なサーバー・リソースであるスレッドが長時間1つのBeanを待機する場合があります。また、リクエスト時間が長くなり、その結果、タイムアウトまでの待機時間が長くなる場合もあります。

プール・ミス率

プール・ミス率は、プールにBeanをリクエストした総回数に対する、プールにBeanの取得をリクエストしたが利用できるBeanがなかった回数の比率です。

Pool Miss Ratio = (Pool Total Miss Count / Pool Total Access Count) * 100

プール・ミス率が高い場合、Beanインスタンスに発生している状況を判断する必要があります。Beanは、次の3つの状況になる場合があります。

- 使用中

- 破棄済

- 削除済

次の手順に従って、問題を診断します。

1. Bean破棄率を調べて、Beanインスタンスが破棄されていないことを確認します。

2. 原因を特定し、状況に対処します。

3. EJBの需要を一定期間調べます。

これを確認する1つの方法は、WebLogic Server管理コンソールに表示される、現在の使用中Bean数およびアイドルBean数を使用することです。一定期間にEJBの需要が急増すると、プールが空になって追加リクエストに対応できなくなるため、多くのプール・ミスが表示されます。

EJBの需要が減少してBeanがプールに戻されると、リクエストを処理するために作成されたBeanの多くは、プールに収まりきらずに削除されます。この場合、フリー・プールの最大サイズを増やすと、プール・ミスの回数を減らすことができる場合があります。この最大サイズを増やすと、ピーク期間中に需要を満たすために作成されたBeanがプール内に存続するため、再び需要が増えたときにこれらのBeanを再び使用できるようになります。

Bean破棄率

Bean破棄率とはBeanのリクエストの総数に対する、破棄されたBean数の比率です。

Destroyed Bean Ratio = (Total Destroyed Count / Total Access Count) * 100

Beanの破棄数を減らすには、Beanインスタンスを破棄する必要がある場合以外は、Beanコードから非アプリケーション例外をスローしないことをお薦めします。非アプリケーション例外は、java.rmi.RemoteException例外(RemoteExceptionから継承される例外を含む)、あるいはEJBのホーム・インタフェースまたはコンポーネント・インタフェースのメソッドのthrows句に定義されていない例外のいずれかです。

通常、Beanの破棄の原因となっている例外は、パフォーマンスを低下させている場合や、EJBまたはEJBで使用されるリソースの問題を示している場合があるため、その例外を特定する必要があります。

プール・タイムアウト率

プール・タイムアウト率とは、行われたリクエストの総数に対する、プールからのBeanを待機していてタイムアウトしたリクエストの比率です。

Pool Timeout Ratio = (Pool Total Timeout Count / Pool Total Access Count) * 100

高いプール・タイムアウト率は、フリー・プールのサイズが適切に設定されていないことを示している場合があります。max-beans-in-free-pool設定を使用してフリー・プールの最大サイズを増やすと、サービス・リクエストに使用できるBeanインスタンスの数が増え、プール・タイムアウト率を下げることができる場合があります。

プール・タイムアウトの数に影響する別の要因は、Beanに対して構成されているトランザクション・タイムアウトです。スレッドがプールからのBeanを待機する最大時間は、Beanのデフォルトのトランザクション・タイムアウト値と同じです。weblogic-ejb-jar.xmlファイルのtrans-timeout-secondsの設定値を大きくすると、Beanインスタンスが使用可能になるまでのスレッドの待機時間が長くなります。

ただし、この値を大きくする場合は注意が必要です。この値を大きくすると、貴重なサーバー・リソースであるスレッドが長時間1つのBeanを待機する場合があります。また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。

トランザクション・ロールバック率

トランザクション・ロールバック率とは、EJBに関与するトランザクションの総数に対する、ロールバックしたトランザクションの比率です。

Transaction Rollback Ratio = (Transaction Total Rollback Count / Transaction Total Count) * 100

トランザクション・ロールバック率が高い場合に原因を調査するには、WebLogic Server管理コンソールに示されるトランザクション・タイムアウト率を最初に調べます。トランザクション・ロールバック率が予想よりも高い場合、最初にタイムアウトの問題に対処します。

予想外に高いトランザクション・ロールバック率には、いくつかの原因が考えられます。アプリケーションまたはアプリケーションで使用されるリソースの潜在的な問題を発見するには、トランザクション・ロールバックの原因を調査することをお薦めします。

トランザクション・タイムアウト率

トランザクション・タイムアウト率とは、EJBに関与するトランザクションの総数に対する、タイムアウトしたトランザクションの比率です。

Transaction Timeout Ratio = (Transaction Total Timeout Count / Transaction Total Count) * 100

不適切なトランザクション・タイムアウト値が原因でトランザクション・タイムアウト率が高くなる場合があります。たとえば、トランザクション・タイムアウトの値が小さすぎると、スレッドが必要な処理を完了する前にトランザクションがタイムアウトする場合があります。トランザクション・タイムアウト値を大きくすると、トランザクション・タイムアウト数を減らすことができる場合があります。

ただし、この値を大きくする場合は注意が必要です。この値を大きくすると、タイムアウトまでにスレッドが長時間1つのリソースを待機する場合があります。また、リクエストがタイムアウトするまでの待機時間が長くなるため、リクエスト時間が長くなる場合があります。

高いトランザクション・タイムアウト率の発生には、サーバー・リソースのボトルネックなど、多くの原因が考えられます。タイムアウトの原因を特定して問題に対処できるようにするには、トランザクション全体をトレースすることをお薦めします。

10メッセージ駆動型Beanのチューニング

この章では、メッセージドリブンBean (MDB)のチューニングとベスト・プラクティスについて説明します。

この章には次の項が含まれます:

- トランザクション・バッチの使用

- MDBスレッド管理

- 分散トピックを使用したMDBの構成およびデプロイのベスト・プラクティス

- 外部宛先におけるMDBの使用

- キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング

- WLS 10.0以前のバージョン方式のポーリングに対する互換性

トランザクション・バッチの使用

MDBトランザクションのバッチ処理を使用すると、複数のJMSメッセージを1つのコンテナ管理トランザクションに管理できます。バッチ処理を使用すると、複数のメッセージのトランザクション・コストが償却されます。また、適切に使用すると、2PC処理と1PC処理の間のスループットの差も削減、または排除できます。『Oracle WebLogic ServerメッセージドリブンBeanの開発』のMDBのトランザクションのバッチ処理に関する項を参照してください。

- バッチ処理を使用する場合、同時に扱うMDBインスタンス数を減らす必要があることもあります。使用できるMDBインスタンスが多すぎる場合、メッセージはバッチではなく並列で処理される可能性があります。「MDBスレッド管理」を参照してください。

- 通常、バッチ処理ではスループットが向上しますが、待機時間(個々のメッセージのMDB処理が完了するまでの時間)も増大する場合があります。

MDBスレッド管理

MDBのスレッド管理については、並行性、すなわち同時にアクティブになれるMDBインスタンス数の観点から説明します。次の項では、MDB並行性について説明します。

- 同時MDBの数の確定

- 並行性戦略の選択

- WebLogic宛先を使用する場合のスレッドの利用

- マルチスレッド・トピックMDBの制限

同時MDBの数の確定

表10-1では、サーバー・インスタンスに対して同時実行しているMDBインスタンス数の確定方法に関する情報を提供します。

表10-1 WebLogic Server MDBの同時方式の確定

ワーク・マネージャまたは実行キューのタイプ

スレッド

デフォルトのワーク・マネージャまたは制約のないワーク・マネージャ

最大でMin(max-beans-in-free-pool,16)で、自動チューニングにより変化します

デフォルトのワーク・マネージャ、自動チューニングを無効化

Min(default-thread-pool-size/2+1, max-beans-in-free-pool)

これは、WebLogic Server 8.1でのデフォルト・スレッド・プールの並行性アルゴリズムでもあります。

カスタム実行キュー

Min(execute-queue-size, max-beans-in-free-pool)

カスタム・ワーク・マネージャ、制約有り

min-thread-constraintとMin(max-threads-constraint, max-beans-in-free-pool)の間で、自動チューニングにより変化します

トランザクション対応のWebLogic MDBは、A) WebLogic以外のキューをリスニングしている場合、またはB) WebLogicキューをリスニングしていて、トランザクション・バッチ処理が有効になっている場合、同期的なポーリング・メカニズムを使用してJMS宛先からメッセージを取得します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。

並行性戦略の選択

次の項では、アプリケーションに対して並行性戦略を選択するための全般的な情報を示します。

注意:
アプリケーションはそれぞれに特性があり、使用するアプリケーションがその環境でどのように動作するのかに基づいて並行性戦略を選択します。

- ほとんどの状況において、メッセージ・ストリームにメッセージの急増が見られる場合には、制約のないワーク・マネージャを高いフェア・シェアで使用するのが適切です。急増したメッセージ群が処理されると、スレッドは自動チューニング・プールに返されます。

- ほとんどの状況において、メッセージの到着率を高いレベルで一定させるか、待機時間を小さくすることが求められる場合、MDBに対してスレッドを予約すると有効です。スレッドを予約するには、ワーク・マネージャにmin-threads-constraintを指定するか、カスタム実行キューを使用します。

- カスタムMDB実行キューを持つWebLogic Server 8.1アプリケーションを移行する場合、MDB実行キューを、max-threads-constraintパラメータおよび高いフェア・シェア設定が構成されたカスタム・ワーク・マネージャに変換できます。

注意:
デフォルトの並行性である16をオーバーライドするためには、max-threads-constraintパラメータを構成する必要があります。

- WebLogic Server 8.1では、デフォルトのプールを拡張するとMDB並行性の最大数も大きくなることから、デフォルトの実行キューのサイズを増加できました。WebLogic Server 9.0でアップグレードされたデフォルト・スレッド・プールのMDBは、最大数が16に固定されています。MDB並行性の数を16よりも大きくするには、カスタム・ワーク・マネージャまたはカスタム実行キューを作成する必要があります。表10-1を参照してください。

WebLogic宛先を使用する場合のスレッドの利用

次の項では、WebLogic ServerとWebLogic宛先が相互運用する場合のスレッドの割当て方法について説明します。

- トランザクション非対応のWebLogic MDBでは、処理すべき新しいメッセージがある場合、必要に応じて、dispatch-policyで指定されているスレッド・プールからスレッドを割り当てます。MDBが正常にソース宛先に接続したものの処理するメッセージがない場合、MDBはスレッドを使用しません。

- トランザクションのバッチ処理を 無効化したトランザクションWebLogic MDBには、「互換性」(デフォルト)のトピック・メッセージ分散モードを使用するトピックMDBを除く非トランザクションMDBと同一の機能があります。いずれの場合でも、MDBは常にスレッド・プール・サイズを1に制限します。

- トランザクション対応のMDBでトランザクション・バッチ処理が有効になっている場合は、MDBがトピックとキューのどちらでリスニングしているかによって動作が異なります。

- トピックでリスニングしているMDB: - 各デプロイ済MDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。

- トピック・メッセージ分散モード = 互換性: デプロイされた各MDBは、プールされていないスレッドのスレッド・グループで作成される専用のデーモン・ポーリング・スレッドを使用します。

- トピック・メッセージ分散モード = One-Copy-Per-ServerまたはOne-Copy-Per-Application: キューと同様。

- キューでリスニングしているMDB - 各デプロイ済MDBは、専用のスレッドを使用するかわりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policyから少なくとも1つのスレッドを使用します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。

WebLogic Serverを外部宛先から消費されたMDBと相互運用するときのスレッドの割当て方法の詳細は、「外部宛先からのメッセージを処理するMDBのスレッドの使用」を参照してください。

マルチスレッド・トピックMDBの制限

topicMessagesDistributionModeが「互換性」であるとき、非トランザクション・トピックMDBのデフォルト動作は、メッセージ処理のマルチスレッド化です。この場合、予期しない例外や未処理のメッセージの確認応答など、トピックがWebLogic JMSトピックでないとき、MDBコンテナは再現可能な動作を提供できません。たとえば、アプリケーションがonmessageからRuntimeExceptionをスローする場合、コンテナはメッセージを確認する可能性があります。トピックが外部ベンダー・トピックであるとき(WebLogic JMSトピックでないとき)、トピックMDBにおけるマルチスレッド化を防ぐために、デプロイメント記述子でmax-beans-in-free-poolの値を1に設定することをお薦めします。

警告:

非トランザクション外部トピック: 外部(WebLogic以外の)トピックとともに機能する非トランザクションMDBには、明示的にmax-beans-in-free-poolを1に設定することをお薦めします。この設定に失敗すると、MDBアプリケーションがRuntimeまたはErrorの例外をスローするなど、特定のエラーがある場合にメッセージの損失につながる可能性があります。

順序単位: WebLogic JMSトピックから消費してWebLogic JMSの「順序単位」値を持つメッセージを処理する非トランザクション「互換性」モードのMDBには、明示的にmax-beans-in-free-poolを1に設定することをお薦めします。この使用事例のような「順序単位」メッセージは、max-beans-in-free-poolを1に設定しない場合、順序通りに処理されない可能性があります。

トランザクションMDBは、max-beans-in-free-poolの設定に関係なく、強制的に自動で並行性を1に設定します。

分散トピックを使用したMDBの構成およびデプロイのベスト・プラクティス

メッセージドリブンBeanは、分散トピックの使用時にスケーラビリティと高可用性を付与する多数のアプリケーション設計およびデプロイメント・オプションを提供します。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項を参照してください。

外部宛先におけるMDBの使用

注意:
ここでの「外部宛先」とは、WebLogic以外のJMSプロバイダによってホストされる宛先を示します。リモートWebLogic宛先のことではありません。

次の項では、外部宛先からのメッセージを消費するMDBを使用したときのWebLogic Serverの動作について説明します。

- 外部宛先からのメッセージを処理するMDB並行性

- 外部宛先からのメッセージを処理するMDBのスレッド使用率

外部宛先からのメッセージを処理するMDB並行性

外部プロバイダによってホストされている宛先(WebLogic JMS以外の宛先)からのメッセージを消費するMDB並行性は、WebLogic JMS宛先に使用するアルゴリズムと同じアルゴリズムを使用して決定されます。

外部宛先からのメッセージを処理するMDBのスレッド使用率

次の項では、WebLogic Serverが外部宛先からのメッセージを処理するMDBと相互運用するときのスレッドの割当て方法について説明します。

- トランザクション非対応のMDBは外部ベンダーのスレッドを使用し、WebLogic Serverのスレッドは使用しません。この場合、dispatch-policyは並行性の決定以外では無視されます。

- トランザクション対応のMDBは、次のようにWebLogic Serverスレッドで動作します。

- トピックでリスニングしているMDB - 各デプロイ済MDBは、プールされないスレッドのグループで作成される、専用のデーモン・ポーリング・スレッドを使用します。

- キューでリスニングしているMDB - 各デプロイ済MDBは、専用のスレッドを使用するかわりに、トークン・ベースの同期ポーリング・メカニズムを使用します。このメカニズムでは常にdispatch-policyから少なくとも1つのスレッドを使用します。「キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング」を参照してください。

キュー/トピックにリスニングするトランザクション対応のMDBに対するトークン・ベースのメッセージ・ポーリング

トランザクションWebLogic MDBは、同期ポーリング・メカニズムを使用して、次の場合にJMS宛先からメッセージを取得します。

- WebLogic以外のキューのリスニング

- WebLogicキューのリスニングおよびトランザクションのバッチ処理が有効化されている場合

- 次の場合のWebLogicトピックのリスニング。

- トピック・メッセージ分散モード = One-Copy-Per-Serverおよびトランザクションのバッチ処理が有効化されている場合。

- トピック・メッセージ分散モード = One-Copy-Per-Applicationおよびトランザクションのバッチ処理が有効化されている場合

同期的なポーリングでは、1つまたは複数のWebLogicポーリング・スレッドがMDBのソース宛先からメッセージを同期的に受信し、MDBアプリケーションのonMessageコールバックを呼び出します。

WebLogic 10.3では、メッセージの負荷が変動する状況で同時ポーラー・スレッド数を制御しやすくなるように、ポーリング・メカニズムがトークン・ベースの手法に変更されました。以前のリリースでは、特定の状況において、スレッド数の増加が緩やかすぎる場合がありました。また、特定の外部JMSプロバイダでは、子ポーラーを一度起動すると、数を減らしてプールに戻すことができない場合もありました。

トークン・ベースのポーリングでは、スレッドがスレッド・プールに戻されるとき、スレッドの内部JMSコンシューマはキャッシュされるのではなく、閉じられます。そのため、コンシューマに対応するポーリング・スレッドはなくなり、メッセージが特定の外部JMSプロバイダによって暗黙的にプリフェッチされることがなくなります。

また、各MDBは、特定のポーラー・スレッドに別スレッドの作成を許可する単一のトークンを保持します。

- メッセージの受信時 - すでにトークンを持っているポーラー・スレッド、または、他に所有されていなかったのでトークンを獲得できたポーラー・スレッドが、追加のポーラー・スレッドを起動します。まだ並行性の最大数に達していない場合は、そのトークンを新しいポーラーに与えます。並行性の最大数に達している場合は、(他のポーラーで使用できるように)単にトークンを解放します。

- 空のキューの検出時 - ポーラーはトークンの獲得を試み、獲得できた場合は、そのキューの定期的なポーリングを試みます。トークンを獲得できない場合、ポーラーは自身をプールに返します。したがって、空のキューに対しても、少なくとも1つのポーラーがメッセージをチェックしていることになります。

WLS 10.0以前のバージョン方式のポーリングに対する互換性

WLSバージョン10.0以前では、バッチ処理が有効になっているトランザクション対応MDBは、デプロイ済の各MDBごとに専用のポーリング・スレッドを作成していました。このポーリング・スレッドはdispatch-policyで指定されたプールから割り当てられるものではなく、システムで動作している他のすべてのスレッドに追加される、完全に新しいスレッドでした。「トランザクション・バッチの使用」を参照してください。

トークン・ベースのポーリングの動作をオーバーライドしてWLS 10.0以前の動作を実装するには、以下のいずれかを行います。

- サーバー・レベルでは、weblogic.mdb.message.81StylePolling システム・プロパティをTrueに設定して、トークン・ベース・ポーリングの動作をオーバーライドします。

- MDBレベルでは、message-driven-descriptorの下のuse81-style-polling要素を設定して、トークン・ベース・ポーリングの動作をオーバーライドします。WLS 8.1方式のポーリング・フラグで外部のトランザクション対応MDBを使用する場合、外部ベンダーの中には同時実行するMDBインスタンスごとに恒久的にスレッドを割り当てる必要があるものもあります。このようなスレッドはdispatch-policyで指定されたプールから取得され、MDBがアンデプロイされるまでプールに返されません。こうしたスレッドは共有されないため、MDBが同じプール内の他のリソースの処理を妨げることがあります。このような場合、必要に応じてプールのスレッド数を増加します。このような外部ベンダーの場合にトークン・ベースのポーリング方式を使用した場合、スレッドの内部的なJMSメッセージ・コンシューマはキャッシュされるのではなく閉じられるため、メッセージが特定のコンシューマの宛先によって予約されることはありません。

11 データ・ソースのチューニング

この章では、WebLogicデータ・ソースのパフォーマンスを最大にする方法のヒントを示します。

この章には次の項が含まれます:

- データベース接続数のチューニング

- 浪費の回避

- 予約時の接続テストの慎重な使用

- プリペアド文と呼出し可能文のキャッシュ

- Pinned-To-Threadプロパティの使用によるパフォーマンスの向上

- サーバーの負荷が重い状態でのデータベース・リスナー・タイムアウト

- データ型オブジェクトのラッピングの無効化

- Oracleドライバとデータベースの詳細構成

- 設計のベスト・プラクティスの使用

データベース接続数のチューニング

WebLogic Serverアプリケーションでデータ・ソースのパフォーマンスを向上させる簡単な方法は、データ・ソースの接続プールを構成するときに「初期容量」の値を「最大容量」の値と同じに設定することです。

データベース接続の作成は、環境内では比較的コストのかかるプロセスです。通常、起動時の接続プールには少数の接続が含まれています。接続に対するクライアントのリクエストが増えるにつれて、プール内の接続だけではリクエストに十分に応じられなくなります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。

サーバーを使用するクライアントに対して接続の作成が遅れないようにする1つの方法は、すべての接続をクライアントの要求によって初期化するのではなく、サーバーの起動時に初期化することです。データ・ソース構成の「接続プール」タブの接続の初期数の値を接続の最大数の値と等しい設定します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項を参照してください。本番前パフォーマンス・テストの一部として最大容量の値を決定する必要があります。

Initial Capacityの値をゼロに構成すると、WebLogic Serverは起動中に接続を確立しません。これは起動パフォーマンスを大幅に向上します(特に、いくつかのデータ・ソースが有効になっている場合)。しかし、さらに重要なこととしては、データベースが使用可能でない場合や起動時に問題がある場合でも(あるいは、プライマリ・サービスが実行中には使用できないスタンバイ・データ・ソースの場合でさえも)、起動時にデータ・ソースをデプロイできるようにします。

Initial Capacityがゼロであっても接続が予約されている状況を次に2つ示します。

1. LLR用に構成されたマルチ・データ・ソース。メンバー・データ・ソースごとに接続が予約され、基礎となるデータベースがOracle Real Application Clusters (Oracle RAC)データベースであるかが判断されます。Oracle RACの場合、使用できるメンバー・データ・ソースは1つのみです。

2. auto-ONSで構成されたActive GridLink (AGL)データ・ソースの場合(つまり、ONSホストとポートのペアが提供されない場合)、接続が確立され、データベースからONS構成情報を取得できます。

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

浪費の回避

リソースの浪費を回避することも、パフォーマンスを向上させる簡単な方法の一つです。次のような状況で、JDBC関連のリソースの浪費を回避できます。

- JNDIルックアップは比較的コストがかかるため、クライアント・コードまたはアプリケーション・コードでルックアップを要求したオブジェクトをキャッシュしておくと、パフォーマンスに何度も影響を与えることがなくなります。

- クライアントまたはアプリケーション・コードで接続を取得したら、接続を閉じて新しい接続を再取得する代わりに、その接続をできる限り再利用します。既存の接続を取得して戻すと、新しい接続を作成する場合よりもコストが抑えられますが、取得とプールへの返却を過度に行うと、接続プールに競合が発生して、アプリケーションのパフォーマンスが低下します。

- 作業の実行に必要な時間よりも長く接続を保持しません。接続を一度取得して必要な作業をすべて完了したら、できるだけ早く接続を戻すようにすると、全体的なパフォーマンスのバランスが最適になります。

予約時の接続テストの慎重な使用

「予約時に接続をテスト」を有効にした場合、サーバー・インスタンスはデータベース接続をクライアントに戻す前にチェックします。この機能によって、無効な接続がクライアントに渡されるリスクを減らすことができます。

ただし、この処理にはかなりコストがかかります。通常、サーバー・インスタンスでは、接続を戻す前に各接続に対して完全なSQL問合せを実行することにより、テストを実行します。SQL問合せが失敗すると、その接続は破棄されて、代わりに新しい接続が作成されます。WebLogic Server 9.xでは、この「予約時の接続テスト」機能に、パフォーマンス調整可能な任意の新しいオプションが用意されました。9.xのパフォーマンス調整可能な任意の新しいオプションを使用すると、クライアントが接続を以前に正常に使用したときから構成済みの期間内(デフォルトは10秒間)であれば、WebLogic ServerでSQL問合せテストを省略できます。クライアントがプールに接続を戻すとき、WebLogic Serverはその接続にタイムスタンプを設定します。この特定の接続が期間内にクライアントに返された場合、WebLogic ServerはSQL問合せテストを省略します。この期間の経過後には、SQL問合せテストが実行されるようになります。この機能によって、「予約時の接続テスト」を使用するビジー・システムでは、パフォーマンスを大幅に向上させることができます。

プリペアド文と呼出し可能文のキャッシュ

アプリケーションまたはEJBで準備された文またはコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間とデータベース・サーバー自体に通信のために大きな処理オーバーヘッドが発生されます。処理コストを最小限にする場合、WebLogic Serverでは、アプリケーションで使用されるプリペアド文またはコール可能文をキャッシュできます。アプリケーションまたはEJBによってキャッシュに格納された文が呼出されると、キャッシュに格納された文が再利用されます。プリペアド文またはコール可能文を再利用すると、データベース・サーバー上のCPU使用量が低減され、現在の文のパフォーマンスが向上します。また、CPUサイクルを別のタスクを行うために使用できます。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の文キャッシュによるパフォーマンスの改善に関する項を参照してください。

文キャッシュを使用することでパフォーマンスを大幅に向上させることができますが、制限があることも考慮に入れる必要があります。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の文キャッシュの使用制限に関する項を参照してください。

Pinned-To-Threadプロパティの使用によるパフォーマンスの向上

アプリケーションがデータ・ソースからのデータベース接続を予約するのにかかる時間を最小限にし、データベース接続用のスレッド間の競合を削減するには、データ・ソースの接続プロパティ・リストにPinned-To-Threadプロパティを追加し、その値をtrueに設定します。

このリリースでは、Pinned-To-Thread機能はマルチ・データ・ソース、Oracle RAC、およびIDプールでは有効になりません。これらの機能は、接続プールに接続を返し、接続が失敗した場合や、接続IDが一致しなかった場合に、その接続を再取得する機能に依存しています。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCデータ・ソース: 構成: 接続プールに関する項を参照してください。

サーバーの負荷が重い状態でのデータベース・リスナー・タイムアウト

WebLogic Serverの負荷が重くなる(CPU使用率が高い)一部の状況では、データベース・リスナーがタイムアウトし、新規接続の作成中に例外をスローする場合があります。この問題を解決するには、データベース・サーバー上でリスナー・タイムアウトを増進します。次の例は、オラクル社のドライバおよびデータベースの例です。

- スローされた例外はResourceDeadExceptionで、ドライバの例外はソケット読取りは時間切れでした。

- 解決するには、次を使用してデータベース・サーバーのタイムアウトを増進します。
sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180

listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=180

データ型オブジェクトのラッピングの無効化

デフォルトでは、Array、Blob、Clob、NClob、Ref、SQLXML、およびStructのデータ型オブジェクトに加え、ParameterMetaDataとResultSetMetaDataオブジェクトがWebLogicラッパーによってラップされます。ラッピングは無効にできます。無効にすると、パフォーマンスが向上し、アプリケーションがネイティブ・ドライバ・オブジェクトを直接使用できます。『Oracle WebLogic Server JDBCデータ・ソースの管理』のラップされていないデータ型オブジェクトの使用に関する項を参照してください。

Oracleドライバとデータベースの詳細構成

Oracleドライバとデータベースを使用する場合にデータ・ソースとドライバのパフォーマンスを向上させる詳細構成オプションが用意されています。オプションには、プロキシ認証、接続での資格証明の設定、接続収集、接続のラベル付けなどがあります。『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracleドライバとデータベースの詳細構成に関する項を参照してください。

設計のベスト・プラクティスの使用

データベース・アプリケーションのパフォーマンスの良し悪しはほとんどの場合、アプリケーション言語ではなく、アプリケーションがどのように設計されているかによって決定されます。クライアントの数と場所、DBMS表および索引のサイズと構造、および問合せの数とタイプは、すべてアプリケーションのパフォーマンスに影響を与えます。『Oracle WebLogic Server JDBCアプリケーションの開発』のベスト・パフォーマンスのためのアプリケーションの設計に関する項を参照してください。

12 トランザクションのチューニング

この章では、トランザクションの最適化に関する背景知識とチューニングについて説明します。

この章には次の項が含まれます:

- グローバル・トランザクション・チューニング

- XAトランザクション・クラスタ・アフィニティ

- ロギング・ラスト・リソース・トランザクションの最適化

- 読取り専用の1フェーズ・コミットの最適化

- TLogを使用しないXAトランザクションの構成

グローバル・トランザクション・チューニング

XAトランザクション・クラスタ・アフィニティによって、グローバル・トランザクションに参加しているサーバー・インスタンスが、関連するリクエストを他のメンバー・サーバーにロード・バランシングしないで処理できるようになります。Enable Transaction Affinity=trueの場合、クラスタ・スループットは次のようにすることによって増加します。

- サーバー間トランザクション調整トラフィックの削減

- JDBC接続の削減など、リソース使用率の向上

- トランザクションの非同期処理の単純化

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成に関する項および『Oracle WebLogic Serverクラスタの管理』のXAトランザクション・アフィニティに関する項を参照してください。

XAトランザクション・クラスタ・アフィニティ

XAトランザクション・クラスタ・アフィニティによって、グローバル・トランザクションに参加しているサーバー・インスタンスが、関連するリクエストを他のメンバー・サーバーにロード・バランシングしないで処理できるようになります。Enable Transaction Affinity=trueの場合、クラスタ・スループットは次のようにすることによって増加します。

- サーバー間トランザクション調整トラフィックの削減

- JDBC接続の削減など、リソース使用率の向上

- トランザクションの非同期処理の単純化

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクラスタの構成に関する項および『Oracle WebLogic Serverクラスタの管理』のXAトランザクション・アフィニティに関する項を参照してください。

ロギング・ラスト・リソース・トランザクションの最適化

JDBCデータ・ソースを通じてロギング・ラスト・リソース(LLR)のトランザクションの最適化を行うと、データベースの挿入、更新、削除などを含む2フェーズ・トランザクションに関するオーバーヘッドを、安全に軽減できます。2フェーズ・トランザクションは、別の2つのリソースが同じグローバル・トランザクション(「XA」または「JTA」トランザクションとも呼ばれる)に参加する場合に発生します。次のことを考慮してください。

- JMSアプリケーションでの一般的な2フェーズ・トランザクションには、通常、JMSサーバーとデータベース・サーバーの両方が関与します。LLRオプションを使用するとXAの2倍のパフォーマンスを実現できます。

- WebLogicをはじめ他のベンダーでも利用できる「最後のエージェント」、「最後の参加者」、「2フェーズ・コミットのエミュレート」といった広く知られたXA最適化に比べ、JDBC LLRオプションは安全性が高くなります。

- JDBC LLRでは、2フェーズ・トランザクションのレコードをトランザクション・マネージャのログ(TLOG)ではなく、データベース表に保存します。

『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項を参照してください。

LLRチューニング・ガイドライン

この項では、LLRのチューニングのガイドラインを示します。

- 『Oracle WebLogic Server JTAアプリケーションの開発』のロギング・ラスト・リソース・トランザクションの最適化に関する項、および『Oracle WebLogic Server JDBCデータ・ソースの管理』のLLRデータ・ソースに関するプログラミング上の考慮事項と制限事項に関する項を読んで理解することをお薦めします。LLRを使用すると、管理および設計に重要な影響を与える場合があります。

- JDBC LLRを使用すると、SQLのupdate、delete、またはinsertを含んだ2フェーズ・トランザクションのパフォーマンスは通常、向上します。

- LLRを使用すると、SQLがすべて読取り(select)のみの2フェーズ・トランザクションのパフォーマンスは通常、低下します。

- JDBC LLRのプールはWebLogic JDBCストアに対しパフォーマンス上の利点を持たません。WebLogic JDBCストアはトランザクションに完全に対応していますが、その内部のJDBC接続ではJTA (XA)トランザクションが使用されません。

- コネクタ用の「最後のエージェント」による最適化や、JDBC接続プール用の「2フェーズ・コミットのエミュレート」オプション(従来の名称は、非XAドライバを使用するプール用の「2フェーズ・コミットを有効化」)といった比較的安全性の低い手法の代わりに、LLRの使用を検討します。

- OracleデータベースではLLR表を多用すると長期的に断片化が起こる場合があり、未使用範囲の発生につながることがあります。これは、LLR表のデータが一時的な性質を持つことにより発生していると考えられます。この問題を回避するには、LLR表においてPCT_FREEを5、PCT_USEDを95に設定します。または、ALTER TABLESPACE [tablespace-name ] COALESCEコマンドを使用して定期的なデフラグを行います。

読取り専用の1フェーズ・コミットの最適化

Oracle Database (Oracle AQやOracle RACを含む)などのリソース・マネージャが、読取り専用の最適化を提供するとき、Oracle WebLogicは読取り専用の1フェーズ・コミットの最適化を提供します。同一のXAトランザクションの複数接続を有効化するときでさえも、Oracle WebLogicやリソース・マネージャの両方でXAResource.prepareネットワーク呼出しやトランザクション・ログの書込みを削除するなど、これにはかなりのメリットがあります。

『Oracle WebLogic Server JTAアプリケーションの開発』の読取り専用の1フェーズ・コミットの最適化に関する項を参照してください。

TLogを使用しないXAトランザクションの構成

XAトランザクションの範囲が単一のトランザクション・マネージャ(TM)である場合、TLogを除去することによりXAトランザクションのパフォーマンスが向上します。TLogが存在しない場合、トランザクション・リカバリ中はXAトランザクション・リソース(決定子)が使用されます。『Oracle WebLogic Server JTAアプリケーションの開発』のTLogを使用しないトランザクションに関する項を参照してください。

13 WebLogic JMSのチューニング

この章では、WebLogic JMSの管理パフォーマンス・チューニング機能を実装することによってアプリケーションを最大限に活用する方法について説明します。

この章には次の項が含まれます:

- JMSパフォーマンス&チューニング・チェック・リスト

- 大きなメッセージ・バックログの処理

- クライアント・リソースのキャッシュと再利用

- 分散キューのチューニング

- トピックのチューニング

- サイズの大きなメッセージのチューニング

- 割当ての定義

- 割当て条件内での送信者のブロック

- MessageMaximumのチューニング

- ネットワーク・プロトコルの最大メッセージ・サイズの設定

- メッセージの圧縮

- メッセージのページングによるメモリーの解放

- JMSサーバーおよび宛先のメッセージのフロー制御

- 期限切れメッセージの処理

- 順序単位を使用したアプリケーションのチューニング

- 一方向のメッセージ送信の使用

- メッセージング・パフォーマンスのプリファレンス・オプションのチューニング

- クライアント側スレッド・プール

- JMS .NETクライアント・アプリケーションのベスト・プラクティス

- Oracle Data Guard環境の考慮事項

JMSパフォーマンス&チューニング・チェック・リスト

次の項には、WebLogic JMSをチューニングするときに考慮する項目のチェックリストが記載されています。

- 必ず割当てを構成します。「割当ての定義」を参照してください。

- 必要に応じて、デフォルトのページングの設定が適用されることを確認します。「メモリーを解放するためにメッセージをページ・アウト」を参照してください。ページングによりパフォーマンスが低下されますが、JVMメモリーが不足している場合には必要です。

- 大きなメッセージ・バックログを回避します。「大きなメッセージ・バックログの処理」を参照してください。

- すべてのアプリケーションでは、デフォルトの接続ファクトリではなく、カスタム接続ファクトリを使用します。MDBを使用するときも同じです。デフォルトの接続ファクトリは、チューニング不可能ですが、カスタム接続ファクトリには、パフォーマンス・チューニングの複数のオプションが用意されています。

- JNDIコンテキストと参照、JMS接続、セッション、コンシューマまたはプロデューサなどのJMSクライアント・リソースをキャッシュして再利用できるように、アプリケーションを書込みます。これらのリソースを作成するには、比較的コストが高くなります。キャッシュの必要があるタイミングとビルトイン・プーリング機能については、「クライアント・リソースのキャッシュと再利用」を参照してください。

- 非同期コンシューマおよびMDBについては、接続ファクトリ上のMessagesMaximumをチューニングします。MessagesMaximumを増加すると、パフォーマンスが向上され、MessagesMaximumを最小値までに減少すると、パフォーマンスが低減されますが、すでにメッセージ処理中のコンシューマのためにメッセージが確実に待機しないようにするのに役立ちます。「MessageMaximumのチューニング」を参照してください。

- 可能な場合はシングル・スレッド処理を実行しないでください。複数のコンカレント・コンシューマおよびプロデューサを使用して、それらを処理するのに十分なスレッドがあることを確認します。

- インスタンスを十分に使用できるようにサーバー側アプリケーションをチューニングします。これらのアプリケーションのために専用スレッド・プールを作成することを検討してください。「メッセージドリブンBeanのチューニング」を参照してください。

- 非同期コンシューマのあるクライアント側アプリケーションについては、「クライアント側スレッド・プール」を参照してクライアント側スレッド・プールをチューニングします。

- 「WebLogic永続ストアのチューニング」に記載されているように永続性をチューニングします。通常、複数のJMSサーバー、宛先およびその他のサービスで同じストアを共有して同時リクエストを単一の物理I/Oリクエストに集約し、JTAトランザクションが1つ以上のストアにまたがる可能性を減らすのは最良の方策です。1つのストアが現在の負荷を処理していない場合のみ複数のストアの使用を検討する必要があります。

- 大きなメッセージがある場合は、「大きなメッセージのチューニング」を参照してください。

- 接続ファクトリ・ターゲットを注意深く構成してクラスタへの不必要なメッセージのルーティングを防ぎます。メッセージはクライアントの接続ホストを通じてフローして、最後の宛先に移動するので、2つのサーバーを通じてルーティングされます。サーバー側のアプリケーションの場合、クラスタへの接続ファクトリをターゲットにします。クライアント側のアプリケーションの場合、分散宛先を操作し、分散宛先メンバーをホストするサーバーへの接続ファクトリのみをターゲットにします。クライアント側のアプリケーションの場合、シングルトン宛先を操作し、宛先をホストする同じサーバーへの接続ファクトリをターゲットにします。

- JTAトランザクションにJMSとJDBCの両方の操作が含まれている場合、JDBC LLRの最適化を有効化を検討します。LLRは、一般的に使用される安全な「ACID」最適化で、パフォーマンスを大幅に向上しますが、いくつか短所があります。「トランザクションのチューニング」を参照してください。

- Javaクライアントを使用している場合、小さいjarサイズがパフォーマンスより重要な場合を除いて、javaシン・クライアントを使用しないでください。シン・クライアントは、T3を指定しても低速IIOPプロトコルを使用するので、かわりにjavaフル・クライアントを使用します。『Oracle WebLogic Serverスタンドアロン・クライアントの開発』を参照してください。

- WebLogic JMSストア・アンド・フォワードのチューニングに従って、JMSストア・アンド・フォワードをチューニングします。

- WebLogicメッセージング・ブリッジのチューニングに従って、WebLogicメッセージング・ブリッジをチューニングします。

- 非永続な非トランザクションリモート・プロデューサ・クライアントを使用している場合、一方向コールの有効化を検討します。「一方向のメッセージ送信の使用」を参照してください。

- JMS分散キューを使用します。『Oracle WebLogic Server JMSアプリケーションの開発』の分散キューの使用に関する項を参照してください。

- すでに分散キューを使用している場合、「分散キューのチューニング」を参照してください。

- 上級分散トピック機能(PDT)の使用を考慮します。『Oracle WebLogic Server JMSアプリケーションの開発』の上級パブリッシュ/サブスクライブ・アプリケーションの開発に関する項を参照してください。

- アプリケーションがトピックを使用する場合、トピックのチューニングを参照してください。

- 優先度によってソートされた宛先などのソート済宛先を構成しないでください。FIFO宛先またはLIFO宛先は、最も効率のよい宛先です。大きなメッセージ・バックログがある場合、宛先のソート処理はコストの高い処理であり、数百のメッセージのバックログの場合はパフォーマンスが低減されます。

- セレクタ設計を使用します。『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージのフィルタ処理に関する項を参照してください。

- 宛先をホストしているのと同じWebLogic Serverでアプリケーションを実行します。これにより、ネットワーキングおよび一部またはすべてのマーシャリング・オーバーヘッドが削除され、ネットワークとCPUの使用率を大幅に減少できます。また、確実にトランザクションは1つのサーバーに対してローカルにできます。これは、アプリケーション・サーバーの組込みメッセージングを使用する主な利点の1つです。

大きなメッセージ・バックログの処理

メッセージ送信者がコンシューマより速くメッセージを挿入する場合、メッセージはメッセージのバックログに蓄積されます。次の例のような理由で大きなバックログが問題になる場合があります。

- コンシューマが受信メッセージ・ロードを処理できない、失敗している、または分散キューで正常にロード・バランスされていないことを示しています。

- サーバーがメモリー不足になり、サーバーが動作しなくなる可能性があります。

- 高ガベージ・コレクション(GC)オーバーヘッドになる可能性があります。JVMのGCオーバーヘッドは、JVM内のライブ・オブジェクト数に部分的に比例しています。

メッセージ処理パフォーマンスの向上

確認する必要がある領域の一つとして、メッセージ処理パフォーマンス全体の向上があります。いくつかの提案を次に示します。

- 「JMSパフォーマンス&チューニング・チェック・リスト」に記載されているJMSチューニングに関する推奨に従います。

- 新規に開発されたアプリケーションにおけるプログラム・エラーを確認します。特に、非トランザクション・コンシューマがメッセージを承認していること、トランザクション・コンシューマがトランザクションをコミットしていること、プレーンjavax.jmsアプリケーションがjavax.jms.Connection.start()を呼出したこと、および特定のアプリケーションのニーズによってトランザクション・タイムアウトがチューニングされていることなどを確認します。プログラミング・エラーの現象としては、コンシューマがメッセージを何も受信しない(start()を呼出したことを確認する)、多くのキューが保留状態になっている、シャットダウンおよび再起動後に、すでに処理されている永続メッセージが再表示される、遅延後に、すでに処理されたトランザクション・メッセージが再表示される(デフォルトJTAタイムアウトは30秒で、デフォルト処理済セッション・タイムアウトは1時間)といった現象があげられます。

- コンシューマによって処理されていないキューのWebLogic統計を確認します。分散キューに関する問題については、「分散キューのチューニング」を参照してください。

- 保留カウントの高いトピックのWebLogic統計を確認します。これによって、通常は現在サービスが提供されていないトピック・サブスクリプションがあることが示されます。メッセージの処理を担当するコンシューマ・クライアントのレスポンスが遅延したり応答しない場合がある、永続サブスクリプションがもう必要ないため削除する必要がある可能性がある、あるいは遅延分散トピックの転送によってメッセージが蓄積していく可能性があります。WebLogic Server管理コンソールで個別の永続サブスクリプションの統計を確認できます。アプリケーションでは、大きなバックログの永続サブスクリプションが作成され、削除されていない場合があります。処理されていない永続サブスクリプションは、管理上破棄されないかぎり、または標準JMSクライアントによってサブスクライブ解除されるまでは、継続して累積されます。

- すべてのメンバーがアクティブとは限らない場合、分散トピックの動作を理解します。分散トピックでは、特定のトピックのメンバーに対して生成したすべてのメッセージがリモートのトピックのメンバーにトランスポートされます。リモートのトピック・メンバーが利用不可能な場合、生成されたメッセージがローカル・トピック・メンバーに格納され、後でトランスポートされます。そのため、トピックのメンバーが長期間にわたって利用不可能な場合、アクティブなメンバーに大きなバックログが生成されます。いくつかのアプリケーションでは、これらのバックログにメッセージの有効期限を設定して対処できます。「メッセージ有効期限ポリシーの定義」を参照してください。

- ある特定のアプリケーションでは、処理されていない古いメッセージが自動的に削除されても問題ありません。「期限切れのメッセージの処理」を参照してください。

- トランザクションMDBの場合は、MDBトランザクション・バッチングを使用します。これにより、いくつかの使用例において5倍向上できます。

- 分散キューを使用して、クラスタにJVMをさらに追加します(分散キュー・メンバーのインスタンスをさらに追加するために)。たとえば、200,000個のメッセージ・バックログをJVM当たり100,000個のメッセージではなく、50,000個のメッセージが存在するように4つのJVMに分割します。

- クライアント・アプリケーションの場合は、同期コンシューマではなく、非同期コンシューマを使用します。非同期コンシューマを使用すると、ネットワーク・オーバーヘッドおよび待機時間が少なくて、メッセージ待ちの間にスレッドがブロックされません。

- 同期コンシューマ・クライアント・メッセージの場合は、CLIENT_ACKNOWLEDGEを使用してプリフェッチを有効にして、一度に複数の使用済メッセージを承認できるようにし、AUTO_ACKNOWLEDGEではなく、DUPS_OK_ACKNOWLEDGEを使用することを考慮します。

- 非同期コンシューマ・クライアント・アプリケーションの場合は、AUTO_ACKNOWLEDGEではなくDUPS_OK_ACKNOWLEDGEの使用を検討します。

- 一括処理を使用します。たとえば、各トランザクションに複数のメッセージを含めるか、または複数の小さいメッセージではなく大きなメッセージを1つ送信します。

- 非恒久サブスクライバ・クライアント側のアプリケーションによって処理されていません(「削除済」)メッセージについては、MULTICAST_NO_ACKNOWLEDGEを調べます。このモードを使用すると、メッセージが同時にUDPマルチキャスト上のサブスクライバにブロードキャストされます。

メッセージ生成の制御

確認する必要があるもう一つの領域は、メッセージ生成の遅延または停止です。いくつかの提案を次に示します。

- 割当てを低く設定します。「割当ての定義」を参照してください。

- プロデューサ・スレッド数を小さくします。

- 割当て条件時の送信者のブロックに記載されているように、割当て条件のときに発生する送信者のブロックのタイムアウトをチューニングします。タイムアウトは、接続ファクトリでチューニング可能です。

- しきい値条件においてプロデューサのコールを自動的に遅くするプロデューサ・フロー制御をチューニングします。「JMSサーバーと宛先上のメッセージ・フローの制御」を参照してください。

- アプリケーションを変更してフロー制御を実装します。たとえば、いくつかのアプリケーションでは、コンシューマによって前に生成されたメッセージのバッチ(ウィンドウ・プロトコル)が正常に処理されるまで、プロデューサは追加のメッセージを挿入できません。その他のアプリケーションでは、リクエストまたはレスポンス・アルゴリズムを実装して、前の応答を受信しないかぎり、新しいリクエストが送信されません(基本的に、ウィンドウのサイズが1であるウィンドウ・プロトコル)。いくつかの場合は、RMI/EJB/Servletからの同期フローが十分であるためJMSをチューニングする必要はありません。

メッセージ生成の制御に関する欠点

メッセージ処理の遅延または停止には、少なくとも次の2つの短所があります。

- プロデューサをコールする下流フローにバックプレッシャをかけます。下流フローによっては、バックプレッシャを処理することができないものもあり、プロデューサの背後に作成されるバックログを処理するのが困難です。バックログの場所は、プロデューサのコール先によって異なります。たとえば、サーブレットによってプロデューサがコールされる場合、バックログがパケットとして発生され、受信するネットワーク・ソケットまたはネットワーク・カード上に累積されます。

- サーバー・スレッド上のコールをブロックすると、スレッド・スタベーション、アクティブなスレッド数の過多またはデッド・ロックなどの問題が発生する可能性があります。通常、この問題を解決するには、プロデューサ・スレッドがサイズを制限した専用のスレッド・プールで実行されていることを確認する必要があります。これにより、ブロック・スレッドは他のスレッド・プールのアクティビティに影響を与えないことを確認できます。たとえば、EJBまたはサーブレットによって「send」が呼出され、長い時間の間ブロックされる可能性がある場合、最大スレッド数制約を持つカスタム・ワーク・マネージャを構成し、EJB/servletのdispatch-policyを設定して、このワーク・マネージャを参照します。

クライアント・リソースのキャッシュと再利用

送受信メッセージに比べてJMSクライアントのリソースを作成するのは、コストの高い操作です。これらのリソースを各メッセージごとに再作成するのではなく、キャッシュまたはプールして再利用する必要があります。これには、コンテキスト、宛先、接続ファクトリ、接続、セッション、コンシューマまたはプロデューサが含まれます。

また、これらのリソースの使用が安全に終了した後、アプリケーションでは、コンテキスト、接続、セッション、コンシューマまたはプロデューサをクローズすることが重要です。使用されていないリソースをクローズしないと、メモリー・リークの問題が発生し、JVM全体のパフォーマンスが低減されます。これにより、メモリー不足になってJVMに失敗します。JNDIコンテキストにはclose()メソッドがあり、JMS接続を自動的にクローズすると、接続を使用して作成されたすべてのセッション、コンシューマおよびプロデューサがクローズされることに注意してください。

サーバー側アプリケーションの場合は、WebLogicは、リソース参照を使用してアクセスされたJMSリソースを自動的にラップしプールします。『Oracle WebLogic Server JMSアプリケーションの開発』のEJBとサーブレットでWebLogic JMSを使用するためのサポートの強化に関する項を参照してください。このプーリング・コードは、ターゲット宛先が頻繁に変更する場合、プロデューサのプーリングを適切に行いません。ただし、この問題を回避するために、次の操作を実装します。アプリケーションがcreateProducer()を呼出すと、宛先にnullを渡して無名プロデューサを使用して、そのかわりに、目的の宛先を各送信コールに引き渡します。

- JMSリソースが多く割り当てられていたり、またはリークしていないか確認するには、mbeanの統計を監視するか、JVMに組み込まれている特定の機能を使用します。コンソール、WLSTまたはjavaコードを使用して、mbeanの統計を監視できます。

- JVMヒープ統計でメモリー・リークまたは予期しない高い割当て数を確認します。

- 同じように、WebLogicの統計における、メモリー・リークまたは予期しない高い割当て数を確認します。

分散キューのチューニング

作成されたメッセージがすべての分散キュー・メンバーの間に均等にロード・バランスされていない場合、プロデューサ接続ファクトリの構成を変更して、サーバー・アフィニティ(デフォルトで有効に設定されています)を無効に設定してください。

いったん作成されると、JMSコンシューマは特定のキュー・メンバーに固定されます。これにより、コンシューマがすべての分散キュー・メンバーの間に均等にロード・バランスされないという問題が発生する可能性があります。特に、すべてのコンシューマの初期化後、新しいメンバーが利用可能な場合に、この問題が発生します。コンシューマがすべての分散キュー・メンバーの間に均等にロード・バランスしない場合、メッセージを処理するために設計されたクラスタにターゲット指定されたMDBを使用するのが、ベストな方法です。WebLogic MDBは、すべての分散キュー・メンバーが処理されていることを自動的に確認します。MDBのオプションが存在しない場合に、コンシューマのロード・バランシングを向上するための提案を、次に示します。

- アプリケーションでは、コンシューマが十分作成され、コンシューマの接続ファクトリは、利用可能なロード・バランシングのオプションを使用してチューニングされていることを確認します。特に、デフォルトのサーバー・アフィニティ設定を無効にすることを検討します。

- コンシューマが定期的にクローズされ、再作成されるようにアプリケーションを変更します。これにより、コンシューマにバランスが再ロードされます。

- 分散キューの論理名からではなく、個別のキュー・メンバーから使用します。各分散キュー・メンバーは、JNDIでjms-server-name@distributed-destination-jndi-nameとして個別に通知されています。

- トランスポートを有効にするには、分散キューを構成します。分散キューをトランスポートすると、コンシューマのないメンバー宛先にアイドルになっているメッセージが自動的と内部的にコンシューマのあるメンバーにトランスポートされます。この方法は、メッセージ・ロードの高いアプリケーションに対しては、現実的ではない場合があります。

注意:
キュー・トランスポートは、WebLogic JMSのUnit-of-Order機能と互換性がありません。この機能を使用すると、トランスポートするメッセージが機能しなくなる場合があります。

『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項、および『Oracle WebLogic Server JMSリソースの管理』の高度なJMSシステム・リソースの構成に関する項を参照してください。

トピックのチューニング

次の項では、WebLogicトピックのチューニング方法について説明します。

- シングルトン・トピックを分散トピックに変換する場合があります。パーティション化されたポリシーを持つ分散トピックは、通常、レプリケートされたポリシーを選ぶよりもパフォーマンスが優れます。

- 特に分散トピックを取り扱うときなど、トピック・メッセージの処理にMDBを活用することを強くお薦めします。MDBを使用すると、複数のサブスクリプションの作成とサービス提供が自動化されるとともに、高度な拡張性オプションを利用して複数の分散トピック・メンバー全体で1つのサブスクリプションのメッセージを自動的に配信できます。

- 共有可能なサブスクリプションの拡張があり、これを使用すると単一トピックのサブスクリプション上のメッセージを複数のJVM上で複数のサブスクリプションによって並列で処理されるようにできます。WebLogic MDBは、互換性 モードでないとき、この機能を活用します。

- 作成されたメッセージがPartitioned Distributed Topicのメンバーの間に均等にロード・バランスされていない場合、プロデューサ接続ファクトリの構成を変更して、サーバー・アフィニティ(デフォルトで有効に設定されています)を無効に設定してください。

- これらの前述の上級機能を使用する前に、次の関連ドキュメントをじっくりと確認することをお薦めします。

- 『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項

- 『Oracle WebLogic Server JMSリソースの管理』の上級パブリッシュ/サブスクライブ・アプリケーションの開発に関する項

- 『Oracle WebLogic Server JMSリソースの管理』のJMS宛先可用性ヘルパーAPIと分散宛先を使用した高度なプログラミングに関する項

非恒久トピック・パブリッシャのチューニング

WebLogic Server 9.0以降では、非恒久トピック・メッセージ・パブリッシュ・リクエストは、現在メッセージの処理準備ができているすべてのコンシューマにメッセージが送られるまでブロックします。このため、コンシューマの数が多い非恒久トピック・パブリッシャで、メッセージの公開に予想よりも時間がかかる場合があります。コンシューマを待機せず、メッセージがJMSサーバーに達したことを確認するまで待機するパブリッシュに戻すには、次のプロパティを使用します。

-Dweblogic.messaging.DisableTopicMultiSender=true

サイズの大きなメッセージのチューニング

次の項では、サイズの大きなメッセージを処理する際にJMSのパフォーマンスを向上させる方法について説明します。

- MessageMaximumのチューニング

- ネットワーク・プロトコルの最大メッセージ・サイズの設定

- メッセージの圧縮

- メッセージのページングによるメモリーの解放

割当ての定義

メッセージ数の割当てを必ず構成することを強くお薦めします。割当てを構成すると、メモリー不足の原因になる大きなメッセージ・バックログが発生しません。WebLogic JMSでは、割当てがデフォルトで設定されていません。

割当てを設定するために複数のオプションがありますが、多くの場合は、宛先レベルの割当てを使用するより、Messages Maximum割当てを各JMSサーバーに設定するのみで十分です。現在のすべてのJMSメッセージでは、メッセージがページ・アウトされても、JVMメモリーが消費されます。これは、ページングにより、メッセージ・ヘッダーではなく、メッセージ本文のみページ・アウトされるためです。キューに関する原則として、現在のすべてのJMSメッセージでは、512バイトのメモリーが消費されることが推測されます。トピックに関する原則として、現在のJMSメッセージでは、256バイトのメモリーとメッセージをまだ承認していないサブスクライバのために追加の256バイトのメモリーが消費されることが推測されます。たとえば、トピック上に3つのサブスクライバがある場合、いずれかのサブスクライバによって処理されていない1つの発行されたメッセージに対して、メッセージがページ・アウトされた場合でも、256 + 256*3 = 1024バイトのメモリーが消費されます。ベスト・プラクティスは、メッセージ・ヘッダー・メモリー使用量が原則によって示された量より大幅に小さいとしても、メモリー使用量に対して控えめな推定を行うことです。

以前のリリースでは、複数のレベルの割当てがありました。宛先には独自の割当てがあり、同時にJMSサーバー内の割当てをめぐって競合する必要もありました。このリリースでは、割当てのレベルは1つだけです。宛先では、独自のプライベートの割当てを使用することも、共有割当てを使用して他の宛先と競合することもできます。

独自の割当てを定義する宛先は、JMSサーバーの割当てのスペースを共有しません。JMSサーバーでは、引き続きメッセージとバイトの割当てを直接構成できますが、これらのオプションは割当てリソースを参照しない宛先の割当てを定義するためにのみ使用できます。

割当てリソース

割当てとは、構成可能な名前付きのJMSモジュール・リソースです。割当てでは、メッセージおよびバイトの最大数を定義します。これを1つまたは複数の宛先に関連付けることで、定義した最大数を強制することができます。同じ割当てを参照する複数の宛先は、割当てリソースの共有ポリシーに従ってその割当てを共有します。

割当てリソースでは、次のパラメータを構成できます。

表13-1割当てのパラメータ

属性

説明

最大バイト数と最大メッセージ数

割当ての「最大メッセージ数」および「最大バイト数」パラメータでは、その割当てリソースで使用できるメッセージとバイトの最大数を定義します。保留中のメッセージは考慮されません - つまり、処理中であったり遅延されていたり、もしくは配信が抑制されているメッセージが、メッセージ数やバイト数の割当てに突き合わせて計数されます。

割当ての共有

割当てリソースの「共有」パラメータでは、同じ割当てリソースを参照する複数の宛先が、リソースの使用において相互に競合するかどうかを定義します。

割当てポリシー

「ポリシー」パラメータでは、使用できる割当てがない場合に、個々のクライアントが割当てをめぐってどのように競合するかを定義します。「サイズの大きなメッセージのチューニング」で説明されているとおり、接続ファクトリで送信タイムアウト機能が有効になっている場合、このパラメータは送信リクエストのブロックが解除される順序に影響します。

割当ての構成パラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのQuotaBeanを参照してください。WebLogic Server管理コンソールを使用した割当てリソースの構成に関する指示については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの宛先用割当ての作成に関する項を参照してください。

宛先レベルの割当て

宛先では、割当てのバイトおよびメッセージの最大数は定義しないことになりました。代わりに、これらの値を定義した割当てリソースと、共有および競合に関する割当てポリシーを使用できます。

宛先の「割当て」パラメータでは、その宛先に割当てを強制するためにどの割当てリソースを使用するかを定義します。この値は動的で、いつでも変更できます。ただし、割当てリソースを変更した時点でその割当ての未処理リクエストがあると、そうしたリクエストはjavax.jms.ResourceAllocationExceptionで失敗します。

注意:
割当ての未処理リクエストは、割当てリソースが変更されたときに失敗します。これは、宛先の割当てを他の割当てに切り替えたときに失敗することを意味し、割当てリソースのメッセージ属性やバイト属性を変更したときには失敗しません。

JMSサーバー・レベルの割当て

宛先で割当てを構成しない場合もあります。JMSサーバーの割当てを使用すると、これらの「割当てを構成していない」宛先で使用するリソースを制限できます。「割当て」属性が明示的に設定されていないすべての宛先は、それらがデプロイされているJMSサーバーの割当てを共有します。この場合の動作は、「共有」パラメータが有効になっている各JMSサーバーに特別な割当てリソースが定義されている場合とまったく同じです。

JMSサーバーの割当てのインタフェースは、以前のリリースから変更されていません。JMSサーバーの割当ては、JMSServerMBeanのメソッドを使用して完全に制御できます。JMSサーバーの割当ての割当てポリシーは、JMSサーバーで「ブロッキング時の送信ポリシー」パラメータを使用して設定します。詳細については、「JMSサーバーでの「ブロッキング時の送信ポリシー」の指定」を参照してください。JMSサーバーの割当ての割当てポリシーも、他の割当てのポリシー設定と同じように機能します。それは、他の割当てのポリシー設定と同じように機能します。

割当て条件内での送信者のブロック

- 接続ファクトリでの送信タイムアウトの定義

- JMSサーバーでのブロッキング時の送信ポリシーの指定

接続ファクトリでの送信タイムアウトの定義

割当て条件内で(送信タイムアウトを定義して)プロデューサをブロックすると、アプリケーションのパフォーマンス、および割当て失敗時のメッセージ送信の継続した再試行におけるベンチマークが大幅に向上します。「送信タイムアウト」機能を使用すると、宛先でスペースを利用できるようになるまで指定の時間にわたってメッセージの生成を待機できるため、メッセージ送信処理をより細かく制御できます。たとえば、プロデューサがリクエストを行い、十分なスペースが存在しない場合、プロデューサはスペースが利用可能になるまでブロックされるか、または処理がタイムアウトになります。別のフロー制御方法については、「JMSサーバーおよび宛先のメッセージのフロー制御」を参照してください。

WebLogic Server管理コンソールを使用して、宛先がメッセージの最大割当てを超過したときにJMS接続ファクトリがメッセージのリクエストをブロックする時間を定義する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージ・フロー制御の構成に関する項に記載されている指示に従って、「JMS接続ファクトリ: 構成: フロー制御」ページに移動します。

2. 「送信タイムアウト」フィールドに、メッセージ宛先に十分なスペースが存在しない場合に送信側がメッセージをブロックする時間をミリ秒単位で入力します。ここで指定した期間が経過すると、次のいずれかの結果が発生します。

- タイムアウト期間の終了前に十分なスペースが利用できるようになった場合、操作は続行されます。

- タイムアウト期間の終了前に十分なスペースが利用できない場合、リソース割当て例外が発生します。
値を0に設定してブロッキング時の送信ポリシーを有効にしない場合、宛先で十分なスペースが利用できないときに「リソース割当て」例外が発生します。

「送信タイムアウト」フィールドの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: フロー制御に関する項を参照してください。

3. 「保存」をクリックします。

JMSサーバーでのブロッキング時の送信ポリシーの指定

ブロッキング時の送信ポリシーを使用すると、メッセージ割当てを超過した宛先で複数のプロデューサによるスペースの競合が存在するときに、小さいメッセージを大きいメッセージより先に送信するかどうかに関するJMSサーバーのブロック動作を定義できます。

WebLogic Server管理コンソールを使用して、宛先が最大メッセージ割当てに達したときにJMSサーバーがメッセージ・リクエストをブロックする方法を定義する手順は次のとおりです。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーのしきい値と割当ての構成に関する項に記載されている指示に従って、WebLogic Server管理コンソールの「JMSサーバー: 構成: しきい値と割当」ページに移動します。

2. 「ブロッキング時の送信ポリシー」リスト・ボックスから、次のいずれかのオプションを選択します。

- 「FIFO」 - 同じ宛先に対するすべての送信リクエストは、スペースが使用できるようになるまで1つずつキューに入れられます。送信リクエストの実行は、スペースを待機する別の送信リクエストがその前に存在するかぎり許可されません。

- 「プリエンプティブ」 - スペースが使用可能な場合、送信操作が別のブロックしている送信操作よりも先に処理できることを示します。つまり、現在のリクエストに対する十分なスペースが存在する場合、スペースを待機している他のリクエストがその前に存在する場合でもそのスペースが使用されます。

- 「ブロッキング時の送信ポリシー」フィールドの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: 構成: しきい値と割当て関する項を参照してください。

3. 「保存」をクリックします。

MessageMaximumのチューニング

WebLogic JMSでは、非同期コンシューマ(または、メッセージ・リスナーとして知られている)またはプリフェッチを有効にした同期コンシューマに送信されたメッセージがパイプラインされます。これにより、パフォーマンスが向上します。これは、メッセージがサーバーからクライアントへに内部的にプッシュされと集合するためです。接続ファクトリのMessagesMaximumの設定を構成すると、JMSサーバーとクライアント間のメッセージ・バックログ(パイプラインのサイズ)をチューニングできます。『Oracle WebLogic Server JMSアプリケーションの開発』の非同期のメッセージ・パイプラインに関する項を参照してください。

一部の環境では、MessagesMaximumパラメータをチューニングすることでパフォーマンスが大幅に向上することがあります。たとえば、JMSアプリケーションで確認応答やコミットが保留されている場合などです。この場合、MessagesMaximumに次の値を設定することをお薦めします。

2 * (ack or commit interval) + 1

たとえば、JMSアプリケーションで一度に50メッセージを確認応答する場合、MessagesMaximumの値を101に設定します。

MessageMaximum制限のチューニング

MessagesMaximumの値が大きすぎると、以下のような状況になることがあります。

- クライアントのメモリー使用量が増加します。

- 既存のクライアントのパイプラインがメッセージで一杯になり処理が集中します。たとえば、MessagesMaximumに10,000,000を設定した場合、最初に接続するコンシューマ・クライアントで、すでに宛先に届いているすべてのメッセージが取得されます。この場合、他のコンシューマは1つもメッセージのない状態のままで、最初のコンシューマで不要なメッセージのメッセージのバックログが作成され、システムのメモリーが不足することがあります。

- パケットが大きすぎるという例外が発生し、コンシューマが膠着状態になります。コンシューマに送信されたメッセージの合計サイズが、現在のプロトコルの最大メッセージ・サイズ(デフォルト・サイズは10MB。コンソールを使用してWebLogic Serverインスタンスごとに、また-Dweblogic.MaxMessageSizeコマンド行プロパティを使用してクライアントごとに構成されている)より大きいと、メッセージの配信が失敗します。

ネットワーク・プロトコルの最大メッセージ・サイズの設定

大きなメッセージを送受信するときに、WebLogic ServerインスタンスのみではなくWebLogicクライアントも構成する必要があります。

多くのプロトコル(T3を含む)は、WLSでのネットワーク・コールのサイズがデフォルトで10MBに制限されています。個別のJMSメッセージのサイズまたは同じネットワーク・コールに一括処理されている一連のJMSメッセージのサイズは、制限値を超える場合、パッケージのサイズが大きすぎるという例外が発生するか、またはコンシューマが停止する可能性があります。非同期コンシューマを使用すると、複数のJMSメッセージが同じネットワーク・コールに一括処理されます。このように一括処理されたメッセージのサイズを制御する場合は、「MessageMaximumの制限のチューニング」を参照してください。

サーバーのインスタンスにメッセージの最大サイズを設定するには、含まれるすべてのデフォルトのチャネルまたはカスタム・チャネルに対して、サポート済の各プロトコルの最大のメッセージ・サイズをチューニングしてください。このコンテキストでは、「メッセージ」とは指定したプロトコル上のJMSコールのみではなく、すべてのネットワーク・コールを意味します。

次のコマンド行プロパティを使用して、クライアント上の最大のメッセージ・サイズを設定します。

-Dweblogic.MaxMessageSize

注意:
この設定は、JMS関連パケットのみでなく、クライアントに配信されるすべてのWebLogic Serverネットワーク・パケットに対して適用されます。

メッセージの圧縮

メッセージ圧縮のしきい値は、WLMessageProducerインタフェースのJMS API拡張機能を使用することによってプログラム的に設定するか、接続ファクトリまたはJMS SAFリモート・コンテキストで「デフォルト圧縮しきい値」を指定することによって管理的に設定できます。メッセージの種類によっては、圧縮によって実際にはサイズが大きくなることがあるため、圧縮されたメッセージが宛先の割当てに影響するおそれがあります。

WebLogic Server管理コンソールを使用してデフォルト圧縮しきい値を構成する手順については、次を参照してください。

- 接続ファクトリ: Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルトの配信パラメータの構成に関する項。

- ストア・アンド・フォワード(SAF)リモート・コンテキスト: Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAFリモート・コンテキストの構成に関する項。

構成されたメッセージ圧縮は、クライアント送信の場合はプロデューサ、メッセージ受信またはメッセージ・ブラウズの場合は接続ファクトリに対して、またはSAF転送を通じて実行されます。メッセージはGZIPで圧縮されます。圧縮は、メッセージのプロデューサとコンシューマが別々のサーバー・インスタンスに配置されていてメッセージがJVM境界をまたぐ場合(通常は、WebLogicドメインが別のマシンにあってネットワーク接続をまたぐ場合)にのみ発生します。解凍は、メッセージのコンテンツがアクセスされたときに、クライアント・サイドで自動的に発生します。ただし、以下の状況でも解凍が発生します。

- 圧縮形式のXMLメッセージでメッセージ・セレクタを使用すると、解凍の問題が発生します。これは、メッセージ本文は、メッセージをフィルタするためにアクセスする必要があるからです。XMLメッセージ・セレクタを定義する場合の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージのフィルタ処理に関する項を参照してください。

- 以前のバージョンのWebLogic Serverと相互運用していると、解凍が発生することがあります。たとえば、メッセージング・ブリッジを使用している場合、現在のリリースのWebLogic Serverから送信されたメッセージが以前のバージョンのWebLogic Serverで受信されると、受信サイドでメッセージが解凍されます。

サーバー側では、ディスクに書き込まれるときでも、メッセージは常に圧縮されたままです。

メッセージのページングによるメモリーの解放

メッセージ・ページング機能を使用すると、メッセージ負荷のピークときにJMSサーバーによって自動的に仮想メモリーの開放が試行されます。この機能は、大容量のメッセージ領域を使用するアプリケーションでは大きなメリットがあります。JMSサーバーでは常にメッセージ・ページングが有効になっており、メッセージ・ページング・ディレクトリは自動的に作成されるため構成する必要はありません。ただし、「ページング・ディレクトリ」オプションを使用してディレクトリを指定することもでき、その場合はページングされたメッセージがこのディレクトリ内のファイルに書き込まれます。

JMSサーバーでは、ページング・ディレクトリに加え、ファイル・ストアまたはJDBCストアを使用して、永続メッセージが格納されます。ファイル・ストアは、ユーザー定義またはサーバーのデフォルトのストアのことです。ページングされたJDBCストアの永続メッセージは、JDBCストアとJMSサーバーのページング・ディレクトリの両方にコピーされます。ページングされたファイル・ストアの永続メッセージの小さいメッセージは、ファイル・ストアとJMSサーバーのページング・ディレクトリの両方にコピーされます。ページングされた大きなファイル・ストアのメッセージは、ページング・ディレクトリにコピーされません。「永続ストアを使用するときのベスト・プラクティス」を参照してください。

ただし、ページアウトされるメッセージは消費するメモリーのすべてを解放することはありません。メッセージ・ヘッダーは、メッセージ本文と一緒にページアウトされるすべてのユーザー・プロパティを除いて、検索/ソート/フィルタリングで使用するためにメモリーに残るからです。ページングされるメッセージの選択にセレクタを使用するキュー・アプリケーションでは、ページアウトされたメッセージをページ・インして戻す必要があるため、パフォーマンスが大幅に低下する場合があります。これは、メッセージ・ヘッダー・フィールド(CorrelationIDなど)に基づきメッセージを選択するトピックまたはアプリケーションに適用されません。原則として、各メッセージは、ページ・アウトしたときにJVMメモリーの512バイトを使用することを仮定します。

メッセージ・ページング・ディレクトリの指定

ページング・ディレクトリが指定されていない場合、ページングされたメッセージの本文はドメインのルート・ディレクトリのservernameサブディレクトリ内にある、デフォルトの\tmpディレクトリに書き込まれます。たとえば、デフォルトのページング・ディレクトリが指定されていない場合、次のディレクトリがデフォルトになります。

oracle_home\user_projects\domains\domainname\servers\servername\tmp

domainnameは、ドメインのルート・ディレクトリ(通常はc:\Oracle\Middleware\Oracle_Home\user_projects\domains\domainname)です。これは、WebLogic Serverプログラム・ファイルが格納されるディレクトリ(通常はc:\Oracle\Middleware\Oracle_Home\wlserver)に対応するディレクトリです。

メッセージ・ページング・ディレクトリ属性を構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの一般的なプロパティの構成に関する項を参照してください。

「メッセージ・バッファ・サイズ」オプションのチューニング

「メッセージ・バッファ・サイズ」オプションでは、ディスクにページングされる前のメモリー内のメッセージ本文を格納するために使用するメモリーの量を指定します。「メッセージ・バッファ・サイズ」のデフォルト値は、JVMの最大ヒープ・サイズのおよそ3分の1、または最大値の512MBになります。このパラメータの設定値を大きくするほど、多くのメッセージがキューまたはトピックに待機している際にJMSでより多くのメモリーが消費されます。このしきい値を超えると、JMSはメモリー使用量をしきい値未満に抑えようとして、「ページング・ディレクトリ」オプションで指定したディレクトリに、メッセージ本文を書き込むことがあります。

このパラメータは割当てではない点に留意してください。サーバー上のメッセージ数がしきい値を超えると、サーバーはメッセージをディスクに書き込み、できるだけ速やかにメモリーから削除してメモリー使用量を減らします。ただし、新しいメッセージの受信を休止することはありません。それでも、メッセージ受信速度がページング速度を上回る場合は、メモリー不足になる可能性があります。メッセージ負荷の大きいユーザーができるかぎり高い可用性をサポートするには、割当てを設定するか、しきい値を設定してフロー制御を有効にすることで、サーバー上でのメモリー使用量を減らすことを検討してください。

JMSサーバーおよび宛先のメッセージのフロー制御

フロー制御機能を使うと、過負荷状態になっていると判断したJMSサーバーや宛先は、メッセージ・プロデューサの処理速度を遅くすることができます。「メッセージの圧縮」を参照してください。

次の項では、フロー制御の仕組みと、接続ファクトリでフロー制御を構成する方法について説明します。

- フロー制御の仕組み

- フロー制御の構成

- フロー制御のしきい値

フロー制御の仕組み

JMSサーバーまたはその宛先は、指定のバイト数またはメッセージ数のしきい値を超えると防御され、メッセージ・フロー(1秒当たりのメッセージ数)を制限するようプロデューサに指示します。

プロデューサは、JMS接続ファクトリを通じてプロデューサ用に構成された一連のフロー制御属性に基づき、生成率を制限します。プロデューサは、指定した最大フローのメッセージ数から開始して、所定の間隔ごとに(たとえば、10秒間、60秒ごとに)、サーバー/宛先がまだ防御されているかを評価します。その時点において、サーバー/宛先がまだ防御されていれば、プロデューサは所定の最小フロー値まで本番率を低下させます。

プロデューサの処理速度が低下するにつれ、しきい値条件は徐々に補正されます。これはサーバー/宛先が防御を解除されるまで行われます。この時点で、プロデューサは生成率を上げることができるようになりますが、必ずしも最大限まで上げる必要はありません。実際には、メッセージ・フローは、所定の最大フローに達してフロー制御の対象でなくなる時点までは(サーバー/宛先が防御を解除されていても)引き続き制御されます。

フロー制御の構成

プロデューサは、セッションから一連のフロー制御属性を受信します。セッションは接続から、接続は接続ファクトリから、この属性を受信します。これらの属性により、プロデューサはメッセージ・フローを調整できます。

具体的には、プロデューサはフローを最小値から最大値までの範囲内に制限する属性を受信します。プロデューサは、条件が悪くなると最小値側に移動し、改善されると最大値側に移動します。最小値側および最大値側への移行は、移行率を指定する2つの追加属性によって定義されます。また、最小値側および最大値側への移行の必要性は構成された間隔ごとに評価されます。

次の表では、フロー制御オプションについて説明します。

表13-2 フロー制御パラメータ

属性

説明

フロー制御を有効化

プロデューサがJMSサーバーによってフロー制御可能かどうかを決定します。

最大フロー

しきい値の条件に達したプロデューサに対する秒当たりの最大メッセージ数。

しきい値の条件に達したときにプロデューサでフローを制限していない場合、そのプロデューサの初期フロー制限が最大フローに設定されます。しきい値の条件に達したときにプロデューサがすでにフローを制限している場合(フロー制限は最大フロー未満)、プロデューサは次にフローが評価されるまで現在のフロー制限で処理を継続します。

いったん、しきい値条件への抵触を回避してからは、プロデューサはフロー限度を無視できなくなります。このフロー制限が「最大フロー」未満の場合、プロデューサはフローが評価されるたびにそのフローを徐々に最大フローまで増やす必要があります。プロデューサが最大フローに達すると、そのフロー制限を無視し、そのフローを制限せずに送信できます。

最小フロー

しきい値の条件に達したプロデューサに対する秒当たりの最小メッセージ数。これはプロデューサのフロー制限の下限値。つまり、フロー制限が最小フローに達したプロデューサの処理速度はWebLogic JMSによってそれ以上落とされません。

フロー間隔

プロデューサが最大フローのメッセージ数から最小フローに、またはその反対にフローを調整するときの調整期間(秒単位)。

フロー・ステップ

プロデューサがフローを最大フローのメッセージ数から最小フローに、またはその反対にフローを調整する場合に使用されるステップ数。具体的には、フロー間隔の調整期間がフロー・ステップ数に分割されます(たとえば、60秒を6ステップで除算するとステップあたり10秒になります)。

また、最大フローと最小フローの差をステップに分割することにより、移動(調整率)が計算されます。各フロー・ステップでは、次のように、現在の条件に基づき必要に応じてフローが上方または下方に調整されます。

下方への移動は、フロー間隔で指定した時間の経過に伴い、フロー・ステップで指定した値に従って幾何的に減衰する(たとえば、100、50、25、12.5)。

上方移動は線形です。差は単にフロー・ステップ数で除算されます。

フロー制御フィールドおよびこのフィールドの有効な値とデフォルト値については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMS接続ファクトリ: 構成: フロー制御に関する項を参照してください。

フロー制御のしきい値

バイト数またはメッセージ数のしきい値の構成に使用する属性は、JMSサーバーまたはその宛先の一部として定義されます。表13-2に、上限しきい値と下限しきい値がJMSサーバーまたはJMS宛先のフロー制御を開始および停止する仕組みを示します。

表13-3 フロー制御しきい値パラメータ

属性

説明

最大バイトしきい値/最大メッセージしきい値

バイト数またはメッセージ数がこのしきい値を超えると、JMSサーバー/宛先は防御され、プロデューサに対してメッセージ・フローを制限するよう指示します。

最小バイトしきい値/または最小メッセージしきい値

バイト数またはメッセージ数がこのしきい値を下回ると、JMSサーバー/宛先は防御を解除され、プロデューサに対してメッセージ・フローを増やし始めるよう指示します。

フロー制御は、メッセージの最大フローを下回っているプロデューサについては、引き続き有効です。プロデューサは、最大フローに到達してフロー制御が行われなくなるまで、生成率を上げ続けることができます。

JMSサーバーおよび宛先のその他のしきい値フィールドと割当てフィールドの詳細、およびそれらの有効値とデフォルト値については、管理コンソール・オンライン・ヘルプの次のページを参照してください。

- 「JMSサーバー: 構成: しきい値と割当て」

- 「JMSキュー: 構成: しきい値と割当て」

- 「JMSトピック: 構成: しきい値と割当て」

期限切れメッセージの処理

次の項では、メッセージの有効期限ポリシーとアクティブな有効期限処理という2つのメッセージ有効期限機能について説明します。これらの機能を使用すると、期限切れメッセージを検索する方法とそれらを検出したときの処理方法をより細かく制御できます。

アクティブなメッセージ有効期限を使用すると、期限切れメッセージが即座に消去されます。さらに期限切れメッセージの監査を使用すると、メッセージがいつ期限切れになったかをログに書き込むか、または期限切れメッセージを定義済のエラー宛先にリダイレクトすることによって、期限切れメッセージを追跡できます。

- メッセージ有効期限ポリシーの定義

- アクティブなメッセージ有効期限のチューニング

メッセージ有効期限ポリシーの定義

有効期限ポリシーを使用して、メッセージが期限切れになったときに実行するアクションを定義します。「宛先」ノードの「有効期限ポリシー」属性では、宛先ごとに有効期限ポリシーを設定できます。「有効期限ポリシー」属性を使用すると、期限切れメッセージの検出時に宛先で実行されるアクション(メッセージの破棄、メッセージの破棄とログへの書き込み、またはエラー宛先へのリダイレクト)を定義できます。

また、JMSテンプレートを使用して複数の宛先を構成する場合、「有効期限ポリシー」フィールドを使用して、すべての宛先の有効期限ポリシーをすばやく構成できます。特定の宛先に関するテンプレートの有効期限ポリシーをオーバーライドするには、その宛先の有効期限ポリシーを変更します。

有効期限ポリシーの構成手順については、次のリンクをクリックしてください。

- トピックの有効期限ポリシーを構成する

- キューの有効期限ポリシーを構成する

- テンプレートの有効期限ポリシーを構成する

- 有効期限ロギング・ポリシーを定義する

トピックの有効期限ポリシーを構成する

JMSテンプレートを使用せずにトピックの有効期限ポリシーを構成する場合は、次の手順に従います。特定のトピックに有効期限ポリシーを設定すると、JMSテンプレートに定義されている設定はオーバーライドされます。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトピック・メッセージ配信の失敗オプションの構成に関する項に記載されている指示に従って、「JMSトピック: 構成: 配信の失敗」ページに移動します。

2. 「有効期限ポリシー」リスト・ボックスから、有効期限ポリシー・オプションを選択します。

- 「破棄」 - 期限切れのメッセージがメッセージング・システムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。

- 「ログ」 - 期限切れのメッセージを削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。次の手順で、ログに書き込まれる実際の情報を「有効期限ロギング・ポリシー」フィールドで定義します。

- 「リダイレクト」 - 期限切れメッセージを現在の場所からトピックに対して定義されたエラー宛先に移動します。
トピックの有効期限ポリシー・オプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSトピック: 構成: 配信の失敗に関する項を参照してください。

3. 前の手順で「ログ」ポリシーを選択した場合、「有効期限ロギング・ポリシー」フィールドを使用して、メッセージのどの情報をログに記録するかを定義します。
「有効期限ロギング・ポリシー」の有効値の詳細は、「有効期限ロギング・ポリシーを定義する」を参照してください。

4. 「保存」をクリックします。

キューの有効期限ポリシーを構成する

JMSテンプレートを使用せずにキューの有効期限ポリシーを構成する場合は、次の手順に従います。特定のキューに有効期限ポリシーを設定すると、JMSテンプレートに定義されている設定はオーバーライドされます。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキューに関するメッセージ配信の失敗オプションの構成に関する項に記載されている指示に従って、「JMSキュー: 構成: 配信の失敗」ページに移動します。

2. 「有効期限ポリシー」リスト・ボックスから、有効期限ポリシー・オプションを選択します。

- 「破棄」 - 期限切れのメッセージがメッセージング・システムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。

- 「ログ」 - 期限切れメッセージをキューから削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。次の手順で、ログに書き込まれる実際の情報を「有効期限ロギング・ポリシー」フィールドで定義します。

- 「リダイレクト」 - 期限切れメッセージをキューから、キューに対して定義されたエラー宛先に移動します。

- キューの有効期限ポリシー・オプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSキュー: 構成: 配信の失敗に関する項を参照してください。

3. 前の手順で「ログ」ポリシーを選択した場合、「有効期限ロギング・ポリシー」フィールドを使用して、メッセージのどの情報をログに記録するかを定義します。
「有効期限ロギング・ポリシー」の有効値の詳細は、「有効期限ロギング・ポリシーを定義する」を参照してください。

4. 「保存」をクリックします。

テンプレートの有効期限ポリシーを構成する

JMSテンプレートを使用すると、似た属性設定を持つ複数の宛先(トピックまたはキュー)を効率的に定義できます。このため、宛先用の既存のテンプレート上でメッセージ有効期限ポリシーを構成できます。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSテンプレートに関するメッセージ配信の失敗オプションの構成に関する項に記載されている指示に従って、「JMSテンプレート: 構成: 配信の失敗」ページに移動します。

2. 「有効期限ポリシー」リスト・ボックスから、有効期限ポリシー・オプションを選択します。

- 「破棄」 - 期限切れのメッセージがメッセージング・システムから削除されます。削除はログに記録されず、メッセージは別の場所にリダイレクトされません。

- 「ログ」 - 期限切れのメッセージを削除し、メッセージがシステムから削除されたことを示すエントリをサーバー・ログ・ファイルに書き込みます。ログに書き込まれる実際の情報は、次の手順に示す「有効期限ロギング・ポリシー」で定義します。

- 「リダイレクト」 - 期限切れメッセージを現在の場所から宛先に対して定義したエラー宛先に移動します。

- テンプレートの有効期限ポリシー・オプションの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSテンプレート: 構成: 配信の失敗に関する項を参照してください。

3. 手順4で有効期限を記録するポリシーを選択した場合、「有効期限ロギング・ポリシー」フィールドを使用して、メッセージのどの情報をログに記録するかを定義します。
「有効期限ロギング・ポリシー」の有効値の詳細は、「有効期限ロギング・ポリシーを定義する」を参照してください。

4. 「保存」をクリックします。

有効期限ロギング・ポリシーを定義する

この項では、有効期限ポリシーについて説明します。

「有効期限ロギング・ポリシー」パラメータはこのリリースのWebLogic Serverでは非推奨となっています。代わりに、メッセージ・ライフ・サイクルのロギング機能を使用することをお薦めします。この機能を使用すると、JMSサーバーに届いたJMSメッセージに発生する基本的なイベントを、詳細な有効期限データも含め包括的に把握できます。メッセージのライフサイクルのロギング・オプションの詳細は、『Oracle WebLogic Server JMSリソースの管理』のメッセージのライフサイクルのロギングに関する項を参照してください。

たとえば、次のいずれかの値を指定できます。

- JMSPriority、Name、Address、City、State、Zip

- %header%、Name、Address、City、State、Zip

- JMSCorrelationID, %properties%

JMSMessageIDフィールドは常にログに書き込まれ、無効にはできません。したがって、有効期限ポリシーが定義されていない(「なし」)か、空の文字列として定義されている場合、ログ・ファイルへの出力にはメッセージのJMSMessageIDのみが含まれます。

有効期限ログの出力形式

期限切れメッセージがログに書き込まれる場合、メッセージのテキスト部分(タイムスタンプ、重大度、スレッド情報、セキュリティIDなどを除く)は次のフォーマットに準拠します。

<ExpiredJMSMessage JMSMessageId='$MESSAGEID' >
<HeaderFields Field1='Value1' [Field2='Value2'] … ] />
<UserProperties Property1='Value1' [Property='Value2'] … ] />
</ExpiredJMSMessage>

$MESSAGEIDはMessage.getJMSMessageID()によって返される文字列です。

例:

<ExpiredJMSMessage JMSMessageID='ID:P<851839.1022176920343.0' >
<HeaderFields JMSPriority='7' JMSRedelivered='false' />
<UserProperties Make='Honda' Model='Civic' Color='White'Weight='2680' />
</ExpiredJMSMessage>

ヘッダー・フィールドが表示されない場合、ヘッダー・フィールド行は表示されません。ユーザー・プロパティが表示されない場合、その行は表示されません。ヘッダー・フィールドとプロパティが存在しない場合、開始タグは閉じカッコ(/>)で閉じることができるので終了タグ</ExpiredJMSMessage>は必要ありません。

例:

<ExpiredJMSMessage JMSMessageID='ID:N<223476.1022177121567.1' />

すべての値は引用符で区切られます。すべての文字列値は32文字に制限されます。リクエストされたフィールドまたはプロパティが存在しない場合、それらは表示されません。リクエストされたフィールドまたはプロパティが存在するが値がない(null値)場合、それらはnullとして(単一引用符なしで)表示されます。リクエストされたフィールドまたはプロパティが空文字の場合、それらは1組の単一引用符(間にスペースなし)として表示されます。

例:

<ExpiredJMSMessage JMSMessageID='ID:N<851839.1022176920344.0' >
<UserProperties First='Any string longer than 32 char ...' Second=null Third='' />
</ExpiredJMSMessage>

アクティブなメッセージ有効期限のチューニング

アクティブな有効期限処理機能を使用すると、期限切れメッセージをそれが送信またはパブリッシュされた宛先から削除するタイミングを定義できます。メッセージは必ずしも有効期限に削除されず、ユーザー定義の秒数以内に削除されます。秒数が少ないほど、メッセージの削除が実際の有効期限に近づきます。

宛先をアクティブにスキャンして期限切れメッセージを処理するようにJMSサーバーを構成する

JMSサーバーが宛先をアクティブにスキャンして期限切れメッセージを処理する方法を定義するには、次の手順に従います。デフォルト値は30秒です。つまり、JMSサーバーは各スキャンの間で30秒待機します。

1. Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバーの一般的なプロパティの構成に関する項に記載されている指示に従って、WebLogic Server管理コンソールの「JMSサーバー: 構成: 一般」ページに移動します。

2. 「有効期限スキャン間隔」フィールドに、JMSサーバーが宛先をスキャンして期限切れメッセージを処理するサイクルの休止間隔を秒数で入力します。
アクティブなスキャンを無効にするには、0を入力します。期限切れメッセージは、検出時にシステムからパッシブに削除されます。

「有効期限スキャン間隔」属性の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJMSサーバー: 構成: 一般に関する項を参照してください。

3. 「保存」をクリックします。

設計上の選択には、JMSアプリケーションのパフォーマンスに影響を与えるものが多数あります。信頼性、スケーラビリティ、管理容易性、モニター、ユーザー・トランザクション、メッセージドリブンBeanのサポート、アプリケーション・サーバーとの統合などの要素がパフォーマンスに影響します。また、WebLogic JMSの拡張と機能もパフォーマンスに直接的な影響を与えます。

JMSのアプリケーションの設計の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のアプリケーション設計のベスト・プラクティスに関する項を参照してください。

順序単位を使用したアプリケーションのチューニング

メッセージ順序単位はWebLogic Serverの付加価値機能です。スタンドアロンのメッセージ・プロデューサや、単体として動作するプロデューサのグループは、この機能を使用して複数のメッセージを処理順序(下位順序)に応じた1つの単位にグループ化できます。この単位を順序単位(UOO)と呼び、この単位にまとめられたすべてのメッセージは作成順に従って処理されます。以下の複雑な設計パターンについてUOOを使用するように置き換えます。

- 下位順序ごとに一意のセレクタを持つ専用コンシューマ

- 下位順序ごとに1つの新しい宛先、宛先ごとに1つのコンシューマ。

『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

ベスト・プラクティス

次の項では、UOO使用時のベスト・プラクティスについて説明します。

- 厳格なメッセージ順序要件があるアプリケーションにおいて理想的です。UOOにより管理やアプリケーション設計が簡略化され、ほとんどのアプリケーションでパフォーマンスが向上します。

- MDBバッチ処理を使用すると以下のことが可能になります。

- 単一の下位順序内のメッセージ処理が高速化します。

- 同じトランザクションにおいて一度に複数のメッセージを消費します。
第10章「メッセージドリブンBeanのチューニング」を参照してください。

- 宛先にはデフォルトのUOOを構成できます。宛先では一度に1つだけのコンシューマがデフォルトのUOOのメッセージを処理します。

UOOと分散宛先の使用

分散宛先を使用している場合、厳格なメッセージ順序を確実に適用するために、各UOOは特定の物理宛先のインスタンスに固定されます。所定のUOOに対して自動的に適切な物理宛先を決定するため、以下の2つのオプションが用意されています。

- ハッシュ処理 - 通常、より高速なUOOの設定です。ハッシュ処理では物理宛先を決定するために、UOO名に対してハッシュ関数を使用します。この方法は次の点でデメリットがあります。

- 分散宛先に対する物理宛先の管理的な削除または追加を正しく処理できません。

- UOOが利用不可能な宛先にハッシュ化された場合、メッセージの送信が失敗します。

- パス・サービス - UOOごとに物理宛先をマップする、単一サーバーのUOOディレクトリ・サービスです。パス・サービスは通常、1秒間に異なる名前のUOOが数多く作成された場合、ハッシュ処理よりも低速です。この場合、メッセージの送信前に、新しいUOO名のそれぞれによってパス・サービスのチェックが暗黙的に強制されます。1秒間に作成されるUOOの数が制限されている場合、UOOのパスがクラスタ全体でキャッシュされるのでパス・サービスのパフォーマンスが問題になることはありません。

UOOを使用するための古いアプリケーションの移行

WebLogic Server 9.0より前のリリースでは、厳格なメッセージ順序要件のあるアプリケーションで次のことを行う必要がありました。

- 1つの物理宛先を1つのコンシューマと一緒に使用します。

- 非同期コンシューマの最大メッセージ・バックログ(接続ファクトリのMessagesMaximumパラメータ)は必ず1に設定します。

UOOでは、任意のサイズの複数のコンシューマおよび非同期コンシューマ・メッセージ・バックログが利用できるので、これらの要件が幅広く緩和されています。UOOを使用するために古いアプリケーションを移行するには、デフォルトのUOO名を物理宛先に設定してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリの順序単位パラメータの構成に関する項、および『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの順序付き再配信に関する項を参照してください。

一方向のメッセージ送信の使用

一方向メッセージ送信は、送信側によってボトルネックとされているアプリケーションのパフォーマンスを大幅に向上させることが可能ですが、それを行うとQOS(サービス品質)が低下するリスクが生じます。JMSプロデューサからの一般的なメッセージ送信は、内部リクエストおよび内部レスポンスの両方が含まれることから、双方向送信と呼ばれています。プロデューサ・アプリケーションがsend()を呼び出すと、この呼出しは、アプリケーションのメッセージが含まれる要求を生成し、そのメッセージの受信を確認するまでJMSサーバーからの応答を待機します。この呼出し/レスポンス・メカニズムでは、プロデューサが制御されます。これは、プロデューサ・アプリケーションは、別の送信呼出しを行うことができるようになるまで、JMSサーバーのレスポンスを待機するように強いられるためです。レスポンス・メッセージをなくすことによって、この待機時間もなくなり、一方向送信となります。WebLogic Serverでは、非永続、非トランザクションのメッセージ処理に対して構成可能な一方向送信オプションがサポートされています。この機能は、アプリケーション・コードを変更することなく利用できます。

一方向送信モードのオプションを有効にすると、ユーザー定義の接続ファクトリで作成したメッセージ・プロデューサで、一方向メッセージ送信ができるようになります(可能な場合)。一方向メッセージ送信が可能な場合、関連付けられたプロデューサは、ターゲット宛先のホストJMSサーバーからのレスポンスを内部で待機することなく、メッセージを送信できます。キュー・センダーおよびトピック・パブリッシャに一方向送信を許可したり、この機能をトピック・パブリッシャのみに制限したりできます。一方向ウィンドウ・サイズを指定して、追加の一方向送信を続行する前に、プロデューサを制御するために双方向メッセージが必要になる時期を決定する必要があります。

接続ファクトリでの一方向送信の構成

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリ・フロー制御の構成に関する項に記載されているように、WebLogic Server管理コンソールを使用して接続ファクトリに一方向のメッセージ送信パラメータを構成します。FlowControlParamsBean MBeanを通じて、WebLogic Scripting Tool (WLST)またはJMXを使用することもできます。

注意:
接続ファクトリが「XA対応」として構成されている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。

宛先が1つの場合のクラスタにおける一方向送信のサポート

宛先が1つの場合のクラスタで一方向送信をサポートするには、宛先をホストしているJMSサーバーと接続ファクトリが、同じWebLogicサーバーにターゲット指定されていることを確認します。接続ファクトリが、クラスタ内のその他のWebLogic Serverインスタンスにターゲット指定されている場合はサポートされません。

宛先が複数の場合のクラスタにおける一方向送信のサポート

同じ名前を共有する宛先が複数ある場合のクラスタで一方向送信をサポートするには、クライアント接続をホストしているWebLogic Serverインスタンスでもその宛先を確実にホストする必要があります。1つのソリューションを次に示します。

1. クラスタ全体のRMIロード・バランシング・アルゴリズムを「サーバー・アフィニティ」に構成します。

2. 2つの宛先が同じWebLogic Serverインスタンスでホストされていないことを確認します。

3. 各宛先が同じlocal-jndi-nameを持つように構成します。

4. 宛先をホストしているWebLogic Serverインスタンスにのみターゲット指定されている接続ファクトリを構成します。

5. JNDIコンテキストから接続ファクトリおよび宛先を取得するために、送信側クライアントにおいて、ステップ3および4で構成したJNDI名が使用されるようにします。

6. ステップ3の宛先をホストしているWebLogic Serverインスタンスにのみ制限されているURLを送信側クライアントが使用するようにします。

このソリューションでは、EJBホームおよびJMS接続ファクトリを含む、クラスタリングされたRMIオブジェクト用のRMIレベルのロード・バランシングは無効にされます。クライアントはJNDIコンテキストの確立に使用されるネットワーク・アドレスにのみ基づいて接続および宛先を効率的に取得します。ロード・バランシングは、WebLogic Serverアドレスのカンマ区切りのリストが含まれる複数のURL、または、ネットワーク管理者によって構成されるIPアドレスのround-robinセットに解決されるDNS名を指定する複数のURLに対して行われる、ネットワーク・ロード・バランシングを利用することによって達成されます。

クラスタ用サーバー・アフィニティの詳細は、『Oracle WebLogic Serverクラスタの管理』のEJBとRMIオブジェクトのロード・バランシングに関する項を参照してください。

一方向送信がサポートされないケース

この項では、一方向送信がサポートされないケースを示します。一方向送信がサポートされない場合、送信のQOSは、標準の双方向に自動的にアップグレードされます。

異なるクライアントと宛先ホスト

一方向送信は、ターゲット宛先をホストしているJMSサーバーとクライアント・プロデューサの接続ホストが、同じWebLogic Serverインスタンスである場合にサポートされます。そうでない場合、一方向モード設定は無視され、標準の双方向送信が代わりに使用されます。

クライアントのホスト接続ファクトリでのXA対応

クライアントのホスト接続ファクトリが「XA対応」として構成されている場合、一方向メッセージ送信は無効になります。この設定では、送信側が実際にトランザクションを使用しているかどうかに関係なく、一方向送信が無効になります。

高度なQOSの検出

次に示す、より高度なQOS機能が検出された場合には、一方向モードの設定は無視され、代わりに標準の双方向送信が使用されます。

- XA

- トランザクション・セッション

- 永続メッセージ

- 順序単位

- 作業単位

- 分散宛先

宛先割当ての超過

ターゲット宛先で指定された割当てを超過している場合、その割当てがクリアになるまで標準の双方向送信が使用されます。

割当てを超過する一方向メッセージは、例外がクライアントに即座に返されることなく、通知のないまま削除されます。クライアントは、次の双方向送信が行われる際、宛先が割当てをまだ超過している場合に、割当ての例外を取得することになります。(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)

割当て条件内で通知なしにメッセージが削除されるのを回避できる1つの方法は、接続ファクトリで構成される「Blocking Send Timeout」の値を増やすことです(「メッセージの圧縮」を参照)。一方向メッセージは、即座に削除されることはありませんが、メッセージが消費されるか、期限切れになることによって割当て条件がクリアになるまでの一定時間、JMSサーバーで待機することになります。クライアントの送信側は、双方向メッセージを送信するまでブロックすることはありません。各クライアントに対して、一方向ウィンドウ・サイズの数を超えるメッセージが割当て条件がクリアになるのを待機してサーバー上で蓄積されることはありません。

サーバー・セキュリティ・ポリシーにおける変更

サーバー側のセキュリティ・ポリシーで変更があると、JMSクライアントがその変更をセキュリティ・ステータスで通知されることなく、一方向メッセージ送信ができなくなる場合があります。

JMSサーバーまたは宛先ステータスにおける変更

JMSサーバーまたはターゲット宛先が管理者によってアンデプロイされているとき、または、生成休止/再開の機能を使用してJMSサーバーあるいはターゲット宛先上のメッセージの生成が休止されている場合、一方向の送信を無効化することができます。『Oracle WebLogic Server JMSリソースの管理』の生成の休止と再開に関する項を参照してください。

論理分散宛先名のルックアップ

一方向のメッセージ送信は、クライアントが論理的な分散宛先名を使用しないで、直接物理分散宛先メンバーを参照する場合、分散宛先で動作します。『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。

ハードウェア障害

ハードウェアまたはネットワークに障害があると、一方向送信は無効になります。こうした場合、JMSプロデューサは、OnExceptionまたは次の双方向メッセージ送信によって通知されます(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)さらに、プロデューサが閉じられます。最悪の場合、障害が発生した直前の最後の双方向メッセージまでのすべてのメッセージが失われる場合があります。

一方向送信のQOSのガイドライン

一般的な非永続メッセージングで一方向送信モードを使用する場合は、次のQOS関連のガイドラインを使用します。

- 送信のブロック機能とともに使用し、正常に実行されているシステム上で一方向送信を使用すると、双方向送信モードを使用する場合と同様のQOSを達成できます。

- トピック・パブリッシャの一方向送信モードは、JMS仕様で設定されているQOSガイドラインの範囲内に収まりますが、双方向モード(WebLogic Serverのデフォルト・モード)より低いQOSとなります。

- 『Oracle WebLogic Server JMSアプリケーションの開発』の非同期コンシューマに対する同期コンシューマに関する項に記載されているように、JMSコンシューマ・アプリケーションがシステムのボトルネックの場合、一方向送信モードでパフォーマンスが改善されない場合があります。

- 送信のバッチ・サイズ(ウィンドウ)の増加に対応するには、クライアントとサーバーの双方またはいずれかでJVMのヒープ・サイズを増やすことを検討します。可能メモリー使用量は、構成されたウィンドウのサイズおよび送信者の数に比例します。

- 送信側アプリケーションは、すべての割当て例外を受け取るわけではありません。割当てを超過する一方向メッセージは、例外が送信側クライアントに返されることなく、通知のないまま削除されます。詳細および考えられる回避策については、「宛先割当てを超過している」を参照してください。

- 接続ファクトリで一方向送信を構成すると、接続ファクトリで構成されているメッセージ・フロー制御パラメータが効率よく無効にされます。

- デフォルトでは一方向ウィンドウ・サイズは1に設定されています。これによって、各一方向メッセージが双方向送信にアップグレードされるため、一方向送信は事実上無効化されます。(一方向モードでも、クライアントは、クライアントの接続ファクトリで構成された「一方向送信ウィンドウ・サイズ」のメッセージ数ごとに双方向メッセージを送信します。)したがって、一方向送信のウィンドウ・サイズはもっと大きな値に設定する必要があります。ウィンドウ・サイズは最初に300に設定し、後からアプリケーションの要件に応じて調整するようにすることが推奨されます。

- クライアント・アプリケーションは、ネットワークまたはサーバーの障害に関する例外を即座に受け取るわけではなく、WebLogic Serverで障害が検出され、プロデューサが自動的に閉じられるまで、一部のメッセージは送信はされるものの、通知なしで削除される場合があります。詳細は、「ハードウェアに障害がある」を参照してください。

「メッセージング・パフォーマンスのプリファレンス」オプションのチューニング

注意:
これは、ファイン・チューニングの詳細オプションです。通常は、ます初めに他のチューニング・オプションを検討するのが最良です。

JMS宛先の「メッセージング・パフォーマンス・プリファレンスのオプション」というチューニング・オプションを使用すると、コンシューマに配信可能なメッセージの完全なバッチが作成されるまで宛先が待機する時間(必要がある場合)を制御できるようになります。最小値の場合、バッチ処理は無効になります。デフォルト値よりも大きな値にチューニングすると、使用できるメッセージをバッチ処理するまで宛先が待機する時間が延長されます。完全なバッチの最大メッセージ数は、JMS接続ファクトリの「セッションあたりの最大メッセージ数」設定で制御されます。

この高度なオプションはWebLogic Server管理コンソールから利用できます。スタンドアロンおよび共通分散宛先(DestinationBean APIでも可能)、またはJMSテンプレート(TemplateBean APIでも可能)の全般構成のページを使用して設定します。

具体的に言うと、JMS宛先には、メッセージをバッチにまとめてコンシューマへ配信することにより、自動的にパフォーマンスを最適化しようとする内部アルゴリズムがあります。メッセージ・レートや他の要因の変化に応じて、こうしたアルゴリズムでバッチのサイズや配信時間が変更されます。ただし、このようなアルゴリズムですべてのメッセージング環境のパフォーマンスを最適化することはできません。「メッセージング・パフォーマンス・プリファレンスのオプション」を指定することで、メッセージ・レートや他の要因の変更に応じたアルゴリズムの対応方法を変更して、システムのパフォーマンスを調整できます。

メッセージング・パフォーマンスの構成パラメータ

「メッセージング・パフォーマンス・プリファレンスのオプション」には、次の構成パラメータがあります。

表13-4 「メッセージング・パフォーマンスのオプション」の値

WebLogic Server管理コンソール値

MBeanの値

説明

メッセージをバッチ処理しない

0

メッセージのバッチ処理を事実上無効にします。利用可能なメッセージは即座にコンシューマへ配信されます。

これは、接続ファクトリの「セッションあたりの最大メッセージ数」フィールドを「1」に設定した場合に相当します。

待機せずメッセージをバッチ処理

25 (デフォルト)

完全に満たないバッチが、利用可能なメッセージを含んだ状態で即座に配信されます。

これは、接続ファクトリの「セッションあたりの最大メッセージ数」フィールドに設定した値に相当します。

メッセージ・バッチ処理の最小待機しきい値

50

短期間だけ待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。

メッセージ・バッチ処理の中間待機しきい値

75

場合に応じてより長く待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。

メッセージ・バッチ処理の最大待機しきい値

100

場合に応じてさらに長く待機した後で、完全に満たないバッチが利用可能なメッセージを含んだ状態で配信されます。

ご使用のシステムに最適な値を見つけるためには、ある程度の実験が必要な場合もあります。たとえば、並列する多数のメッセージ・コンシューマが設定されたキューの場合、WebLogic Server管理コンソールで「メッセージをバッチ処理しない」の値を選択(またはDestinationBean MBeanに「0」を指定)すると、そのキューではコンシューマが利用可能になるとすぐに、できるかぎり早くそのコンシューマにメッセージをスローしようとします。反対に、迅速なレスポンスが求められないメッセージ・コンシューマが1つだけ設定されているキューの場合、管理コンソールで「メッセージ・バッチ処理の最大待機しきい値」という値を選択(またはDestinationBean MBeanに「100」を指定)すると、そのキューではメッセージをバッチの形でのみコンシューマにスローしようとし、結果として待機時間は増加しますが、スロー回数が少なくなるのでサーバー全体のスループットが向上する場合があります。

スタンドアロンの宛先、共通分散宛先、またはJMSテンプレートに対して、WebLogic Server管理コンソールで「メッセージング・パフォーマンスのプリファレンス」パラメータを構成する手順については、管理コンソール・オンライン・ヘルプの次の項を参照してください。

- 「トピックに関する詳細なパラメータの構成」

- 「キューに関する詳細なパラメータの構成」

- 「共通分散トピック - 詳細パラメータの構成」

- 「共通分散キュー - 詳細パラメータの構成」

- 「JMSテンプレートに関する詳細なパラメータの構成」

これらのパラメータの詳細は、Oracle WebLogic Server MBeanリファレンスのDestinationBeanとTemplateBeanを参照してください。

非同期メッセージ・パイプラインとの互換性

「メッセージング・パフォーマンス・プリファレンスのオプション」は、非同期メッセージ・パイプラインを使用する非同期コンシューマに対応しています。また、同期コンシューマのプリフェッチ・モード機能(非同期メッセージ・パイプラインをシミュレートする機能)を使用する同期コンシューマにも対応します。ただし、「最大メッセージ数」に設定されている値が小さすぎると、宛先のより高いレベルのパフォーマンス・アルゴリズム(たとえば、「メッセージ・バッチ処理の最小待機しきい値」、「メッセージ・バッチ処理の中間待機しきい値」、「メッセージ・バッチ処理の最大待機しきい値」)の影響が無効になる場合があります。非同期メッセージ・パイプラインの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージの受信に関する項を参照してください。

クライアント側スレッド・プール

多くのjavaクライアント側のアプリケーションでは、クライアント・スレッド・プールのデフォルト・サイズとして、5個のスレッドで十分です。アプリケーションに大量の非同期コンシューマがある場合、非同期コンシューマに設定されている数よりも少し多いスレッド数を割り当てると役に立ちます。これにより、さらに多くの非同期コンシューマを同時に実行できます。

WebLogicクライアント・プールの構成方法は、WebLogic serverスレッド・プールの構成方法とは異なり、自動チューニングされていません。WebLogicクライアントでは、サーバーから受信されるリクエストのためにJMS MessageListenerの起動など、特定のスレッド・プールが使用されています。このプールは、次のコマンド行プロパティを使用して構成できます。

-Dweblogic.ThreadPoolSize=n

ここでは、nは、スレッド数を示します。

クライアント側のスレッド・ダンプを使用して、この設定が有効になっていることを確認できます。

JMS .NETクライアント・アプリケーションのベスト・プラクティス

次に、JMS .NETクライアント・アプリケーションの作成時に使用するパフォーマンス関連のベスト・プラクティスを簡単に示します。

- アイドル接続が失敗した場合にアプリケーションが対応する必要がある場合は、IConnectionを使用して接続例外リスナーを常に登録します。

- 複数の.NETクライアント・スレッドで1つのコンテキストを共有して、1つのソケットを使用するようにします。

- コンテキスト、接続、セッション、プロデューサ、宛先、接続ファクトリなど、頻繁にアクセスするJMSリソースはキャッシュして再利用します。これらのリソースを作成してクローズすると、CPUとネットワーク帯域幅がかなり消費されます。

- クラスタ内の複数のJMS .NETクライアント・ホスト・サーバーにわたってJMS .NETクライアントをロード・バランシングする場合は、DNS別名かカンマ区切りのアドレスを使用します。

JMS .NETクライアント・アプリケーションのベスト・プラクティスおよびその他のプログラミングに関する考慮事項については、『Microsoft .NET対応のWebLogic JMSクライアントの使用』のプログラミングの考慮事項に関する項を参照してください。

Oracle Data Guard環境の考慮事項

次の項では、Oracle Data Guardを含むWebLogic JMS環境の構成に関する考慮事項を示します。

- 計画停止時間の宛先の停止

- 予期しない停止に対するJMSサービスの移行

Oracle Data Guardの詳細は、http://www.oracle.com/us/products/database/options/active-data-guard/overview/index.htmlを参照してください。

計画停止時間の宛先の停止

メンテナンス時間が計画されている場合、本番データベース・インスタンスからスタンバイ・インスタンスへの切替えを開始する前に、影響を受けるJMS宛先を停止します。スタンバイ・データベースが本番に遷移したら、JMS宛先を再開します。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの実行時のJMSサーバー・メッセージ操作の停止に関する項を参照してください。

予期しない停止に対するJMSサービスの移行

サービスの停止が予期せず発生した場合、「失敗した場合に再起動する」オプションでJMSサービス移行を実装します。本番からスタンバイ・データベースへの切替えに必要な時間が、ストアのIORetryDelaySeconds属性の値を超えてJMSサービスが失敗する場合、そのJMSサービスと関連するストアはその場所(インプレース)で再起動されます。『Oracle WebLogic Serverクラスタの管理』の失敗した移行可能サービスのインプレース再起動に関する項を参照してください。

14 WebLogic JMSストア・アンド・フォワードのチューニング

この章では、ストア・アンド・フォワード(SAF)アプリケーションのパフォーマンスを最大にする方法について説明します。WebLogic Server 9.0以上のリリースのJMSでは、ローカル・サーバーのインスタンスからリモートJMS宛先への高パフォーマンス・メッセージ転送のためにストア・アンド・フォワードの高度な機能が用意されています。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。

この章には次の項が含まれます:

- JMS SAFのベスト・プラクティス

- JMS SAFのチューニングのヒント

JMS SAFのベスト・プラクティス

- リモートの宛先の可用性があらかじめ高い場合、SAFの使用は避けます。JMSクライアントからリモートの宛先に対して直接的に配信できます。SAFは、信頼性に欠けるネットワークや様々なメンテナンス・スケジュールがあるなど、リモートの宛先の可用性が高くない状況で使用します。

- リモートの宛先にメッセージを転送する場合、メッセージング・ブリッジではなく、パフォーマンスの優れたJMS SAF機能を使用します。一般に、JMS SAFエージェントはメッセージング・ブリッジに比べてかなり高速です。ただし、非永続的かつ「必ず1回」のモードでメッセージを送信する構成の場合は除きます。

注意:
外部宛先やWebLogic 9.0よりも前のリリースの宛先にメッセージを格納および転送(ストア・アンド・フォワード)するためには、現在もメッセージング・ブリッジが必要です。

- 管理とチューニングを簡略化するため、JMS SAFとWeb Services Reliable Messaging (WS-RM)エージェントには別個のSAFエージェントを構成します。

- 永続性が必要なサブシステムでは、サブシステム間で同じWebLogicストアを共有するとパフォーマンスが向上します。たとえば、SAFおよびJMS操作を含むトランザクション、複数のSAF宛先を含むトランザクション、SAFおよびEJBを含むトランザクションなどがこれに当たります。「WebLogic永続ストアのチューニング」を参照してください。

JMS SAFのチューニングのヒント

- 利用可能なSAFエージェント間でメッセージ送信をロード・バランシングするには、インポート済宛先を複数のSAFエージェントにターゲット指定します。

- SAF宛先ごとに個別のリモートSAFコンテキストを使用してパフォーマンスの改善を図ることを検討します。同じリモートSAFコンテキストを使用するSAF宛先は、通常、単一でスレッド化されます。

- 小さなメッセージを処理するアプリケーションでは、JMS SAFの「ウィンドウ・サイズ」を増加します。デフォルトでは、JMS SAFエージェントはメッセージを10個まで含められるバッチにまとめて転送します。メッセージのサイズが小さい場合、転送する各バッチ内のメッセージ数を増やすことでパフォーマンスが2 - 3倍になることがあります。小さなメッセージでは「ウィンドウ・サイズ」の初期値を100とするとより適切です。この値は、後で環境に合わせて最適化できます。
大きなサイズのメッセージを処理するアプリケーションで「ウィンドウ・サイズ」を変更しても、パフォーマンスが向上する可能性が低いので、お薦めしません。「ウィンドウ・サイズ」ではWS-RM SAFの動作もチューニングされるので、「両方」タイプのSAFエージェントでこのパラメータをチューニングするのは適切ではありません。

注意:
分散キューの場合、WindowSizeは無視され、バッチ・サイズは内部で1つのメッセージに設定されます。

- JMS SAFの「ウィンドウ間隔」を増やします。デフォルトでは、JMS SAFエージェントの「ウィンドウ間隔」の値は0で、メッセージは到着するとすぐに転送されます。この設定では、効果的な「ウィンドウ・サイズ」が構成された値よりかなり小さくなることがあるため、パフォーマンスが低下する場合があります。「ウィンドウ間隔」の初期値としてより適切な値は500ミリ秒です。この値は、後で環境に合わせて最適化できます。ここで言う小さなメッセージとは数Kよりも小さなものを指します。大きなメッセージとはおよそ10Kのものを指しています。
「ウィンドウ間隔」の変更では、フォワーダがすでにメッセージを到着と同じ速度で転送できている場合にのみパフォーマンスが向上します。この場合、フォワーダは新しく届いたメッセージをすぐに転送するのではなく、休止してより多くのメッセージを蓄積してからバッチとして転送します。結果としてバッチ・サイズが大きくなるため、転送スループットが向上して全体的なシステム・ディスクおよびCPUの使用率が低減されますが、待機時間は増大します。

注意:
分散キューの場合、「ウィンドウ間隔」は無視されます。

- アプリケーションが重複メッセージに対応できる場合、インポート済宛先の「非永続QOS」の値を「1回以上」に設定します。

15 WebLogicメッセージング・ブリッジのチューニング

この章では、メッセージング・ブリッジのパフォーマンスを向上させる様々な方法について説明します。

この章には次の項が含まれます:

- ベスト・プラクティス

- バッチ・サイズの変更

- バッチ間隔の変更

- サービス品質の変更

- 複数のブリッジ・インスタンスの使用

- スレッド・プール・サイズの変更

- 恒久サブスクリプションの無効化

- ソースまたはターゲット宛先とブリッジの同じ場所への配置

- 「非同期モードを有効化」属性の変更

- 多くのブリッジを使用する環境のチューニング

ベスト・プラクティス

- リモートの宛先の可用性があらかじめ高い場合、メッセージング・ブリッジの使用は避けます。JMSクライアントからリモートの宛先に対して直接的に配信できます。メッセージング・ブリッジは、信頼性に欠けるネットワークや様々なメンテナンス・スケジュールがあるなど、リモートの宛先の可用性が高くない状況で使用します。

- リモートの宛先にメッセージを転送する場合、メッセージング・ブリッジではなく、パフォーマンスの優れたJMS SAF機能を使用します。一般に、JMS SAFエージェントはメッセージング・ブリッジに比べてかなり高速です。ただし、非永続的かつ「必ず1回」のモードでメッセージを送信する構成の場合は除きます。

注意:
外部宛先やWebLogic 9.0よりも前のリリースの宛先にメッセージを格納および転送(ストア・アンド・フォワード)するためには、現在もメッセージング・ブリッジが必要です。

バッチ・サイズの変更

「非同期モードの有効化」属性をfalseに設定し、サービス品質が、「必ず1回」の場合、「バッチ・サイズ」を使用して、トランザクション(バッチ)当たりのメッセージ数を増やして、コミットされるトランザクション数を減らすできます。ブリッジ・インスタンスの最適なバッチ・サイズは、使用するJMSプロバイダ、ハードウェア、オペレーティング・システムおよびアプリケーション環境にあるその他の要因の組合せによって異なります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・プロパティの構成に関する項を参照してください。

バッチ間隔の変更

「非同期モードの有効化」属性をfalseに設定して、サービス品質が、「必ず1回」の場合、BatchInterval属性を使用して、ブリッジがバッチ・メッセージを転送する前にバッチの入力を待機するまでの時間を調整できます。ブリッジ・インスタンスに最適なバッチ間隔は、使用するJMSプロバイダ、ハードウェア、オペレーティング・システムおよびアプリケーション環境にあるその他の要因の組合せによって異なります。たとえば、キューがビジーでない場合、バッチがいっぱいになるまで待機するために、ブリッジが頻繁にメッセージの転送を停止します。この場合、BatchInterval属性の値を小さくする必要があります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのトランザクション・プロパティの構成に関する項を参照してください。

サービス品質の変更

サービス品質を「必ず1回」に設定すると、「最大1回」や「重複可」に設定した場合に比べ、パフォーマンスが大幅に向上したり低下したりすることがあります。

「必ず1回」のサービス品質を使用している場合、確実にトランザクション・セマンティクスを実現するため、ブリッジでは必ず両方のJMSサーバーで2フェーズ・コミットを行います。この操作には、非常にコストがかかることがあります。ただし、「必ず1回」を使用していると、他のサービス品質と違ってブリッジで複数の操作をバッチとしてまとめられます。

可能なかぎり最高のパフォーマンスを得るために、このパラメータを試みる必要があります。たとえば、キューがビジーでない場合または非永続メッセージを使用した場合、「必ず1回」の一括処理は、ほとんど利点がありません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。

複数のブリッジ・インスタンスの使用

メッセージの順序を指定する必要がない場合、複数のブリッジをデプロイすることを検討できます。

同じ宛先を使用してブリッジの複数のインスタンスをデプロイできます。デプロイ後は、ブリッジの各インスタンスが並列で実行されるので、スループットが向上される可能性があります。複数のブリッジ・インスタンスを使用すると、元の宛先と同じ順番でメッセージは転送されません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの作成に関する項を参照してください。

複数のブリッジを使用するかどうかを判断する際には、次の要素を検討します。

- 一部のJMS製品では、複数のブリッジを使用してもあまりメリットがないと想定されます。

- 通常、WebLogic JMSメッセージングのパフォーマンスはかなり向上します。永続メッセージの処理では特に改善が見られます。

- CPUやディスク・ストレージがフルに使用されている場合、ブリッジ・インスタンス数を増やすとスループットが低下することがあります。

スレッド・プール・サイズの変更

ブリッジを構成する際の一般的なルールでは、サーバー・インスタンスに割り当てられた各ブリッジ・インスタンスに1つのスレッドを用意します。ご使用の環境で適切な数のスレッドを利用できるようにするには、次のいずれかを行います。

- 共有スレッド・プールの使用: サーバーのインスタンスでは、スループットを最大化し、構成済のブリッジ・インスタンス数を補正するために、スレッド・プールのサイズが自動的に変更されます。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic Serverでのスレッド・プールの使用の理解に関する項を参照してください。

- weblogic.jms.MessagingBridgeクラスのワーク・マネージャを構成します。詳細は、『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャの理解に関する項を参照してください。

- WebLogic Server管理コンソールを使用して、サーバー・インスタンスの「構成: サービス」ページの「メッセージング・ブリッジの構成」セクションで、Thread Pool Sizeプロパティを設定します。サーバー内のデフォルトの実行スレッド・プールとの競合を避けるため、メッセージング・ブリッジ群では別個のスレッド・プールを共有します。このスレッド・プールは同期モードでのみ使用されます(「非同期モードの有効化」は設定されていません)。非同期モードでは、ブリッジはソース宛先のJMSプロバイダで作成されたスレッドで実行されます。WebLogic Server 9.0では非推奨になっています。

- ブリッジ・リソース・アダプタ・ツールが、ブリッジ数の2倍であることを確認します。『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』のリソース・アダプタに関する項を参照してください。

恒久サブスクリプションの無効化

ブリッジのトピックでのリスニング中に、ブリッジによってメッセージの転送が行われていないときに、メッセージを失っても構わない場合、「恒久性の有効化」フラグを無効にして、転送されていないメッセージがサーバーのストアに収集されないことを確認します。フラグを無効にすると、メッセージが非永続メッセージになります。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。

ソースまたはターゲット宛先とブリッジの同じ場所への配置

メッセージング・ブリッジのソースまたはターゲットがWebLogic宛先である場合、ブリッジをその宛先と同じWebLogic Serverにデプロイします。メッセージング・ブリッジをその宛先の1つに割り当てると、関連するネットワークおよびシリアライゼーションのオーバーヘッドが削減されます。このようなオーバーヘッドは高スループットのアプリケーションで、特にメッセージが非永続の場合に増大することがあります。

「非同期モードを有効化」属性の変更

「非同期モードの有効化」属性は、メッセージング・ブリッジがhttp://docs.oracle.com/javaee/5/api/javax/jms/MessageListener.htmlのJMS MessageListenerインタフェースを使用して非同期でメッセージを受信するかまたは同期のJMS APIを使用してメッセージを受信するかを決定します。ほとんどの場合、表 15-1に示すように、[非同期モードを有効化]属性の値はアプリケーション環境に必要なQOSによって決まります。

表15-1 QOSレベルと対応する「非同期モードを有効化」属性の値

QOS

「非同期モードを有効化」属性の値

必ず1回脚注 1

false

1回以上

true

最大1回

true

脚注 1 ソース宛先がWebLogic JMSプロバイダ以外で、QOSが「必ず1回」の場合、「非同期モードを有効化」属性は無効になり、メッセージは同期モードで処理されます。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのメッセージング・ブリッジ・インスタンスの構成に関する項を参照してください。

「必ず1回」のサービス品質が指定されていると、ブリッジのパフォーマンスに大きく影響します。ブリッジによりメッセージごとに新しいトランザクションが開始され、そのトランザクションに関与する両方のJMSサーバーに渡って2フェーズ・コミットが実施されます。2フェーズ・コミットは通常、ブリッジのトランザクションでもっともコストのかかる部分です。処理されるメッセージ数が増加するとブリッジのパフォーマンスは低下する傾向があります。

多くのブリッジを使用する環境のチューニング

この項では、多くのブリッジ・インスタンスをデプロイするシステムのシステム起動時間と全般的なパフォーマンスの改善方法について説明します。

- weblogic-ra.xml記述子ファイルのmax-capacity属性を調整して、各リソース・アダプタに関連付けられた接続ファクトリの容量を変更します。max-capacity属性の値は、少なくともブリッジ・インスタンス数の2倍にする必要があります。
たとえば、割り当てられているメッセージング・ブリッジ・インスタンスが10個までの環境においては、max-capacity属性は20に設定されているのは適切な設定です。ブリッジ・インスタンスを15個に増やす場合には、max-capacity属性の値を30まで増やします。『Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理』の接続ファクトリの数の設定に関する項を参照してください。

- サーバーのスレッド・プール・サイズ全体を、アクティブなブリッジの数よりも少し多くなるように増やします。これは、バッチ・サイズが1よりも大きなXA(トランザクション)ブリッジ、または非WebLogic JMSプロバイダでホストされるソース宛先から消費するXAブリッジに適用されます。
たとえば、メッセージ・ブリッジの数が90の場合、コマンド行で次の内容を指定します。

-Dweblogic.threadpool.MinPoolSize=100

これにより、影響を受けるブリッジを初期化する場合にスレッドが十分に確保されます。スレッドの数が十分ではない場合、新しいスレッドが作成されるまで、何秒もの遅延が生じる可能性があります。

- サーバー・インスタンスに割り当てられたブリッジ・インスタンスごとにスレッドを指定します。「スレッド・プール・サイズの変更」を参照してください。

16リソース・アダプタのチューニング

この章では、リソース・アダプタのチューニングのベスト・プラクティスについて説明します。

この章には次の項が含まれます:

- リソース・アダプタのクラスローディングの最適化

- 接続の最適化

- スレッド管理

- InteractionSpecインタフェース

リソース・アダプタのクラスローディングの最適化

リソース・アダプタ・クラスを1つまたは複数のJARファイルにパッケージ化してから、そのJARファイルをRARファイル内に配置することができます。これをネストされたJARと呼びます。JARファイルをRARファイル内にネストしていて、クラスがクラスローダーによってロードされる必要がある場合、RARファイル内のJARは、ロードする必要のある各クラスごとに、開いて閉じて繰返し処理されることになります。

RARファイル内のJARの数が少なく、JARのサイズが比較的小さい場合は、パフォーマンスに大きな影響は与えません。一方、多数のJARがあり、JARのサイズが大きい場合は、パフォーマンスへの影響が大きくなります。

そのようなパフォーマンスの問題を避けるには、以下のいずれかを行います。

1. リソース・アダプタを展開形式でデプロイします。この場合、JARのネストは不要になるため、クラスの検索に関わるパフォーマンスの影響は小さくなります。

2. リソース・アダプタを展開形式でデプロイできない場合は、RARファイルの内部でJARを展開できます。この場合もJARのネストは不要になるため、クラスローディングのパフォーマンスが大幅に向上します。

接続の最適化

リソース・アダプタで、J2CA 1.5仕様(http://java.sun.com/j2ee/connector/download.html)の7.14.1項および7.14.2で述べられているオプションの機能を実装することをお薦めします。これらの機能を実装すると、WebLogic Serverでは、通常は利用できない機能を提供できます。

怠惰な接続の関連付け(7.14.項1に記載)を利用すると、サーバーは未使用の接続を自動的にクリーン・アップして、アプリケーションによるリソースの占有を防ぐことができます。怠惰なトランザクション登録(7.14.2項に記載)を利用すると、アプリケーションは、接続がすでに開かれた後で、トランザクションを開始できます。

スレッド管理

リソース・アダプタの実装でWorkManagerを使用して(http://java.sun.com/j2ee/connector/download.htmlにあるJ2CA 1.5仕様の第10章「Work Management」に記載)、新しいスレッドで実行する必要がある処理を、新しいスレッドを直接作成しないで起動するようにしてください。WebLogic Serverはこれらのスレッドの管理やモニターを行えるようになります。

InteractionSpecインタフェース

J2CA 1.5仕様(http://java.sun.com/j2ee/connector/)の第15章「Common Client Interface」に従って、WebLogic ServerはEISのアクセスでCommon Client Interface (CCI)をサポートしています。CCIでは、アプリケーション・コンポーネント用の標準クライアントAPIを定義しています。アプリケーション・コンポーネントおよびEAIフレームワークは、CCIを使用することにより、異種EIS間の対話を制御できます。

ベスト・プラクティスとしては、CCIリソース・アダプタをRARファイル内に実装しなければならないInteractionSpecクラスは格納しないでください。代わりに、RARファイルの外部にある別のJARファイルにパッケージ化してください。そうすると、一般的なCLASSPATHにInteractionSpecインタフェース・クラスを入れないでも、クライアントがアクセスできるようになります。

InteractionSpecインタフェースについては、すべてのアプリケーション・コンポーネント(EJB、リソース・アダプタ、Webアプリケーション)がEARファイルにパッケージ化されている場合、すべての共通クラスをAPP-INF/libディレクトリに配置できることに留意してください。これが最も簡単なシナリオです。

このことは、スタンドアロンのリソース・アダプタ(RARファイルにパッケージ化)には当てはまりません。(InteractionSpecと同様に)インタフェースがシリアライズ可能である場合、クライアントとリソース・アダプタの両方が、実装クラスだけでなくInteractionSpecインタフェースにアクセスする必要があります。ただし、インタフェースがjava.io.Remoteを拡張している場合、クライアントはインタフェース・クラスにのみアクセスすればよくなります。

17 Webアプリケーションのチューニング

この章では、Webアプリケーションのチューニングとセッションの管理に関するベスト・プラクティスを示します。

この章には次の項が含まれます:

- ベスト・プラクティス

- セッション管理

- Pub-Subチューニング・ガイドライン

- GZIP圧縮の有効化

ベスト・プラクティス

- ページ・チェックの無効化

- カスタムJSPタグの使用

- JSPのプリコンパイル

- HTMLテンプレート圧縮の使用

- サービス・レベル・アグリーメントの使用

- 関連情報

ページ・チェックの無効化

サーブレットおよびJDPのページ・チェックを無効化すると、パフォーマンスを向上できます。次の各パラメータを -1に設定します。

- pageCheckSeconds

- servlet-reload-check-secs

- servlet Reload Check

これは本番モードではデフォルトの値です。

カスタムJSPタグの使用

Oracleでは、JSPページで使用できる特殊なJSPタグとして、cache、repeat、およびprocessの3つを提供しています。これらのタグは、weblogic-tags.jarというタグ・ライブラリjarファイルにパッケージされています。このjarファイルには、タグのクラスとタグ・ライブラリ記述子(TLD)が含まれています。これらのタグを使用するには、JSPを格納するWebアプリケーションにこのjarファイルをコピーして、タグ・ライブラリをJSPで参照します。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のカスタムWebLogic JSPタグ(cache、process、repeat)の使用方法に関する項を参照してください。

JSPのプリコンパイル

weblogic.xmlデプロイメント記述子のjsp-descriptor要素のprecompileパラメータをtrueに設定すると、Webアプリケーションをデプロイまたは再デプロイしたとき、あるいはWebLogic Serverを起動したときにJSPをプリコンパイルするように構成できます。サーバーを再起動するたびに、また追加でサーバーをターゲット指定したときに、JSPを再コンパイルしないようにするには、weblogic.appcを使用してJSPをプリコンパイルし、プリコンパイルしたJSPをWEB-INF/classesフォルダにコピーして、.warファイルにアーカイブします。ソース・ファイルをアーカイブ.warファイルとは別のディレクトリに格納すると、クラス・ファイルのいずれかとJSPとの依存関係によってエラーが発生する可能性がなくなります。JSPの再コンパイルを回避する方法の詳細は、http://www.oracle.com/technetwork/articles/entarch/jsp-reloaded-101726.htmlの不要なJSPコンパイルの回避に関する項を参照してください。

HTMLテンプレート圧縮の使用

compress-html-templateを使用すると、JSPテンプレート・ブロック内のHTMLが圧縮され実行時のパフォーマンスが向上します。JSPのHTMLテンプレート・ブロックに<pre> HTMLタグが含まれる場合は、この機能は有効にしないでください。

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の「jsp-descriptor」を参照してください。

サービス・レベル・アグリーメントの使用

ワーク・マネージャには、アプリケーションで必要とされるサーバー・レベル・アグリーメントに基づいてサーブレットやJSPを割り当てる必要があります。「スレッド管理」を参照してください。

関連情報

- 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットのベスト・プラクティス。

- http://www.javaworld.com/javaworld/jw-06-2004/jw-0628-performance_p.htmlにある『Servlet and JSP Performance Tuning』(Rahul Chaudhary著、JavaWorld、2004年6月号)

セッション管理

セッションの永続性およびセッションを処理する場合、一般にはアプリケーションの作業ができるだけ少なくなるようアプリケーションを最適化する必要があります。次の項では、環境やアプリケーションに適したセッション管理戦略の設計について説明します。

- セッションの永続性の管理

- セッションの最小化

- セッション・データの集約

セッションの永続性の管理

WebLogic Serverでは、Async-replicatedおよびAsync-JDBCモードを含めて、アプリケーションの異なる要件に応じる複数のセッション永続性メカニズムが用意されています。セッション永続性メカニズムは、後でWebアプリケーションに構成できます。アプリケーションのために使用するセッション管理戦略は、HTTPセッション・サイズ、セッション・ライフサイクル、信頼性およびセッション・フェイルオーバー要件など実環境要因によって異なります。たとえば、Webアプリケーションのライフサイクルとオブジェクト・サイズに基づき、フェイルオーバー要件のないWebアプリケーションは、単一メモリーベースのセッションとして維持され、セッション・フェイルオーバー要件を持つWebアプリケーションは、レプリケートされたセッションまたはJDBCベース・セッションとして維持されます。

純粋なパフォーマンスという観点では、セッションの状態に対するJDBCベース永続性と比較して、レプリケートされたセッション永続性を選択する方がよい選択です。ただし、レプリケート・ベース・セッションでは、WebLogicクラスタリングを使用する必要があるので、単一サーバー環境ではこのオプションを選択しません。

一方、JDBCベースの永続性を使用した環境では、WebLogicクラスタを使用する必要はなく、セッションの状態をより長い期間にわたってデータベースに保持できます。JDBCベースの永続性のパフォーマンスを向上させるには、コードを最適化してセッションの状態の永続性の粒度をできるだけ高くします。また、データベースの選択、データベース・サーバーの適切な構成、JDBCドライバ、JDBC接続プールの構成なども、JDBCベースの永続性のパフォーマンスに影響します。

セッション永続性の管理の詳細については次を参照してください。

- 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッション永続性の構成

- 『Oracle WebLogic Serverクラスタの管理』のHTTPセッションの状態のレプリケーションに関する項

- 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の永続記憶域(JDBC永続性)のデータベースの使用

セッションの最小化

アプリケーションをチューニングして最高のパフォーマンスを引き出すには、WebLogic Serverのセッション管理の方法を構成することが重要になります。次のことを考慮してください。

- セッションの使用にはスケーラビリティのトレードオフが伴います。

- セッションの使用を抑えます。つまり、ステートをクライアント上で現実的に保持できない場合か、またはURL書換えのサポートが必要な場合にのみ、セッションを使用します。たとえば、ユーザー名などの単純な状態を直接Cookieに保持します。また、ラッパー・クラスを記述して、これらのCookieの「取得」および「設定」を行うこともできます。これにより、同じプロジェクトに参加しているサーブレット開発者の作業が簡素化されます。

- 頻繁に使用する値をローカル変数に格納します。

詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のセッション管理の設定に関する項を参照してください。

セッション・データの集約

この項では、セッション・データの集約方法のベスト・プラクティスを紹介します。WebLogic Serverではセッションの変更を属性によって追跡およびレプリケートするので、以下のことを行う必要があります。

- 連携して変更するセッション・データは単一のセッション属性に集約します。

- 頻繁に変更するセッション・データと読取り専用のセッション・データは別のセッション属性に集約します。

たとえば1つの大きな属性を使用して、そこにすべてのセッション・データを含めている場合、そのデータの10 %だけを変更しても、属性全体をレプリケートする必要があります。この操作によって、不要なシリアライズ/デシリアライズやネットワークのオーバーヘッドが生じます。この場合、変更する10%のセッション・データを別の属性に移動する必要があります。

Pub-Subチューニング・ガイドライン

この項では、Pub-Subサーバーの一般的なチューニング・ガイドラインを示します。

- 特にアプリケーションが数千単位のクライアントを処理する場合は、ファイル記述子を増やして多数の接続が長時間維持されるようにします。

- WebLogic Serverのロギング・レベルのチューニング

- JVMオプションをチューニングします。推奨オプションは-Xms1536m -Xmx1536m -Xns512m -XXtlaSize:min=128k,preferred=256kです。

- 最大メッセージ・サイズを増やします。アプリケーションが大量のメッセージをパブリッシュする場合は、値を<max-message-size>10000000</max-message-size>に設定することを検討してください。

GZIP圧縮の有効化

WebLogic Server Webコンテナは、HTTP/1.1の一部であるHTTP Content-Encoding GZIP圧縮をサポートします。GZIP圧縮によって、Webブラウザがダウンロードする必要のあるデータのサイズを削減し、ネットワーク帯域幅を向上します。GZIP圧縮を有効化して構成することにより、Webアプリケーションをドメイン・レベルまたはWebアプリケーション・レベルでチューニングできます。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のWebアプリケーションのGZIP圧縮の有効化に関する項を参照してください。

18 Webサービスのチューニング

この章では、WebLogic Webサービス・アプリケーションとアプリケーション・リソースの設計、開発、およびデプロイにおけるベスト・プラクティスを紹介します。

この章には次の項が含まれます:

- Webサービスのベスト・プラクティス

- Web Service Reliable Messagingエージェントのチューニング

- Webサービスのパフォーマンス改善のための負荷の大きいシステムのチューニング

Webサービスのベスト・プラクティス

設計およびアーキテクチャにおける決定は、実行時のパフォーマンスやWebサービス・アプリケーションのスケーラビリティに大きく影響します。ここでは、最高のパフォーマンスを得るために重要な推奨事項を紹介します。

- Webサービス・アプリケーションは、推移的な性質を持ち適度なサイズのペイロードを伴うサービスについて設計します。

- Webサービス・アプリケーションに対して正しいサービス形式とエンコーディングを選択します。

- パフォーマンス向上のために、シリアライザのオーバーヘッドとネームスペース宣言を制御します。

- SOAPメッセージのフォーマットを最適化するため、MTOM/XOPまたはFast Infosetを使用します。

- パフォーマンスのオーバーヘッドを最小化するために、SOAP添付およびセキュリティを注意して設計します。

- 以下のようなアプリケーションでは、非同期のメッセージング・モデルの使用を検討します。

- トランスポートが低速で信頼性に欠けます。

- 複雑で実行時間の長い処理を扱います。

- トランザクション対応のサービス指向アーキテクチャ(SOA)の場合、パフォーマンスを向上させるにはロギング・ラスト・リソース(LLR)のトランザクションの最適化を使用することを検討します。「トランザクションのチューニング」を参照してください。

- ネットワークのオーバーヘッドを最小限に抑えることでパフォーマンスを向上させるには、レプリケーション、データのキャッシング、およびスキーマ定義を使用します。

- XML圧縮/圧縮解除のオーバーヘッドがネットワーク・オーバーヘッドより小さい場合のみ、XML圧縮手法を考慮します。

- パーサーなど、XML機能を頻繁に使用するアプリケーションでは、パフォーマンスの問題が発生するか、記述子が足りなくなる場合があります。これは、jaxp.propertiesファイル(JAXP API)でルックアップを行うことによって、XMLパーサー・インスタンスがブート・ストラップされるために発生する場合があります。実行時に不要なファイル操作が行われないように、およびパフォーマンスやリソースの使用率が向上するように、このプロパティをコマンド行で設定することをお薦めします。

- 『Oracle WebLogic Server JAX-WS Webサービスの開発』のJWSプログラミング・ベスト・プラクティスに関する項に従います。

- 基底のすべてのコンポーネントに関するベスト・プラクティスやチューニングにおける推奨事項に従います。「WebLogic Server EJBのチューニング」、「Webアプリケーションのチューニング」、「データ・ソースのチューニング」、「WebLogic JMSのチューニング」などを参照してください。

Web Service Reliable Messagingエージェントのチューニング

Webサービスの信頼性のあるメッセージングでは、ローカル・サーバーのインスタンスからリモート宛先への高パフォーマンス・メッセージ転送のためにストア・アンド・フォワードの高度な機能が用意されています。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。次の項では、ストア・アンド・フォワード(SAF)アプリケーションでベストなパフォーマンスを得る方法について説明します。

- 管理とチューニングを簡略化するため、JMS SAFとWeb Services Reliable Messagingエージェントには別個のSAFエージェントを構成します。

- 永続性が必要なサブシステムでは、サブシステム間で同じWebLogicストアを共有するとパフォーマンスが向上します。たとえば、SAFおよびJMS操作を含むトランザクション、複数のSAF宛先を含むトランザクション、SAFおよびEJBを含むトランザクションなどがこれに当たります。「WebLogic永続ストアのチューニング」を参照してください。

- リモートのSAFエージェントでは「ウィンドウ・サイズ」パラメータ値の増加を検討します。1Kより小さいメッセージでは、「ウィンドウ・サイズ」を300程度にチューニングするとスループットが向上します。

注意:
「ウィンドウ・サイズ」ではJMS SAFの動作もチューニングされるので、「両方」タイプのSAFエージェントでこのパラメータをチューニングするのは適切ではありません。

- 「再試行の遅延」の設定を小さくしすぎないようにします。小さすぎると、不要な配信試行が生じる場合があります。

Webサービスのパフォーマンス改善のための負荷の大きいシステムのチューニング

非同期のリクエストとレスポンス、信頼性のあるメッセージング、バッファリングなどの機能はすべて、最小のシステム・リソースを使用して少ないクライアント数(10未満)に対応するように、あらかじめチューニングされています。多数のクライアントや大量のメッセージを処理する予定である場合は、次の項に記載されているように、負荷の増大に対応できるようチューニング・パラメータを調整してください。

- ワーク・マネージャのスレッド・プールの最小サイズ制約の設定

- バッファリング・セッションの設定

- 非同期リソースの解放

ワーク・マネージャのスレッド・プールの最小サイズ制約の設定

ワーク・マネージャを定義して、最低でもサービスへの同時リクエストまたはレスポンスの想定数と同じ値にスレッド・プール最小サイズ制約(min-threads-constraint)を設定します。

たとえば、Webサービス・クライアントが高速で連続して20個のリクエストを発行する場合、このクライアントをホストするアプリケーションの推奨されるスレッド・プール最小サイズ制約値は20です。構成されている制約値が小さすぎる場合、受信された処理で空き処理スレッドを待機するため、パフォーマンスが大幅に低下します。

スレッド・プール最小サイズ制約の詳細は、『Oracle WebLogic Serverサーバー環境の管理』の制約に関する項を参照してください。

バッファリング・セッションの設定

信頼性のあるメッセージングやバッファリングの機能ではJMSキュー・セッションを使用してメッセージを信頼性/バッファ・キューに送信します。デフォルトでは、WebLogic Serverはバッファリングに10個のセッションを割り当てるので、10個のクライアントが同時に信頼性/バッファ・キューにメッセージを入れることができます。

非同期のリクエストとレスポンスの場合、通信のやり取りのリクエスト部分とレスポンス部分は別々に2つのクライアントとしてカウントされます。この場合、セッションのデフォルト・プールは非同期のリクエストとレスポンスのクライアントに同時に5つまで対応できます。アプリケーションで予期される同時クライアント数に対応するには、次のパラメータを予期されるクライアント・スレッド数の2倍に設定します。

-Dweblogic.wsee.buffer.QueueSessionPoolSize=size

非同期リソースの解放

非同期のリクエストとレスポンスの機能を使用する場合、WebLogic Serverは非同期レスポンスがクライアントに返されるまで、そのリクエストに関する情報を永続的に格納します。これらのリソースは、ストア・クリーナと呼ばれるバックグラウンドのスレッドによって解放されるまで、永続ストアに保持されます。

これらのリソースはより早く解放できる場合もあります。ストア・クリーナを頻繁に実行すれば、永続ストアのサイズを削減して、クリーニングに要する時間を最小限に抑えることができます。

デフォルトでは、ストア・クリーナは2分(120000 ms)ごとに実行されます。次のJavaシステム・プロパティを使用して、ストア・クリーナの間隔を1分(60000 ms)に設定することをお薦めします。

-Dweblogic.wsee.StateCleanInterval=60000

19 WebLogic Tuxedo Connectorのチューニング

この章では、WebLogic Tuxedo Connector (WTC)アプリケーションのパフォーマンスを最大にする方法について説明します。WebLogic Tuxedo Connector (WTC)では、WebLogic ServerアプリケーションとTuxedoサービスの相互運用性が実現されます。WTCを使用すると、サービス・リクエストに応じて、WebLogic ServerクライアントがTuxedoサービスを呼出し、TuxedoクライアントがWebLogic Server Enterprise Java Beans (EJBs)を呼出すことができます。『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のOracle WebLogic Tuxedo Connectorのプログラミングの概要に関する項を参照してください。

この章には次の項が含まれます:

- 構成のガイドライン

- ベスト・プラクティス

構成のガイドライン

WebLogic Tuxedo Connectorの構成を行う際には、次のガイドラインに従ってください。

- 構成には複数のWTCサービスを設定できます。

- 1つのサーバー・インスタンスにはWTCサービスを1つだけターゲット指定できます。

- WTCでは接続プール機能がサポートされません。WTCではリクエストは多重化されますが、単一の物理的接続を使用します。

- 構成の変更は次のように実装されます。

- セッション/接続の確立前に、セッション/接続構成(ローカルAP、リモートAP、パスワード、およびリソース)を変更。変更は受け入れられ、新しいセッションまたは接続に実装されます。

- 接続/セッションの確立後に、セッション/接続構成(ローカルAP、リモートAP、パスワードおよびリソース)を変更。変更は受け入れられますが、接続を切離して再接続しないかぎり既存の接続/セッションに実装されません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWTCサービスのサーバーへの割当てに関する項を参照してください。

- インポート済サービスやエクスポート済サービスの構成を変更した場合。変更は受け入れられ、次回のインバウンド・リクエストまたはアウトバウンド・リクエストに実装されます。この方法は、処理中のリクエストが不明な状態のままになるためお薦めしません。

- tBridgeの構成を変更。デプロイされたWTCサービスを変更すると常に例外が発生します。tBridgeの構成を変更する前には、必ずWTCサービスのターゲット指定を解除するようにします。ターゲット指定を解除して構成を変更したら、WTCサービスをターゲット指定して変更を実装します。

ベスト・プラクティス

次の項では、WTC使用時のベスト・プラクティスを紹介します。

- 接続ポリシーを構成するときに、ON_STARTUPおよびINCOMING_ONLYを使用します。ON_STARTUPおよびINCOMING_ONLYは、常に組合せられています。たとえば、WTCのリモート・アクセス・ポイントがON_STARTUPを使用して構成されている場合、Tuxedoドメイン構成のDM_TDOMAINのセクションは、リモート・アクセス・ポイントをINCOMING_ONLYとして構成する必要があります。この場合は、WTCは、常にセッション・イニシエータとして機能します。『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のアクセス・ポイント間の接続の構成に関する項を参照してください。

- ON_DEMANDの接続ポリシーを使用しないでください。望ましい接続ポリシーは、ON_STARTUPとINCOMING_ONLYです。これにより、ON_DEMANDのルーティング・セマンティクスによるサービス・リクエストの失敗の可能性が低減します。『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のアクセス・ポイント間の接続の構成に関する項を参照してください。

- アプリケーションを設計するときに、リンク・レベル・フェイルオーバー、サービス・レベル・フェイルオーバーおよびロード・バランシングなどのWTC機能の使用を考慮してください。『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のフェイルオーバーとフェイルバックの構成に関する項を参照してください。

- WebLogic Serverクラスタを使用した追加的なロード・バランシングおよびフェイルオーバーの使用を検討します。WTCをWebLogic Serverクラスタ内で使用する方法は以下のとおりです。

- WebLogic ServerクラスタのすべてのノードにWTCインスタンスを構成します。

- 各クラスタ・ノードの各WTCインスタンスで同じ構成にする必要があります。

『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のWebLogic Tuxedo Connectorのクラスタ化された環境での管理方法に関する項を参照してください。

- WTCからTuxedoへの接続にインターネットを使用する場合、次のセキュリティ設定を使用します。

- 「セキュリティ」の値をDM_PWに設定します。『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のリモート・アクセス・ポイントの認証に関する項を参照してください。

- Link-level暗号化を有効にして、min-encrypt-bitsパラメータを40に設定し、max-encrypt-bitsを128に設定します。『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のLink-Level暗号化に関する項を参照してください。

- エラー条件をアプリケーションで管理し解釈するメカニズムをアプリケーション・ロジックで提供する必要があります。

- 『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のアプリケーション・エラーの管理に関する項を参照してください。

- 『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のシステム・レベル・デバッグの設定に関する項を参照してください。

- TypedFML32バッファ内に埋め込まれたTypedFML32バッファを使用しないでください。『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のWebLogic Tuxedo ConnectorでのFMLの使用に関する項を参照してください。

- アプリケーションへの負荷が大きい場合、より多くのリモートTuxedoアクセス・ポイントを構成し、そのアクセス・ポイント間でWTCの作業負荷をロード・バランスしてください。『Oracle WebLogic Server WebLogic Tuxedo Connectorの管理』のフェイルオーバーとフェイルバックの構成に関する項を参照してください。

- トランザクション・アプリケーションを使用するときに、同じリモート・アクセス・ポイントから利用可能な同じトランザクションにリモート・サービスを含めるようにしてください。『Oracle WebLogic Server Oracle WebLogic Tuxedo Connectorアプリケーションの開発』のWebLogic Tuxedo Connector JATMIトランザクションに関する項を参照してください。

- ゲートウェイからサービスをディスパッチするときに利用可能なクライアント・スレッド数によって、同時に実行しているサービス数が制限される場合があります。利用可能なスレッド数を増やすWebLogic Tuxedo Connector属性は存在しません。サービスを呼出すときに適切なスレッド・モデルを使用します。『Oracle WebLogic Serverサーバー環境の管理』のスレッド管理に関する項およびワーク・マネージャを使用したスケジュールされた作業の最適化に関する項を参照してください。

- WebLogic Serverのリリース9.2以降には高度なルーティング・アルゴリズムがあり、トランザクションのパフォーマンスを向上させることができます。特に、2フェーズ・コミット(2PC)トランザクションに複数のTuxedoサービス・リクエストが関与する場合、パフォーマンスが向上します。アプリケーションがTuxedoドメインに対してサービスを一度だけリクエストする場合、次のWebLogic Serverコマンド行パラメータを設定してこの機能を無効にできます。

-Dweblogic.wtc.xaAffinity=false

- コンストラクタTypedFML32をバッファ内のオブジェクトの最大数を使用して呼び出します。最大数の予測が困難な場合でも、適切な数を指定するとパフォーマンスが向上します。フィールド数に1.33を乗算すると、およその最大数を算出できます。

注意:
このパフォーマンスに関するヒントはTypedFMLバッファ・タイプには当てはまりません。

例:

TypedFML32バッファ・タイプにフィールドが50ある場合、最大数は63になります。コンストラクタTypedFML32(63, 50)を呼び出す方がTypedFML32()を呼び出すよりもパフォーマンスが良くなります。

TypedFML32バッファ・タイプにフィールドが50あってそれぞれが最大10回まで繰り返せる場合、コンストラクタTypedFML32(625, 50)を呼び出す方がTypedFML32()を呼び出すよりもパフォーマンスが良くなります。

- WTCクライアントと相互運用するサーバーとして働くTuxedoアプリケーションを構成する場合、並列処理の実施を検討してください。これは、様々なTuxedoマシン上に様々なサーバーを入念に構成すると可能になる場合があります。

- Tuxedoアプリケーションにおけるデータベース・アクセスのデッドロックの可能性に注意します。デッドロックはTuxedoアプリケーションを注意深く構成することで回避できます。

- WTCのロード・バランシングまたはサービス・レベルのフェイルオーバーを使用している場合、WTCトランザクション・アフィニティを無効化しないことを推奨します。

- アウトバウンド・リクエストをロード・バランシングする場合、インポート済サービスを複数のエントリとともに異なるキーを使用して構成します。インポート済サービスでは、各レコードが固有であるかどうかを複合キーを使用して判断します。複合キーは「サービス名+ローカル・アクセス・ポイント+リモート・アクセス・ポイント・リストのプライマリ・ルート」で構成されています。
次の例に、service1に対するリクエストをTDomainSession(WDOM1,TUXDOM1)とTDomainSession(WDOM1,TUXDOM2)の間で適切にロード・バランシングするよう構成する方法を示します。

表19-1 ロード・バランシングの正しい構成の例

ResourceName

LocalAccessPoint

RemoteAccessPointList

RemoteName

service1

WDOM1

TUXDOM1

TOLOWER

service1

WDOM1

TUXDOM2

TOLOWER2

次の例は、ロード・バランシングのリクエストを不適切に構成した場合です。この構成では、service1に対して同じ複合キーが使用されます。

表19-2不適切に構成されたロード・バランシングの例

ResourceName

LocalAccessPoint

RemoteAccessPointList

RemoteName

service1

WDOM1

TUXDOM1

TOLOWER

service1

WDOM1

TUXDOM1

TOLOWER

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

この付録では、キャパシティ・プランニングの概要を示します。キャパシティ・プランニングは、アプリケーションのニーズを十分に満たすために必要なハードウェアおよびソフトウェアの構成を決定するプロセスです。キャパシティ・プランニングは精密科学ではありません。アプリケーションやユーザーの動作はそれぞれ異なります。

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

- キャパシティ・プランニングの要因

- アプリケーション・パフォーマンスの目標の評価

- ハードウェアのチューニング

- ネットワークのパフォーマンス

- 関連ドキュメント

キャパシティ・プランニングの要因

WebLogic Serverインスタンスと特定のアプリケーションをサポートするために、ハードウェア構成にどの程度のキャパシティが必要となるかは、様々な要因に左右されます。アプリケーションのサポートに必要なハードウェア・キャパシティは、アプリケーションと構成の詳細によって異なります。それぞれの要因が構成とアプリケーションにどう影響するのかを考える必要があります。

次の項では、いくつかの要因を取り上げて説明します。これらの要因について理解した上でアプリケーションの要件を検討すると、構成のサーバー・ハードウェア要件を作成しやすくなります。表A-1のキャパシティ・プランニングに関する質問を考慮してください。

表A-1 キャパシティ・プランニングの要因と情報の参照先

キャパシティ・プランニングに関する確認事項

詳細は、次を参照してください:

WebLogic Serverは十分にチューニングされていますか?

アプリケーション・パフォーマンスの目標の評価

ユーザー・アプリケーションは効率的に設計されていますか?

データベース・サーバーのキャパシティとユーザー・ストレージ要件

帯域幅は十分ありますか?

ネットワーク負荷

同時実行が必要なトランザクション数はどのくらいですか?

同時セッション

データベースは制約要因となっていますか?追加のユーザー・ストレージ要件はありますか?

データベース・サーバーのキャパシティとユーザー・ストレージ要件

WebLogic Serverのほかに何がマシンで実行されていますか?

ネットワーク負荷

クライアントはWebLogic Serverへの接続にSSLを使用していますか?

SSL接続とパフォーマンス

クライアントはどのような種類のトラフィックを生成しますか?

RMIとサーバーのトラフィック

WebLogic Serverアプリケーションにはどのような種類のクライアントが接続しますか?

プログラムに基づくクライアントとWebベースのクライアント

現在のデプロイメントはクラスタ用に構成されていますか?

クラスタリングされた構成

サーバーは移行用に構成されていますか?

サーバーの移行

プログラムに基づくクライアントとWebベースのクライアント

WebLogic Serverには、主に以下の2種類のクライアントが接続します。

- Webベースのクライアント(WebブラウザやHTTPプロキシなど)は、HTTPまたはHTTPS(セキュア)プロトコルを使用して、HTMLまたはサーブレットの出力を取得します。

- プログラム的なクライアント(Javaアプリケーションやアプレットなど)は、RMIを使用してT3プロトコル経由でサーバーに接続します。

HTTPはステートレスであるという性質を持つため、サーバーはプログラムに基づくクライアントの場合よりも多くのオーバーヘッドを処理する必要があります。しかし、ブラウザの利用性やファイアウォールとの互換性など、HTTPクライアントにはパフォーマンス・コストに見合う数多くの利点があります。

T3はクライアント側のプレゼンテーション作業の多くを処理するので、一般には、プログラムに基づくクライアントの方がHTTPクライアントよりも効率的です。通常、Webクライアントはサーブレットを経由しますが、プログラムに基づくクライアントはEJBを直接呼び出します。このため、サーバーがプレゼンテーションを処理する必要がなくなります。T3プロトコルはソケットを使用して機能するので、サーバーとの間で接続を長時間継続します。

プログラムに基づくクライアントだけを利用するようにインストールされたWebLogic Serverでは、複数のWebLogic Serverが利用するHTTPプロキシよりも多いクライアントを同時に処理できます。HTTP上でT3をトンネリングした場合、このパフォーマンスの向上は見られません。実際には、HTTP上のT3のパフォーマンスは一般的には通常のHTTPより15%低く、同様に、WebLogic Serverインストールの最適キャパシティも少なくなります。

RMIとサーバーのトラフィック

クライアントはどのようなサーバー・トラフィックを発生させるでしょうか。T3クライアントを使用する場合は、サーバーとのほとんどの対話にRemote Method Invocation (RMI)が関わります。RMIを使用するクライアントは、センダーとリスナーがそれぞれ1つなので、サーバーとの間に大量のトラフィックを発生させることはありません。

RMIは、HTTPトンネリングを使用してRMI呼出しがファイアウォールを通過するようにできます。通常、HTTPをトンネリングするRMIは、非トンネリングRMIのような高いパフォーマンスを提供しません。

SSL接続とパフォーマンス

Secure sockets layer (SSL)は、セキュアなインターネット通信を実現するための標準です。WebLogic Serverのセキュリティ・サービスは、X.509デジタル証明書とアクセス制御リスト(ACL)をサポートして、関係者の認証を行い、ネットワーク・サービスへのアクセスを管理します。たとえば、SSLは従業員の給与が記載されたJSPページを保護できます。これにより、機密情報へのアクセスがブロックされます。

SSLでは、大量の計算処理が必要となります。SSLプロトコルで暗号化処理を使用すると、その分だけWebLogic Serverが処理可能な同時接続数が減ります。

クライアント総数の中の必要なSSL接続数に注意してください。一般にサーバーは、1つのSSL接続を処理する能力で3つの非SSL接続を処理できます。したがって、SSLを使用すると、サーバーのキャパシティはSSL接続の暗号強度に応じて大幅に低下します。また、SSLによって課せられるオーバーヘッドの量は、SSL対応のクライアント対話の数に関連します。WebLogic Serverには、SSL処理用のネイティブ・パフォーマンス・パックが含まれています。

WebLogic Serverプロセスの負荷

WebLogic Serverのほかに何がマシンで実行されているかを調査してください。マシンは、プレゼンテーション・ロジックやビジネス・ロジックよりもはるかに多くの処理を行っている場合があります。たとえば、Webサーバーを実行していたり、株価情報サービスからの株価情報の提供など、リモート情報を提供し続けていたりする場合も考えられます。

WebLogic Serverに関係のない処理によってWebLogic Serverマシンの処理能力がどのくらい消費されるのかを考慮してください。WebLogic Server (またはWebLogic Serverが動作しているマシン)が別の重要な処理を実行している場合、その他のプロセスにどの程度の処理能力を割り当てるかを決める必要があります。Webサーバー・プロキシがWebLogic Serverと同じマシンで実行されている場合は、処理能力の25 - 50%程度を見込んでおきます。

データベース・サーバーのキャパシティとユーザー・ストレージ要件

データベースがボトルネックですか?追加のユーザー・ストレージ要件はありますか?データベース・サーバーはしばしば、WebLogic Serverよりもはるかに早くキャパシティの限界に達します。アプリケーションを処理するためには、十分堅牢なデータベースをプランニングしてください。通常、優れたアプリケーションのデータベースには、アプリケーション・サーバーのハードウェアよりも3 - 4倍強力なハードウェアが必要です。したがって、データベース・サーバー用に別のマシンを使用することをお薦めします。

一般に、WebLogic ServerのCPU使用率が85 - 95%の範囲に入らない場合、データベースがボトルネックになっていると考えられます。つまり、WebLogic Serverはほとんどの時間、アイドル状態でデータベースの応答を待っているということです。クラスタ内でロード・バランシングを行うと、ノード間のCPU使用率はほぼ均等になります。

一部のデータベース・ベンダーは、アプリケーション・サーバー用のキャパシティ・プランニング情報を提供し始めています。一般に、これはアプリケーション用の3層モデルに対するレスポンスです。

アプリケーションは、データベースと対話しない処理用にユーザー・ストレージを必要とする場合があります。たとえば、セキュリティ・システムでは、各ユーザーのセキュリティ情報を格納するためのディスクとメモリーが必要です。1人のユーザーの情報を格納するために必要なサイズを計算し、その数に予期される最大ユーザー数を掛けてください。

同時セッション

どのくらいの数のトランザクションを同時実行する必要があるのかを調査してください。WebLogic Serverが処理する必要がある同時セッションの最大数を調べます。効率を上げるには、セッションごとにRAMを増やす必要があります。Oracleでは、処理が最小限のキャパシティを上回ると予想されるWebLogic Serverごとに少なくとも256MBのメモリーを設置することを推奨しています。

次に、同時にリクエストを送るクライアントの最大数と、各クライアントがどのくらいの頻度でリクエストを行うかを調べます。WebLogic Serverとの1秒当たりのユーザー対話数は、特定のWebLogic Serverデプロイメントによって1秒間に処理する必要がある対話の総数を示します。一般に、Webデプロイメントの場合、ユーザー対話はJSPページまたはサーブレットにアクセスします。アプリケーション・デプロイメントにおけるユーザー対話は通常、EJBにアクセスします。

また、リクエスト数が急激に増えた場合に対応するために、指定した期間内のトランザクションの最大数に着目する必要があります。たとえば、株式レポート・アプリケーションの場合、株式市場のオープン後とクローズ前の取引の急増に対応したプランニングが必要です。ワールド・シリーズやワールド・カップ・サッカーの決勝戦の間の広告としてWebサイトをブロードキャストする場合、需要の急増が予想されます。

ネットワーク負荷

帯域幅が十分かどうかを調査してください。WebLogic Serverには、クライアントからのすべての接続を処理するだけの十分な帯域幅が必要です。プログラムに基づくクライアントの場合、クライアントJVMごとにサーバーへの1つのソケットがあります。各ソケットには帯域幅が必要です。プログラムに基づくクライアントを処理するWebLogic Serverでは、Webベース・クライアントのサーバーが処理する帯域幅の125 - 150%が必要です。Webサーバーを実行するために必要な帯域幅は、転送するコンテンツのサイズに応じて、56kbps (キロビット/秒)の帯域幅ごとに7 - 10のリクエストを同時に処理できると考えておけばよいでしょう。HTTPクライアントだけを処理する場合は、静的ページを提供するWebサーバーと同程度の帯域幅が必要です。

LANインフラストラクチャの要件に影響を及ぼすプライマリ要因は、サーブレットおよびステートフル・セッションEJBに対するレプリケートされたセッションの使用です。クラスタでは、レプリケートされたセッションがLAN帯域幅を最も消費します。アプリケーションでサーブレットおよびEJBのセッション情報のレプリケーションが必要かどうかを検討してください。

指定のデプロイメントの帯域幅が十分かどうかを調べるには、ネットワーク・オペレーティング・システム・ベンダーのネットワーク・ツールを利用します。Windows NT、Windows 2000、およびSolarisなど、多くの場合、ネットワーク・システム上の負荷の内容を検査することができます。負荷が非常に高い場合は、帯域幅がシステムのボトルネックになっている可能性があります。

クラスタリングされた構成

クラスタは、効率とフェイルオーバーを大幅に向上させます。クラスタリングしていても、ユーザーにわかるほどパフォーマンスが低下することはありません。本番環境のWebLogic Serverデプロイメントの多くは、WebLogic Serverインスタンスのクラスタを1つのマルチプロセッサ・サーバーに配置しています。

Enterprise JavaBeans (EJB)またはサーブレットのセッションのレプリケーションを実行する大規模なクラスタは、小規模なクラスタに比べてより広い帯域幅が必要です。セッション・データのサイズとクラスタのサイズを検討してください。

サーバーの移行

サーバーは移行用に構成されていますか?WebLogic Serverの移行とは、障害が発生した場合に、クラスタリングされたWebLogic Serverインスタンスまたはクラスタリングされたインスタンスで実行中のコンポーネントを別の場所に移動する処理です。サーバー全体を移行する場合は、サーバーのインスタンスは、障害が発生すると別の物理マシン上に手動または自動で移行されます。

本番環境でのキャパシティ・プランニングについては、移行中にサーバーを起動すると、CPUに負荷がかかることがあります。マシンで同時にある台数のサーバーを実行できるので、同じマシンで同時に同じ数のサーバーを起動できるわけではありません。

アプリケーションの設計

アプリケーションが効率的に設計されているかどうかを調査してください。WebLogic Serverは、ユーザー・アプリケーション用のプラットフォームです。ユーザー・アプリケーションの設計が不適切な場合、または設計が最適化されていない場合、特定の構成では、10 - 50%もパフォーマンスが大幅に低下することがあります。WebLogic Server向けに開発されたすべてのアプリケーションが最適化されているわけではなく、ベンチマーク・アプリケーションほどのパフォーマンスを発揮するわけではない、と考えるようにしてください。予想される最大キャパシティを増やしてください。「アプリケーションのチューニング」を参照してください。

アプリケーション・パフォーマンスの目標の評価

キャパシティ・プランニングのこの段階では、サーバー上で予測されるアクティビティのレベルに関する情報を収集します。予想されるユーザーの数、リクエストの数、許容できるレスポンス時間、および望ましいハードウェア構成などです。サーバー・ハードウェアのキャパシティ・プランニングでは、最大のパフォーマンス要件に焦点を絞り、キャパシティに関して測定可能な目標を設定します。

提供されているサンプル・アプリケーションのいずれかを使用して計算される数値は、ご使用のアプリケーションで確認できる数値の概算にすぎません。製品ハードウェアを使った実際の製品アプリケーションでのベンチマークに匹敵するものはありません。特に、実際のアプリケーションでは、提供されているテスト・アプリケーションでは捕捉されにくい競合やその他の問題が明らかになる場合があります。

ハードウェアのチューニング

パフォーマンスを調べる場合、所定のハードウェア構成でWebLogic Serverと所定のアプリケーションをサポートするためにどのくらいのキャパシティが必要となるかは、多くの要因が影響します。アプリケーションのサポートに必要なハードウェア・キャパシティは、アプリケーションと構成の詳細によって異なります。それぞれの要因を、どのように各アプリケーションおよび構成に適用するかを検討する必要があります。

パフォーマンスを評価するためのベンチマーク

Standard Performance Evaluation Corporation (http://www.spec.org)は、コンピュータ・システムのパフォーマンスを評価するための標準ベンチマークおよびメトリックを提供しています。

サポートされるプラットフォーム

WebLogic Serverの各リリースでサポートされているハードウェアおよびオペレーティング・システム・プラットフォームの最新の動作確認情報へのリンクは、『Oracle WebLogic Server 12.2.1の新機能』のサポートされている構成に関する項を参照してください。

ネットワークのパフォーマンス

ネットワークのパフォーマンスが低下するのは、リソースの供給が需要に追いつくことができない場合です。最近のエンタープライズ・レベルのネットワークは非常に高速で、適切に設計されたアプリケーションであれば、パフォーマンス低下の直接的な原因になることはまれです。しかし、1つまたは複数のネットワーク・コンポーネント(ハードウェアまたはソフトウェア)に問題が見つかった場合は、ネットワーク管理者と協力してその問題を洗い出し、解決する必要があります。WebLogic Server用に、適切な広さのネットワーク帯域幅、およびアーキテクチャ内の他の層への適切な数の接続(クライアント接続やデータベース接続など)が用意されているかどうかを検証する必要もあります。したがって、パフォーマンスの潜在的なボトルネックを解消するには、ネットワークのパフォーマンスを継続的にモニターすることが重要です。

ネットワーク帯域幅の決定

帯域幅は、一般には「データ通信の転送レートで、通常はビット毎秒で測定される、通信を送受信するためのリンクの容量」と定義されます。WebLogic Serverを実行するマシンには、そのすべてのWebLogic Serverクライアント接続を処理できるだけの十分な帯域幅が必要です。プログラムに基づくクライアントの場合、クライアントJVMごとにサーバーへの1つのソケットがあり、ソケットごとに専用の帯域幅が必要になります。WebLogic Serverインスタンスでプログラムに基づくクライアントを処理するには、同様なWebサーバーで処理する場合の125 - 150%の帯域幅が必要になります。HTTPクライアントのみを処理する場合は、静的ページを提供するWebサーバーと同程度の帯域幅が必要になると考えてください。

所定のデプロイメントに十分な帯域幅があるかどうかを調べるには、使用しているネットワーク・オペレーティング・システムのベンダーから提供されているネットワーク・モニター・ツールを使用して、ネットワーク・システム上の負荷を参照します。ネットワークの利用状況は、Solarisのnetstatコマンド、Windowsのシステム・モニター(perfmon)など、一般的なオペレーティング・システム・ツールを使用してモニターすることもできます。負荷が非常に高い場合は、帯域幅がシステムのボトルネックになっている可能性があります。

また、アプリケーションとアプリケーション・サーバーの間およびアプリケーション・サーバーとデータベース・サーバーの間で転送されているデータをチェックして、ネットワーク上で転送されるデータの量をモニターします。このデータ量は、ネットワークの帯域幅を超えてはいけません。超えると、ネットワークがボトルネックになる可能性があります。これを確認するには、次のコマンドを使用して、パケットの再転送や重複に関するネットワーク統計値をモニターします。

netstat -s -P tcp

関連ドキュメント

Oracle Technology Networkでは、WebLogic Serverの詳細なドキュメントを提供しています。http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.htmlを参照してください。

サード・パーティの膨大なソフトウェアからも、キャパシティ・プランニング関連のトピックに関する情報を入手できます。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利について

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

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

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

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

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

第三者のコンテンツ、製品、サービスに対する免責事項

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

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

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

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

Oracle Supportへのアクセス

サポートをご契約のお客様には、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を参照してください。