2. チューニング

2.1. APサーバ

2.1.1. チューニングのための事前確認

チューニングの方針を立てるためには現在使用中または使用予定のWebOTXのメモリ使用量や性能を正しく把握する必要があります。WebOTXやOSが提供する情報採取方法について説明します。

2.1.1.1. メモリ使用量の確認

WebOTXが必要とするメモリ使用量はマニュアルの [ セットアップガイド > 1. 使用上の条件 > 1.1. 必要リソース ] を参照してください。 WebOTXのエージェントプロセスが使用するJVMヒープサイズの確認については [ドメイン構築・基本設定ガイド > 3. ドメイン > 3.11. Javaプロセスの監視・管理] を、JVMヒープサイズのモニタリングに関しては [ドメイン構築・基本設定ガイド > 9. モニタリング] を参照してください。 アプリケーションプロセスのメモリ使用量の確認については[ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.8. 統計情報(統合運用管理ツールでの表示) ] を参照してください。その他のプロセスについてはタスクマネージャ(Windowsの場合)またはtopコマンド(unixの場合)で確認してください。また、OS全体でのメモリ残量はタスクマネージャ(Windowsの場合)またはswapinfoコマンド(unixの場合)で確認できます。
なお、Oracle製JDKをご使用の場合はjconsoleを、HP-UXの場合はHPJmeterなどでヒープ使用量を確認することもできます。

2.1.1.2. アプリケーション処理時間の確認

実行時間の上限の設定を適切に行うために、運用アシスタントの実行時間の上限の適正値算出機能を利用してください。 詳細は [製品構成と提供機能 >3. 提供機能 > 3.4. TPモニタ > 3.4.4.TPモニタの障害に対する機能 > 3.4.4.5. 運用アシスタント ] の実行時間の上限の適正値算出を参照してください。

また、プロセス数やスレッド数を適切に設定するためにはキュー滞留数がひとつの目安になります。統合運用管理ツールでのキュー滞留数の確認方法については [3. モニタリング > 3.1. モニタリング情報の採取 > 3.1.3. モニタリングの利用例 > 3.1.3.3. キューイング数のモニタリング] を参照してください。さらにquewrtコマンドで確認することもできます。 [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.12. キュー滞留情報 ] を参照してください。

2.1.1.3. 多重度の確認

クライアント多重度、スレッド多重度がどこまで使われているのかを確認する方法を説明します。

2.1.2. リソースチューニング

WebOTXで消費するメモリについてチューニングする方法について説明します。またディスクサイズを節約する方法について説明します。

2.1.2.1. ドメインエージェントプロセスのヒープサイズの見直し

ドメインエージェントプロセスのヒープサイズを見直すことにより、ドメインエージェントプロセスの使用メモリをチューニングできます。なおチューニングする値については [3. モニタリング > 3.1. モニタリング情報の採取] や [ドメイン構築・基本設定ガイド > 3. ドメイン > 3.11. Javaプロセスの監視・管理 > 3.11.3. 統計レポート出力]、 [ドメイン構築・基本設定ガイド > 3. ドメイン > 3.11. Javaプロセスの監視・管理 > 3.11.4. GCログ出力] などから、 高負荷時にも耐えられるサイズを見積もる必要があります。少なくしすぎるとOutOfMemoryErrorが発生します。

設定方法

統合運用管理ツールのドメイン毎に設定

なお、GC採取時以下のログが出力されていた場合、Javaの通常のヒープとは別のPermanent領域というヒープ領域が足りなくなったことを示しています。

Permanent generation is full...
increase MaxPermSize (current capacity is set to: 67108864 bytes)

ここにはクラスの内部表現が展開されます。アプリケーションによっては非常に多くのクラスをロードするものもあり、Permanent 領域が足りなくなることがあります。このような場合には、Permanent 領域のサイズを変更する必要があります。現在は、デフォルトで128Mバイトに設定されています。

いずれも、編集後ドメインを再起動することで設定が反映されます。

なお、それ以外にも、JVMのヒープサイズに関して次のような指定が可能です。
いずれも、編集後ドメインを再起動することで設定が反映されます。

なお、これらの設定値が大きすぎると、次のようなエラーが発生してドメインが起動しなくなる場合がありますので注意して下さい。 また、実際にこれらのエラーが発生した場合には、OS側でそれ以上のサイズを確保できない状況であることを示していますので、指定した値よりも小さな値を設定するようにしてください。

Error occurred during initialization of VM
Could not reserve enough space for object heap

また、下図にも示すようなこれら以外のJVMオプションによってチューニングを行う場合には、[アプリケーションサーバ]-[JVM構成]-[JVMオプション]に設定値を追加します。
運用管理コマンドの場合は、オプションの形式に応じて次のように指定します。

"-X"で始まるオプション:

otxadmin> create-jvm-options -- -X<JVMオプション名><オプション値>

"-XX"で始まるオプション:

otxadmin> create-jvm-options "-XX\:<JVMオプション名>=<オプション値>"

GC
図2.1.2.1-1

2.1.2.2. サーバプロセスのヒープサイズ・スタックサイズの見直し

プロセスグループのプロセスのヒープサイズを見直すことにより、使用メモリをチューニングできます。また、ヒープサイズのチューニングほどの効果はありませんが、スレッドスタックサイズを変更することにより、若干使用メモリを減らせる可能性があります。 チューニングのためにはGCログを採取するなどして実際のメモリ使用量を測定する必要があります。設定値を小さくしすぎると、OutOfMemoryErrorが発生するので注意してください。

設定方法

統合運用管理ツールのプロセスグループ毎に設定

  1. [JavaVMオプション]-[最大ヒープサイズ]及び[初期ヒープサイズ] (Javaのみ)
  2. [スレッド制御]-[スレッドのスタックサイズ]

スレッドスタックサイズは、[スレッド制御]-[スレッド数]の設定で作成したスレッドに対して確保されます。 既定値は1MBなので、スレッド数が3の場合、使用メモリは3MBのみとなります。 よってスレッド数の設定が大きくない場合のチューニング効果はほぼありません。

一方、ヒープサイズをプロセスグループ毎に数100MBの設定を行っている場合、 適切なメモリ使用量を見積もってチューニングを行うことにより、 大幅にメモリ使用量を削減できる可能性があります。 メモリ不足に対するチューニングを行う場合、ヒープサイズの設定は重要なチューニングポイントになります。

2.1.2.3. 起動サービスの見直し

ドメイン作成時の既定値では、既定の状態に従い、サービスの起動設定が行われます。

この際、運用上必要のないサービスを起動させない設定にすることによりメモリを削減することができます。サービスを停止する場合、下記の表に記載されている停止条件を確認し、停止条件に全て合致しているか確認を行った後、設定を変更してください。

設定方法

  統合運用管理ツールのドメイン毎に設定

表2.1.2.3-1
ライフサイクル名
(英語名)
既定状態 停止への変更 停止条件 備考
データベースコントローラ
(DBControllerService)
起動 データベースコントローラを使用してデータベースの起動を行わない場合
テスト用サーバをインストールした場合、自動的にJavaDB(Derby)の自動起動設定を行います。
JavaEEUtilityLifecycle
(JavaEEUtilityLifecycle)
起動 不可    
JMSプロバイダ
(JmsProvider)
起動 業務アプリケーションでJMSを使用していな場合  
Object Brokerサービス
(ObjectBrokerService)
起動 Webコンテナサービスを使用しない場合
EJBを使用しない場合
JNDIサービスを使用しない場合
 
TPモニタマネージャサービス
(TPMonitorManagerService)
Editionにより異なる 不可   Expressインストール時には停止状態となっており、使用することができません。
Transactionサービス
(TransactionService)
起動 不可    
Webコンテナサービス
(WebContainerService)
起動 Webアプリケーションを使用していない場合
Web版統合運用管理コンソールを使用しない場合

このサービスを停止する場合、以下のコマンドを実行してWeb版統合運用管理コンソールを無効化する必要があります。

otxadmin> set system-applications.application.manager.enabled=false
Webサーバサービス
(WebServerService)
インストール時の選択によって異なる WebOTX Webサーバを使用していない場合
インストール時にアドバンスドモードを選択している場合
(別マシンのWebサーバを利用しない限り、必要となります。)
 

2.1.2.4. プロセス数・スレッド数の見直し

サーバAPプロセスのプロセス数およびスレッド数を減らすことによりシステム全体のメモリを削減することが出来ます。 それ以上にメモリの節約を必要とする場合はコンポーネントの集約を行うことによりメモリを削減できます。ただし、障害の局所化か難しくなるなどのデメリットもあるので注意が必要です。

設定方法

・ 統合運用管理ツールのプロセスグループの[プロセス制御]-[プロセス数]

・ 統合運用管理ツールのプロセスグループの[スレッド制御]-[スレッド数]

2.1.2.5. ディスクサイズの節約

ディスクサイズを節約するためにはアプリケーションログのファイルサイズを制限したり、プロセス終了により退避されたアプリケーションログを削除することが有効です。 例えば削除可能なアプリケーションログについては [ドメイン構築・基本設定ガイド > 8. ログ > 8.3. その他 > 8.3.3. Standard/Enterprise上のアプリケーションのログ出力 > 8.3.3.1. サーバアプリケーショントレース採取] に記述しているsaveディレクトリがあります。 但し、ログの削除は障害発生時のプロセスの異常終了の原因究明に支障が出る可能性があるため注意が必要です。

最終更新日から30日(既定値)経ったsaveディレクトリ配下のファイルは、WebOTXシステムの起動後12時間間隔(運用アシスタント機能を使用している場合)、およびWebOTXシステムの停止時に自動的に削除されます。

設定方法

・ 統合運用管理ツールのTPシステムの[システムパラメータ]-[トレースファイルの保存期間]

・ 統合運用管理ツールのプロセスグループの[トレース設定]-[システムトレースファイルの最大サイズ]

2.1.2.6. エージェントプロセスのメモリ節約STDENT

Standard/Enterpriseで動作するTP モニタは、オペレーション毎にトランザクション等の実行時情報を管理する機能を備えています。あるモジュールが配備されると、TP モニタでは個々のオペレーションを識別するために番号を付与して、内部管理テーブルと状態情報との関連付けを行います。EJB モジュールの場合には、オペレーションがリモートインタフェースのメソッドに該当します。

メソッド識別情報の割り当て範囲を限定することにより、配備処理中に行われる識別情報の生成数を削減し、エージェントプロセスでのメモリ消費量の削減が可能です。

詳しくは、 [運用ツールガイド > 2. 統合運用管理ツール(WebOTX Administrator) > 2.4. アプリケーションの配備]、 [ ドメイン構築・基本設定ガイド > 5. アプリケーション > 5.8. 配備チューニング > 5.8.1. EJBのメソッド識別情報の割り当て抑止(Standard/Enterprise) ] を参照してください。

また、EJBのメソッド識別情報の割り当てを抑止する以外にもオペレーションの統計情報を採取しないようにすることでエージェントプロセスでのメモリ消費量を節約できます。 ただし、この場合、運用アシスタントの機能を停止する必要があります。

設定方法

・ 統合運用管理ツールのTPシステムの[オペレーション制御]-[オペレーションの統計情報を採取しない]

・ 統合運用管理ツールのTPシステムの[運用アシスタント]-[運用アシスタント機能を使用する]

2.1.3. 性能チューニング

サーバAPの性能チューニングについて説明します。

2.1.3.1. 多重度のチューニング

プロセスグループの適正な多重度を算出するための方法について説明します。

理論的に算出

待ち行列理論を用いた計算により理論値を算出する方法について説明します。まずは以下の値について要件を整理します。

これらを待ち行列理論で計算して必要な多重度Nを求めます。
N=RTs/(Ta(R-Ts))
例えば
Ta=0.1 (10件/秒)
Ts=0.2
R=0.5
とすると
N=0.5*0.2/(0.1*(0.5-0.2))=3.33...
となり要求を満たすには4多重必要ということになります。

プロトタイプを用いた算出

本番運用を想定したプロトタイプを動作させ多重度を求める方法について説明します。プロトタイプを用いた測定のほうがより実運用に即した値を求めることが出来ます。

単体評価で算出

平均サービス時間:Tsを1多重で1つのクライアントからアクセスして時間を求めます。その他の値は既存システムもしくはユーザ要件から算出した値を用いて多重度を求めることが出来ます。

負荷評価で確認

実際に平均到着間隔:Taだけの負荷をかけて多重度を変えながらレスポンス時間を確認します。

運用アシスタントの利用

運用アシスタントにより多重度の適正を診断することができます。多重度が多すぎる/少なすぎる場合は統合運用管理ツールなどを通して通知されます。
また運用アシスタントの多重度自動変更機能を利用することにより、システムの稼働状況に合わせて多重度を自動的に変更させることができます。 詳しくは [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.13. 運用アシスタント > 7.1.13.2. 多重度の最適化支援 ] を参照してください。

2.1.3.2. CPU使用率の確認

応答時間が長い場合はその時のCPU使用率を確認してください。応答時間が長い場合はその時のCPU使用率を確認してください。 プロセスグループの「動作情報」タブの「プロセス情報」で確認できます。CPU情報はオペレーションジャーナルに記録され、統計的に解析することが可能です。
CPU使用率が高い場合はプロセス数やスレッド数を増やしても性能がよくなるとは限らないため、CPU使用率を減らすなどの対策が必要です。

2.1.3.3. 重要な処理を優先的に実行したい場合の設定

多重度を増やす等の対処をおこなっても、他のプロセスが動作中でCPU時間がなかなか割り当てられない場合などはレスポンス時間が大きくなってしまいます。 プロセスの優先度を指定することにより、高優先度の処理は他のプロセスより優先されるため、CPU負荷が高い状況でも処理投入後即開始することが可能となります。

例えば、以下のように業務特性に合わせた最適な優先度設定が可能です。(※)

表2.1.3.3-1

処理

優先度

緊急オンライン処理

通常オンライン処理

通常(未設定)

バッチ処理


図2.1.3.3-1

さらに、呼び出し処理単位の優先度設定(オペレーション優先度)と組合せて、よりきめ細かな設定が可能です。

プロセス優先度の設定はプロセスグループ単位で行います。 また、オペレーション優先度の設定はオペレーション単位で行います。

(※)優先度を維持するためには優先度を固定化する必要があります。またLinux OSでは優先度を固定することが出来ません。優先度を高く設定しても、実行を続けると優先度が落ちる場合があります。

2.1.3.4. 性能ネック箇所の特定

性能測定を行なった結果、性能が想定していたより出ない場合、どの部分に問題があるのか特定する方法について説明します。

レスポンス時間の把握

実際にどれくらいの実行時間で運用しているかを確認する方法について説明します。レスポンス時間の把握により問題のあるオペレーションを特定することが出来ます。
オペレーションの性能情報は[統計情報]-[ドメイン名]-[アプリケーション]-[アプリケーション名]-[モジュール名]-[インタフェース名]-[オペレーション名]を参照して下さい。
また、レスポンス時間(キュー待ち時間を含む応答時間)の他に、実行時間(キュー待ち時間を含まない処理時間)とCPU時間を確認することで性能ネック箇所を切り分けることができます。性能ネック箇所として疑わしいのは以下の箇所となります。
 レスポンス時間 >> 実行時間 であれば多重度不足
 実行時間 >> CPU時間 であればDBやネットワークなどのバックエンド問題
 実行時間 ≒ CPU時間 であれば業務AP内でのループ

キュー滞留数の把握

キュー滞留が発生しているかを確認する方法について説明します。キュー滞留が発生している場合、多重度が不足しておりレスポンス悪化になっている可能性が考えられます。

キュー滞留数の確認方法については [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.12. キュー滞留情報 ] を参照ください。

オペレーションジャーナルの活用

オペレーション単位でオペレーションの処理状況(平均時間、最大時間、最小時間、呼び出し回数、平均CPU使用時間(ユーザモード/カーネルモード)、最大CPU使用時間(ユーザモード/カーネルモード)、最小CPU使用時間(ユーザモード/カーネルモード))を確認することができます。これにより問題のあるオペレーションを特定することが出来ます。

オペレーションジャーナルの確認方法については [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.10. 統計情報(オペレーションジャーナル) ] を参照ください。

イベントジャーナルの活用

イベントジャーナルを採取してオペレーションの処理の流れを詳細に調べることができます。

イベントジャーナルについては [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.11. 通信情報(イベントジャーナル) ] を参照ください。

プロファイリング(Java APのみ)

Javaアプリケーションの場合プロファイリングを行なうことにより、より詳細に問題箇所を特定することが出来ます。

2.1.3.5. RMI-IIOPの通信で利用するクラスのキャッシュ

EJBアプリケーションやJNDIサーバとの通信で利用するクラスをキャッシュするように設定を変更することで、性能を向上させることができる場合があります。 Webアプリケーションのセッションレプリケーションでは、実装上、JNDIサーバとの通信が行われます。

設定方法
統合運用管理ツールで設定する場合:

次のMOの「Javaプロパティ設定」操作で、PoolClassesプロパティの値にtrueを設定してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[Object Brokerコンフィグ]

運用管理コマンドで設定する場合:

otxadmin> set-ospi-java-property PoolClasses true

クラスのキャッシュ機能を利用できる条件の詳細は、 [注意制限事項 > 12. Object Broker JavaTM/C++ > 12.1. 注意事項(Java) ] を参照してください。

2.1.4. その他チューニングに関する設定

高負荷になりレスポンスが悪化した場合などに考慮が必要なタイムアウト値や、プロセス起動・停止に必要なタイムアウト値などに関する設定、その他上限設定について説明します。


図2.1.4-1


図2.1.4-2

2.1.4.1. 起動・停止タイムアウト(メッセージ表示)

プロセスの起動操作、停止操作の完了を待ち合わせる時間を設定します。 タイムアウトした場合はエラーメッセージが表示されます。但し、プロセスの起動処理自体は実行され続けます。

表2.1.4.1-1

設定項目

説明

既定値

設定値範囲

補足事項

1.システム起動タイムアウト

システムの起動処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

2.システム停止タイムアウト

システムの停止処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

3.アプリケーショングループ起動タイムアウト

アプリケーショングループの起動処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

4.アプリケーショングループ停止タイムアウト

アプリケーショングループの停止処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

5.プロセスグループ起動タイムアウト

プロセスグループの起動処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

6.プロセスグループ停止タイムアウト

プロセスグループの停止処理に関するタイムアウトの設定をします。

120秒

1以上の整数で秒単位

内部プロセスの電文応答待ち時間である70秒よりも長い値を指定してください

設定方法

1. システム起動タイムアウト
otxadmin> set tpsystem.startTimeOut=120
2. システム停止タイムアウト
otxadmin> set tpsystem.stopTimeOut=120
3. アプリケーショングループ起動タイムアウト
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.startTimeOut=120
4. アプリケーショングループ停止タイムアウト
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.stopTimeOut=120
5. プロセスグループ起動タイムアウト
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.startTimeOut=120
6. プロセスグループ停止タイムアウト
otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>processGroups.<プロセスグループ名>.stopTimeOut=120

2.1.4.2. 起動・停止タイムアウト(プロセス終了)

アプリケーションプロセスの起動または停止に長い時間がかかる場合はタイムアウトを検出して異常終了することがあります。この場合、処理時間が妥当か検証し、妥当でないなら処理を見直し、妥当ならタイマ値を見直す必要があります。

表2.1.4.2-1

設定項目

説明

既定値

設定値範囲

1. スレッド初期化時間

スレッド初期化にかかる時間のタイムアウト値を設定します。

600秒

1-2147483647で秒単位

2. プロセスのストール監視間隔

スレッド初期化前及びスレッド終了後にかかる時間のタイムアウト値を設定します。

600秒

1以上の整数で秒単位

スレッド初期化時間のタイムアウト値は以下の場所で時間のかかる処理を行っている場合に考慮が必要です。

設定を反映させるためにはアプリケーショングループを再起動してください。

また、プロセスのストール監視間隔のタイムアウト値は以下の場所で時間のかかる処理を行っている場合に考慮が必要です。

設定を反映させるためにはTPシステムを再起動してください。

設定方法
  1. スレッド初期化時間

    統合運用管理ツールのプロセスグループの[スレッド制御]-[スレッドの初期化時間の上限]

  2. プロセスのストール監視間隔

    統合運用管理ツールのTPシステムの[上限設定]-[プロセスのストール監視間隔]

2.1.4.3. 呼び出しタイムアウト

2.1.4.4. 実行時間タイムアウト

サーバ側のオペレーション実行開始から実行完了までのタイムアウト値を設定します(既定値:600秒)。この値はサーバでの実行時間のみ考慮して設定します(キュー待ち時間は含みません)。

オペレーションの実行をタイムアウトさせる場合は、オペレーションの[実行時間の上限超過時にプロセスを強制停止する]設定にチェックを入れてください。タイムアウト値はオペレーションの[実行時間の上限]で設定できます。いずれもTPシステムに設定した場合は全てのオペレーションに一括設定されます。

なお、実行時間タイムアウト値は運用アシスタントの実行時間の上限の適正値算出機能により推奨値が自動設定されている場合があります。[実行時間の上限超過時にプロセスを強制停止する]にチェックを入れる場合は、実行時間タイムアウト値の設定値が問題ないかを検討して下さい。

これらの設定を変更した場合、予期しない時間で強制停止されることを防ぐために、運用アシスタントの適正値算出機能を停止させます。運用アシスタントに実行時間の上限を自動設定させたい場合は、 再度設定を行ってください。実行時間の上限における適正値算出機能の詳細は [製品構成と提供機能 >3. 提供機能 > 3.4. TPモニタ > 3.4.4.TPモニタの障害に対する機能 > 3.4.4.5. 運用アシスタント ] の実行時間の上限の適正値算出を参照してください。

なお、実行時間タイムアウト値を超過した場合、プロセスは終了します。プロセスを再起動させるためには再起動回数(統合運用管理ツールのTPシステムの[上限設定]-[プロセス障害時の再起動回数])を2以上にする必要があります。推奨はデフォルトの5です。プロセス障害時の再起動回数が1でプロセスが終了した場合、プロセスは終了したままで再起動しませんので注意してください。

設定方法

統合運用管理ツールの以下の設定を変更します。
オペレーションの[オペレーション制御]-[実行時間の上限]
オペレーションの[オペレーション制御]-[実行時間の上限超過時にプロセスを強制停止する]

2.1.4.5. クライアント無通信監視間隔

TPシステム利用時、サーバとクライアントの間、または、WebサーバとAPサーバの間の無通信状態を監視します(既定値:しない)。本タイマ値以上無通信状態(具体的には要求も応答も流れない状態)が続いた場合はコネクションを切断します。設定を反映させるためにはTPシステムの再起動が必要です。

設定方法

統合運用管理ツールの[IIOPリスナ]-[クライアント制御]-[クライアントとの無通信監視を行う]及び[クライアントとの無通信監視間隔]
または
統合運用管理ツールの[AJPリスナ]-[クライアント制御]-[Webサーバとの無通信監視を行う]及び[Webサーバとの無通信監視間隔]

2.1.4.6. キューイング数上限

サーバアプリケーションすべてのスレッドがクライアントからのリクエスト処理を行なっている場合、新たな要求はキューイングされ実行待ちとなります。既定値ではメモリの許す限りキューイングされてしまい、クライアントから見るとキュー数が増えれば増えるほど無応答時間が長くなります。ある程度以上のキューイングを抑制することによりクライアントのレスポンスを保証することが出来ます。

(平均待ち時間)=(平均サービス時間)*{(キュー数)+1}

設定方法

統合運用管理ツールでプロセスグループ毎に設定できます。

プロセスグループの[キューの最大数]-[リクエストキューのサイズ]

2.1.4.7. 接続クライアント数上限

IIOPリスナを使ってrichクライアントを動作させる場合、またはAJPリスナを使ってthinクライアントを動作させる場合、想定以上の接続を受けるとサーバ側資源(主にメモリとファイルディスクリプタ)を余分に使います。 接続数に上限を設けることにより設定以上のクライアントから要求を受け付けなくすることが出来ます。ただし接続クライアント数をぎりぎりに設定してしまうとゴーストセッションが残っている場合、 接続できなくなる可能性がありますので、ゴーストセッションの対策をとった上である程度の余裕を持たせてください。 ゴーストセッションの対策については [ トラブルシューティングガイド > 2. 障害解析 > 2.3. ログ情報から > 2.3.1. イベントログ・syslog > クライアント接続数オーバへの対応] を参照してください。

設定方法

統合運用管理ツールの[TPシステム]-[IIOPリスナ]-[上限設定]-[最大同時接続クライアント数]
統合運用管理ツールの[TPシステム]-[AJPリスナ]-[上限設定]-[最大同時リクエスト処理数]

2.1.4.8. セッションあたりの同時実行数

thinクライアント構成の場合、Webサーバから1つのセッションを通して多重にリクエスト要求が発行されます。 クライアント数やトランザクション処理件数に応じた1セッションあたりの同時実行数を設ける必要があります。 本設定は、IIOPリスナ利用時にのみ有効です。

設定方法

統合運用管理ツールの[TPシステム]-[IIOPリスナ]-[クライアント制御]-[1セッションあたりのリクエスト多重度]

2.1.4.9. 電文長の長いメッセージの送受信

サーバ側の送受信の上限は設定の有無にかかわらず99,999,998バイト(約100M)となります。

また、クライアントがVBまたはC++の場合、電文の受信最大サイズは8,388,608バイト(8M)となります。クライアント側での受信電文長を10Mまで増やしたい場合はクライアントマシンのレジストリ変更が必要です。

設定方法

レジストリの名前:HKEY_LOCAL_MACHINE\SOFTWARE\NEC\ObjectSpinner\1\MaxMessageSize
属性:文字列属性(REG_SZ)
値  :0〜4294967295(単位:バイト)
意味:受信可能とする最大サイズを指定します。
補足:送信には関係ありません。

2.1.4.10. 接続要求最大保留数

クライアントから瞬時に大量の接続要求が来た場合、WebOTX側での接続処理が間に合わずクライアントへエラーが返ってしまうことがあります。このような場合には本パラメータの値を大きくすることにより、接続要求をサーバ側で保留することができます。

設定方法

統合運用管理ツールの[TPシステム]-[IIOPリスナ]-[クライアント制御]-[接続要求最大保留数]
統合運用管理ツールの[TPシステム]-[AJPリスナ]-[クライアント制御]-[接続要求最大保留数]

2.1.4.11. メモリプールサイズ

クライアントからのCORBAリクエストはメモリプールとして事前に確保した共有メモリ上に受信されます。また、サーバからのCORBA応答もメモリプールに展開された後に送信を行います。これらの領域は、クライアントへの送信が完了した時点で解放されます。
このような管理方式にすることで、外因によらず迅速で確実なバッファ取得ができることになりますが、一方で、このサイズを適当な値に設定する必要があります。
バッファ使用区間はCORBAリクエストの受信から送信までですので、サーバ側でのオペレーションの同時実行数が上がるほどバッファが必要になります(キューイングされているものも含む)。また、リクエストや応答のメッセージサイズが大きいほどバッファが必要になります。
なお、本用途に使用されるバッファ領域はメモリプールサイズ×0.9となります。

必要なメモリプールサイズの最大値は次のとおり計算できます。

(メモリプールサイズの最大値) = (メモリブロック数) * (ブロックサイズ)
(メモリブロック数) = {もっとも大きい電文のサイズ/(ブロックサイズ) + 1} *
             (WebOTXで同時に処理するオペレーション数)
(ブロックサイズ) = 4704 bytes

設定方法

統合運用管理ツールの[TPシステム]-[システムパラメータ/動的情報]-[送受信用共有メモリサイズ]


2.1.4.12. プロセス障害時の再起動回数

プロセスグループのプロセスが異常終了したとき、自動再起動させる回数を1から55000の範囲の整数で設定します。 1を設定すると、プロセスは再起動しません。全てのプロセスグループに対してこの設定は有効となります。

プロセスグループ単位で、プロセスが自動で再起動する回数は次の計算式の通りです。
(プロセス再起動回数) = (プロセス多重度) × { (プロセス障害時の再起動回数) − 1 }

例えば、(プロセス多重度)が4で(プロセス障害時の再起動回数)を5に設定している場合、 プロセスグループ単位でプロセスは計16回再起動します。 4プロセスの内で特定のプロセスのみが異常終了している場合でも、16回まで自動で再起動します。

なお、[TPシステム]-[上限設定]-[プロセスを正常と仮定する間隔]で設定されている時間内にプロセスの異常終了が起こらなかった場合、プロセス再起動回数はクリアされ、初期値にリセットされます。

設定方法

統合運用管理ツールの[TPシステム]-[上限設定]-[プロセス障害時の再起動回数]

2.1.4.13. TPシステム(システムパラメータ)

統合運用管理ツールのTPシステム(システムパラメータ)で設定可能なパラメータで、 設定値に対するメモリ使用量の計算式は次のとおりです。

  1. 最大プロセス数
    設定値 * 688byte

  2. 最大コンポーネント数
    最大コンポーネント数の設定値 * 最大プロセス数の設定値 * 8byte

  3. 最大インタフェース数
    最大インタフェース数の設定値 * 最大プロセス数の設定値 * 4byte

  4. 最大オペレーション数
    設定値 * 1016byte

設定方法

統合運用管理ツールの以下の設定を変更します。
[TPシステム]-[システムパラメータ/静的情報]
[TPシステム]-[システムパラメータ/動的情報]

2.2. WebOTX Webサーバ

全エディションにおけるWebOTX Webサーバのチューニングについて説明します。

2.2.1. リクエスト処理

WebOTX Webサーバは、親プロセスと複数の子プロセスで構成されます。ブラウザから受信したリクエストは、子プロセスに割り当てられて、リクエスト処理を実行します。

プラットフォームにより、子プロセスでのリクエストの処理方法が異なります。

UNIXの場合、マルチスレッド動作をする子プロセスが複数個起動し、子プロセス内の1スレッドで1つのリクエストを処理します。子プロセスの数は受け付けたリクエスト数により増減します。

Windows の場合、マルチスレッド動作をする子プロセスが1個起動し、子プロセス内の1スレッドで1つのリクエストを処理します。子プロセスの数は受け付けているリクエスト数に関係なく常に1固定です。

2.2.1.1. 最大同時リクエスト処理数

WebOTX Webサーバが同時に処理できるリクエストの数を変更するには、最大同時リクエスト数の値を変更します。${INSTANCE_ROOT}/config/WebServer/httpd.conf を変更します。

UNIX

MaxClients 250

Windows

ThreadsPerChild 250

※本設定値に大きな値を設定すると、その分メモリ等のシステム資源が必要になりますので、値を変更する際には十分注意してください。

2.2.1.2. その他の設定項目

WebOTX Webサーバのリクエスト処理数に関係するその他の設定項目は以下のとおりです。システム要件に合わせて各値を調整します。${INSTANCE_ROOT}/config/WebServer/httpd.conf を変更します。

UNIX

表2.2.1.2-1

指示子

説明

既定値

MaxClients

最大同時リクエスト処理数。子プロセスで動作するスレッドの総数。本値を変更する場合には、ThreadsPerChild/ServerLimit/ThreadLimitの各値を調整します。

250

ThreadsPerChild

子プロセスで生成されるスレッド数。
ThreadLimit以下の値を設定します。

25

StartServers

起動初期化時のプロセス数。

2

MinSpareThreads

アイドル状態でのスレッド総数の最小数。

25

MaxSpareThreads

アイドル状態でのスレッド総数の最大数。

75

MaxRequestsPerChild

子プロセスが処理するリクエストの最大総数。本指定数のリクエストを受信すると子プロセスは終了します。0を指定すると子プロセスは動作し続けます。

0

ServerLimit

子プロセスの上限値。20000まで指定可能。

16

ThreadLimit

子プロセスで動作するスレッド数の上限値。
15000まで指定可能。

64

各指示子の詳細については、以下を参照してください。

http://httpd.apache.org/docs/2.2/mod/worker.html

http://httpd.apache.org/docs/2.4/mod/worker.html


Windows

表2.2.1.2-2

指示子

説明

既定値

ThreadsPerChild

最大同時リクエスト処理数。子プロセスで動作するスレッドの総数。4096まで指定可能。

250

MaxRequestsPerChild

子プロセスが処理するリクエストの最大総数。本指定数のリクエストを受信すると子プロセスは終了します。0を指定すると子プロセスは動作し続けます。

0

各指示子の詳細については、以下を参照してください。

http://httpd.apache.org/docs/2.2/mod/mpm_winnt.html


2.3. Webコンテナ

全エディションにおける Webアプリケーション実行時の Webコンテナのチューニングについて説明します。

2.3.1. プロセッサ数

Webコンテナには、Webブラウザからのリクエストを処理するプロセッサが存在し、リクエストが来るとスレッドが割り当てられ、プロセッサがリクエスト処理を実行します。

同時に複数のリクエストが来た場合それだけプロセッサを消費しますが、その数を調整することで、同時に処理できるリクエストの数を制限したり、拡大したりすることができます。

2.3.1.1. 最大プロセッサ数

同時に処理できるリクエストの数を変更するには、最大プロセッサ数の値を変更します。 この設定はスタンダードモード時のみ適用されます。

【スタンダードモード】

otxadmin を使用して次のコマンドを実行します。

otxadmin> set  --user <ユーザ名> --password <パスワード > --host <ホスト名> --port <管理ポート> server.thread-pools.thread-pool.<スレッドプールID>.max-thread-pool-size=<最大数>

get コマンドを利用すれば、現在の値を確認できます。

otxadmin> get server.thread-pools.thread-pool.<スレッドプールID>.*

なお、標準では以下のスレッドプール(スレッドプールID)が定義されています。

スレッドプールがどのリスナで利用しているかの確認はWeb版運用管理コンソールから以下のツリーを選択し、 属性の「スレッドプール」値によって確認することができます。

  「アプリケーションサーバ」
    「ネットワーク構成」
      「ネットワークリスナ構成」
        「<リスナ名>」

otxadminコマンドでは以下を実行することで各リスナで利用しているスレッドプールの一覧が表示されます。

otxadmin> get server.network-config.network-listeners.network-listener.*.thread-pool
実行例 :
server.network-config.network-listeners.network-listener.admin-listener.thread-pool = admin-thread-pool
server.network-config.network-listeners.network-listener.ajp-listener-1.thread-pool = http-thread-pool
server.network-config.network-listeners.network-listener.http-listener-1.thread-pool = http-thread-pool
server.network-config.network-listeners.network-listener.http-listener-2.thread-pool = http-thread-pool

【アドバンスドモード】

Webコンテナの最大処理スレッド数を変更するには、運用管理コンソールの以下の設定値を変更します。

[TPシステム] - [アプリケーショングループ] - <アプリケーショングループ名> - [プロセスグループ] -<プロセスグループ名>の順にクリックしていき、 [属性]タブ - [スレッド制御] - [スレッド数]の値を変更します。

Webコンテナのプロセス数を変更するには、運用管理コンソールの以下の設定値を変更します。

[TPシステム] - [アプリケーショングループ] - <アプリケーショングループ名> - [プロセスグループ] -<プロセスグループ名>の順にクリックしていき、 [属性]タブ - [プロセス制御] - [プロセス数]の値を変更します。

これらのパラメータのチューニングの指針については「2.3.4. Webコンテナチューニングの指針」を参照してください。

2.3.1.2. 最小プロセッサ数

最大プロセッサ数に応じて最小プロセッサ数の値を変更します。 この設定はスタンダードモード時のみ適用されます。

otxadmin を使用して次のコマンドを実行します。

otxadmin> set  --user <ユーザ名> --password <パスワード > --host <ホスト名> --port <管理ポート> server.thread-pools.thread-pool.<スレッドプールID>.min-thread-pool-size=<最小数>

get コマンドを利用すれば、現在の値を確認できます。

otxadmin> get server.thread-pools.thread-pool.<スレッドプールID>.*

なお、標準では以下のスレッドプール(スレッドプールID)が定義されています。

2.3.2. プラグインのリクエスト処理数

ドメインをWebOTX Webサーバなどの外部のWebサーバと連携した場合、Webサーバとドメインを接続するプラグインモジュールが存在します。

Webサーバやドメインでリクエストを処理するプロセッサ(スレッド)と同様にプラグインで同時にリクエスト処理数を調整することができます。

2.3.2.1. 最大同時リクエスト処理数

同時に処理できるリクエストの数を変更するには、connection_pool_size の値を変更します。

connection_pool_size は、ドメインディレクトリの config/WebCont配下の workers.properties(スタンダードモード時)/ior_workers.properties(アドバンスドモード時)に定義します。このファイルをエディタで開いて編集してください。

具体的には、次のようになります。"worker.ajp13"(スタンダードモード時)/"worker.otxiiop"(アドバンスドモード時)については通常固定と考えてください(プラグインの負荷分散機能を利用した場合は可変となります)。デフォルト値は 150 です。

worker.ajp13.connection_pool_size=150 (スタンダードモード時)
worker.otxiiop.connection_pool_size=150 (アドバンスドモード時)

値を反映するには Webサーバを再起動する必要があります。

また、アドバンスドモード時は追加で以下の設定が必要になります。

統合運用管理ツールより、[TPシステム]-[IIOP リスナ]-[クライアント制御]-[1プロセスあたりの多重度]に connection_pool_size と同値を設定します。

2.3.3. セッション数の確認方法

本節では、Webコンテナ上で動作する Webアプリケーションのセッションに関する情報の収集について説明します。

2.3.3.1. スタンダードモード

スタンダードモードでセッション数を確認するにはアプリケーションの統計情報を採取します。具体的には、統合運用管理ツールや Web版統合運用管理コンソール、もしくは otxadmin コマンドから Webコンテナのモニタリングレベル "HIGH" にする必要があります。

統合運用管理ツールや Web版統合運用管理コンソールからは、「アプリケーションサーバ/モニタリングサービス/モジュールモニタリングレベル」の Webコンテナを "HIGH" にします。otxadmin コマンドからは以下のコマンドを入力してください。

otxadmin> set server.monitoring-service.module-monitoring-levels.web-container=HIGH

上記のコマンドを実行すれば、その時点から、アプリケーション毎のセッション数をそれぞれ次の場所(方法)で確認することができます。

統合運用管理ツール/Web版統合運用管理コンソール

[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[<アプリケーション>]-[<アプリケーション名>]-[session] の順にクリックしていき、「統計値」タブで確認。

otxadmin コマンド
まず、以下のコマンドを実行して配備されたアプリケーションの名一覧を表示させます。

otxadmin> list-components

上記で表示されたリストの中から、希望のアプリケーション名を確認して以下のコマンドを実行します。

otxadmin> get --monitor server.applications.<アプリケーション名>.*.session.*

表示される項目の意味は次の通りです。

表2.3.3.1-1

項目名

説明

activesessionscurrent-Current

現在アクティブなセッションの数(単位:個)

activatedsessionstotal-Count

生成されたセッションの累計数(単位:個)

expiredsessionstotal-Count

有効期限が切れたセッションの累計数(単位:個)


Caution 【セッションレプリケーション時の注意事項】

2.3.3.2. アドバンスドモード

アドバンスドモードでセッション数を確認するにはアプリケーションの統計情報を採取します。具体的には、統合運用管理ツールやWeb版統合運用管理コンソール、もしくは otxadmin コマンドから Webコンテナのモニタリングレベル "HIGH" にする必要があります。

統合運用管理ツールやWeb版統合運用管理コンソールからは、「アプリケーションサーバ/モニタリングサービス/モジュールモニタリングレベル」の Webコンテナを "HIGH" にします。otxadmin コマンドからは以下のコマンドを入力してください。

otxadmin> set server.monitoring-service.module-monitoring-levels.web-container=HIGH

上記のコマンドを実行すれば、その時点から、アプリケーション毎のセッション数をそれぞれ次の場所(方法)で確認することができます。

統合運用管理ツール/Web版統合運用管理コンソール

[統計情報]-[<ドメイン名>]-[TPシステム]-[アプリケーショングループ]-[<アプリケーショングループ名>]-[プロセスグループ]-[<プロセスグループ名>]-[processes]-[<プロセスID>]-[applications]-[<アプリケーション名>]-[<仮想サーバ名>]-[session] の順にクリックしていき、「統計値」タブで確認。

otxadmin コマンド
まず、以下のコマンドを実行して配備されたアプリケーションの名一覧を表示させます。

otxadmin> list-components

上記で表示されたリストの中から、希望のアプリケーション名を確認して以下のコマンドを実行します。

otxadmin> get --monitor tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.processes.<プロセスID>.applications.<アプリケーション名>.*.session.*

表示される項目の意味は次の通りです。

表2.3.3.2-1

項目名

説明

activesessionscurrent-Current

現在アクティブなセッションの数(単位:個)

activatedsessionstotal-Count

生成されたセッションの累計数(単位:個)

expiredsessionstotal-Count

有効期限が切れたセッションの累計数(単位:個)


※ 複数のプロセスを起動している時に該当アプリケーションで合計いくつのセッションが消費されているかを確認するには、全てのプロセスID のセッション数(activesessionscurrent-Current)を見て合計してください。

Caution 【セッションレプリケーション時の注意事項】

2.3.4. Webコンテナチューニングの指針

本節では、Webコンテナのチューニング方法やその指針ついて説明します。

WebOTX Webコンテナでは、利用するエディションによって選択できる動作形態が異なります。Express ではスタンダードモードを、Standard/Enterprise ではスタンダードモードに加えてアドバンスドモードも選択可能です。

スタンダードモードとは、Webコンテナを運用管理エージェントのJava VM プロセス(エージェントプロセス)で動作させるもので、Java EE 技術をベースにした Webベースのシステムを迅速に開発・運用することができます。アドバンスドモードは、WebコンテナをTPモニタ内に配置して複数の Java VM プロセスで多重化し TPモニタで制御するもので、高い信頼性が要求される基幹業務システムを構築することができます。また、アドバンスドモードでは、WebOTX システムを載せたマシンを複数台クラスタ構成で構築したより高信頼・高可用性のある運用をサポートします。それぞれの動作イメージは以下のとおりです。

2.3.4.1. スタンダードモード(内蔵Webサーバ)

スタンダードモードで内蔵Webサーバを利用した場合の構成例は次のとおりです。


図2.3.4.1-1

この構成でチューニングするポイントは以下のとおりです。

  1. Webコンテナの最小プロセッサ数
  2. Webコンテナの最大プロセッサ数
  3. ドメインの最小ヒープサイズ
  4. ドメインの最大ヒープサイズ
  5. レスポンスを圧縮する最小コンテンツサイズ

これらをどのような値にするかは、利用する環境により変化します。(a), (b) については想定される同時アクセス数が、(c), (d) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。

(a), (b) について、Webコンテナのスレッド数は同時リクエスト数に応じて最小プロセッサ数から最大プロセッサ数に向けて増加していきますが、スレッド数の増加が追いつかない場合、バックログキューにキューイングされます。このバックログキューがあふれるとコネクションが切断されエラーとなります。以下をチューニングの指針としてください。

(最大プロセッサ数 - 最小プロセッサ数)> バックログキューの数

このバックログキューは "accept-count" で変更しますので必要に応じて調整してください。

(e)については、クライアント⇔Webコンテナ間のネットワーク速度とWebコンテナが動作しているマシンのCPU性能によって変わってきます。 基本的に、レスポンスデータが少ない場合に圧縮を行うとCPUの無駄使いとなり、圧縮しない場合よりもトランザクション性能が落ちます。ところが、あるサイズ以上のレスポンスデータになると圧縮を行ったほうが行わない場合に比べトランザクション性能が良くなります。この境界点を見極めて、レスポンスを圧縮する最小コンテンツサイズを決定します。

以下に参考データを掲載します。このデータを元にレスポンスを圧縮する最小コンテンツサイズの既定値は 6KB としています。ご利用の環境で想定されるデータを数種類実測し下記と異なる傾向があればこの値を変更してください。なお、この設定は内蔵Webサーバを使用した場合のみ有効です。


図2.3.4.1-2



図2.3.4.1-3



図2.3.4.1-4

またヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gc オプションを指定してヒープの状況を確認しながらチューニングを行うことになります。

それぞれのパラメータの設定方法については、 [ リファレンス集 ドメイン構成・環境移行編 > 2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド ] 、および [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ ] を参照してください。

2.3.4.2. スタンダードモード(外部Webサーバ)

スタンダードモードで外部Webサーバを利用した場合、外部Webサーバにプラグイン(mod_jkプラグイン)が配置されます。 Webサーバが受け取ったリクエストはプラグインを経由して Webコンテナに送られます。

スタンダードモードで外部Webサーバを利用した場合の構成例は次のとおりです。


図2.3.4.2-1

この構成でチューニングするポイントは以下のとおりです。

  1. Webサーバの最大同時接続数
  2. プラグインの最大同時接続数
  3. Webコンテナの最小プロセッサ数
  4. Webコンテナの最大プロセッサ数
  5. ドメインの最小ヒープサイズ
  6. ドメインの最大ヒープサイズ

これらをどのような値にするかは、利用する環境により変化します。(a), (b), (c), (d) については想定される同時アクセス数が、(e), (f) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。

このうち (a), (b) はお互いの設定値の大小関係により動作が変わってきます。WebOTX Webサーバには同時リクエスト処理数を扱うパラメータとして "ThreadsPerChild" があります。プラグインの "connection_pool_size" はこの "ThreadsPerChild" と一緒に考えます。

(d) については「WebOTX Webサーバの最大同時リクエスト処理数(ThreadsPerChild x Webサーバのプロセス数)+ 5」としておくことをお勧めます。また、Webコンテナの最大プロセッサ数を超えて受け付けられなかったリクエストは Webコンテナのバックログキューに溜まります。

また、特にヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gcオプションを指定してヒープの状況を確認しながらチューニングを行うことになります。

それぞれのパラメータの設定方法については、 [ リファレンス集 ドメイン構成・環境移行編 > 2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド ] 、および [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ ] を参照してください。

2.3.4.3. アドバンスドモード(単一サーバ)

【AJPリスナを用いる場合】

アドバンスドモードでAJPリスナを用いる場合、スタンダードモード(外部Webサーバ)と同様に、外部Webサーバにプラグイン(mod_jkプラグイン)が配置されます。

アドバンスドモード(AJPリスナ)を利用した場合の構成例は次のとおりです。


図2.3.4.3-1

上記構成でチューニングするポイントは以下のとおりです。

    【AJPリスナ利用時】
  1. Webサーバの最大同時接続数
  2. プラグインの最大同時接続数
  3. AJPリスナの同時接続クライアント数
  4. AJPリスナの1セッションあたりのリクエスト多重度
  5. Object Broker C++の各種パラメータ
  6. Webコンテナのプールバッファ領域の個数
  7. プロセスグループのキュー
  8. プロセスグループのスレッド数
  9. プロセスグループの初期ヒープサイズ
  10. プロセスグループの最大ヒープサイズ

これらをどのような値にするかは、利用する環境により変化します。(a), (b), (c), (d), (e), (g), (h) については想定される同時アクセス数が、(e), (h), (i) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。

(a), (b) については [2.3.4.2.スタンダードモード(外部Webサーバ)] と同様です。

(c) は接続してくるクライアント数以上の値を設定します。WebOTX Webサーバと連携している場合は Webサーバの httpdプロセス数がクライアント数となります。

(d) は接続してくるクライアント1つあたりの多重度となりますので、WebOTX Webサーバの同時クリエスと処理数(ThreadsPerChild)と同じ数になるように設定します。

(f) はリクエストを処理する時に使用するバッファ領域の個数です。Webコンテナに来たリクエストはこのバッファ領域を利用して処理されます。既定値は5で高負荷時には必要に応じて自動的に追加作成しますが、利用し終わったら破棄し初期値まで戻ります。常に多数のリクエストが同時に来ることが想定される場合はこの値を調整します。次のシステムプロパティで指定します。
-Dcom.nec.webotx.enterprise.web.connector.poolBufferSize=<バッファの個数>

(g) はプロセスグループに来るリクエストがキューイングされるキューです。全てのスレッドはこのキューへの到着を待ち合わせます。このキューを制限することによりオーバしたリクエストを即座にエラーとし、高負荷時でもリクエストのクライアントへのレスポンス時間を保証することが可能です。

(h) は作成するプロセスグループの数、一つのプロセスグループ内で動作するプロセスの数、そして、リクエスト処理性能により決定します。
例えば、あるプロセスグループに300リクエストが同時に来てリクエスト間隔が0.2(リクエスト/秒) の場合、1秒間のリクエスト処理数は「300(リクエスト) x 0.2(リクエスト/秒) = 60(リクエスト/秒)」となります。そして、1スレッドの処理数を 3リクエスト/秒と仮定した場合、プロセスグループ内で必要なスレッド多重度は「60(リクエスト/秒) / 3(リクエスト/秒) = 20(スレッド)」となります。
プロセス多重度を2に設定した場合の1プロセスあたりに必要なスレッド数は、半分の 10 になります。

また、特にヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gc オプションを指定してヒープの状況を確認しながらチューニングを行うことになります。

それぞれのパラメータの設定方法については、 [ リファレンス集 ドメイン構成・環境移行編 > 2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド ] 、および [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ ] を参照してください。


【IIOPリスナを用いる場合】

アドバンスドモードでIIOPリスナを用いる場合はWebOTX Webサーバを利用することが前提となり、IIOPプラグインを利用します。

アドバンスドモード(IIOPリスナ)を利用した場合の構成例は次のとおりです。


図2.3.4.3-2

上記構成でチューニングするポイントは以下のとおりです。

    【IIOPリスナ利用時】
  1. Webサーバの最大同時接続数
  2. プラグインの最大同時接続数
  3. IIOPリスナの同時接続クライアント数
  4. IIOPリスナの1セッションあたりのリクエスト多重度
  5. Object Broker C++の各種パラメータ
  6. Webコンテナのプールバッファ領域の個数
  7. プロセスグループのキュー
  8. プロセスグループのスレッド数
  9. プロセスグループの初期ヒープサイズ
  10. プロセスグループの最大ヒープサイズ

これらをどのような値にするかは、利用する環境により変化します。(a), (b), (c), (d), (e), (g), (h) については想定される同時アクセス数が、(e), (h), (i) についてはアプリケーションやその他のライブラリがどれくらいのメモリを必要とするかによって変わってきます。

(a), (b) については [2.3.4.2.スタンダードモード(外部Webサーバ)] と同様です。

(c) は接続してくるクライアント数以上の値を設定します。WebOTX Webサーバと連携している場合は Webサーバの httpdプロセス数がクライアント数となります。

(d) は接続してくるクライアント1つあたりの多重度となりますので、WebOTX Webサーバの同時クリエスと処理数(ThreadsPerChild)と同じ数になるように設定します。

(f) はリクエストを処理する時に使用するバッファ領域の個数です。Webコンテナに来たリクエストはこのバッファ領域を利用して処理されます。既定値は5で高負荷時には必要に応じて自動的に追加作成しますが、利用し終わったら破棄し初期値まで戻ります。常に多数のリクエストが同時に来ることが想定される場合はこの値を調整します。次のシステムプロパティで指定します。
-Dcom.nec.webotx.enterprise.web.connector.poolBufferSize=<バッファの個数>

(g) はプロセスグループに来るリクエストがキューイングされるキューです。全てのスレッドはこのキューへの到着を待ち合わせます。このキューを制限することによりオーバしたリクエストを即座にエラーとし、高負荷時でもリクエストのクライアントへのレスポンス時間を保証することが可能です。

(h) は作成するプロセスグループの数、一つのプロセスグループ内で動作するプロセスの数、そして、リクエスト処理性能により決定します。
例えば、あるプロセスグループに300リクエストが同時に来てリクエスト間隔が0.2(リクエスト/秒) の場合、1秒間のリクエスト処理数は「300(リクエスト) x 0.2(リクエスト/秒) = 60(リクエスト/秒)」となります。そして、1スレッドの処理数を 3リクエスト/秒と仮定した場合、プロセスグループ内で必要なスレッド多重度は「60(リクエスト/秒) / 3(リクエスト/秒) = 20(スレッド)」となります。
プロセス多重度を2に設定した場合の1プロセスあたりに必要なスレッド数は、半分の 10 になります。

また、特にヒープサイズについては、最終的には実際にアプリケーションを配備して動作させ、-verbose:gc オプションを指定してヒープの状況を確認しながらチューニングを行うことになります。

それぞれのパラメータの設定方法については、 [ リファレンス集 ドメイン構成・環境移行編 > 2. 他APサーバ(Tomcat)からWebOTXへの移行ガイド ] 、および [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.4. Webコンテナ ] を参照してください。

2.3.4.4. アドバンスドモード(複数サーバ)

【AJPリスナを用いる場合】

アドバンスドモード(AJPリスナ)を利用した WebOTX システムを複数配置してロードバランサで振り分ける構成例は次のとおりです。


図2.3.4.4-1

複数のWebサーバにリクエストを振り分けるためのロードバランサが追加になるだけで、設定項目は [2.3.4.3.アドバンスドモード(単一サーバ)] と同様です。


【IIOPリスナを用いる場合】

アドバンスドモード(IIOPリスナ)を利用した WebOTX システムを複数配置してロードバランサで振り分ける構成例は次のとおりです。


図2.3.4.4-2

複数のWebサーバにリクエストを振り分けるためのロードバランサが追加になるだけで、設定項目は [2.3.4.3.アドバンスドモード(単一サーバ)] と同様です。

2.3.4.5. コネクター種別ごとの性能特性

Webコンテナには、Webブラウザからのリクエストを処理するプロセッサが存在し、リクエストが来るとスレッドが割り当てられ、プロセッサがリクエスト処理を実行します。
同時に複数のリクエストが来た場合それだけプロセッサを消費しますが、その数を調整することで、同時に処理できるリクエストの数を制限したり、拡大したりすることができます。

これらのコネクター種別の選択の指針を示します。これを参考にコネクターの種別を選択してください。

表2.3.4.5-1 コネクター種別毎の機能一覧

AJP

BIO

NIO

Grizzly

HTTP Request 読み込み

Blocking

Blocking

Non Blocking

Non Blocking

HTTP Body 読み込み

Blocking

Blocking

Blocking

Blocking

HTTP Response 書き込み

Blocking

Blocking

Blocking

Blocking

SSL Handshake

Blocking

Blocking

Non blocking

Non blocking

最大同時接続数

スレッド数と同じ

スレッド数と同じ

制限なし

制限なし

WebSocketのサポート

NO

NO

YES

NO

外部サーバ(Apache)連携

YES

NO

NO

NO

外部サーバ(Apache)連携用のコネクター

【スレッド数とスループットの関係】

以下に参考データを掲載します。
実際には、スループットが一番良いクライアント数で測定します。


図2.3.4.5-1

【クライアント数とスループットの関係】

以下に参考データを掲載します。
「最適なスレッド数の決定」で決定したスレッド数で測定します。


図2.3.4.5-2

内蔵サーバ連携用のコネクター

【スレッド数とスループットの関係】

以下に参考データを掲載します。
実際には、スループットが一番良いクライアント数で測定します。


図2.3.4.5-3

【クライアント数とスループットの関係】

以下に参考データを掲載します。
「最適なスレッド数の決定」で決定したスレッド数で測定します。


図2.3.4.5-4


2.3.5. Webサーバプラグインからのコネクション接続数の確認方法

本節では、外部Webサーバと連携している時、Webサーバプラグインからドメインへのコネクションの接続数の確認方法について説明します。

Webサーバプラグインからドメインへのコネクションの接続数を確認するには、Webサーバプラグインの「Jk Status Manager」を利用します。次の手順で「Jk Status Manager」を有効にします。

  1. workers.propertiesにstatusワーカを追加します。
  2. 新しいワーカはカンマ(,)区切りで追加します。statusワーカの名前は任意です。以下では「mystatus」という名前で追加しています(これ以降の記載では「mystatus」という名前を使用します)。

    変更前:   worker.list=ajp13
    変更後:   worker.list=ajp13, mystatus


    追加したmystatusワーカのタイプ定義を追加します。タイプは "status" 固定です。
    worker.listより後であればどこに追加しても問題ありません。

     worker.mystatus.type=status


  3. uriworkermap.propertiesにstatusワーカにアクセスするためのURLを追加します。

  4. WebOTX Webサーバ(Apache)をご利用の場合
    1. ${INSTANCE_ROOT}/config/WebServer/httpd.conf を開いてTM_WS_PLUGIN-start 〜 TM_WS_PLUGIN-end で囲まれた部分を編集し、".conf-auto" を".conf"に変更します。

      変更前:
         # TM_WS_PLUGIN-start
         include "${INSTANCE_ROOT}/config/WebCont/mod_jk-2(2|4).conf-auto"
         # TM_WS_PLUGIN-end
      変更後:
         # TM_WS_PLUGIN-start
         include "${INSTANCE_ROOT}/config/WebCont/mod_jk-2(2|4).conf"
         # TM_WS_PLUGIN-end

    2. ${INSTANCE_ROOT}/config/WebCont/mod_jk-2(2|4).conf-auto を ${INSTANCE_ROOT}/config/WebCont/mod_jk-2(2|4).conf にコピーします。

    3. ${INSTANCE_ROOT}/config/WebCont/mod_jk-2(2|4).conf を開いてJkMountFile のファイル名拡張子 ".properties-auto"を ".properties"に変更します。

      変更前:JkMountFile "${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties-auto"
      変更後:JkMountFile "${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties"


    IISをご利用の場合
    1. ${INSTANCE_ROOT}\config\WebCont\isapi_redirect.properties を開いてworker_mount_file のファイル名拡張子 ".properties-auto"を ".properties"に変更します。

      変更前:worker_mount_file=${INSTANCE_ROOT}\config\WebCont\uriworkermap.properties-auto
      変更後:worker_mount_file=${INSTANCE_ROOT}\config\WebCont\uriworkermap.properties


    WebOTX Webサーバ(Apache)/IIS ご利用の場合共通
    1. ${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties-auto を${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties にコピーします。

    2. ${INSTANCE_ROOT}/config/WebCont/uriworkermap.properties を開いてstatusワーカにアクセスするためのコンテキストの定義を追記します。この時のコンテキスト名は任意ですが、配備済みのコンテキストと重複しないようにしてください。

      /<コンテキスト名>=mystatus
      /<コンテキスト名>/*=mystatus

    3. WebOTX Webサーバ(Apache)/IISを再起動します。

  5. 「http://[host]:[port]/mystatus」にアクセスします。

「http://[host]:[port]/mystatus」にアクセスすると次のような「Jk Status Manager」の画面が表示されます。

この中で「Listing AJP Worker」の下に定義済みのワーカが表示されます。例では「Worker Status for ajp13」というワーカが定義されているのが分かります。そして、その下の「State」と記載されている行がそのワーカのコネクション情報が表示されている領域です。

Stateに表示されている項目のうち、コネクションに関する項目とその意味は次の通りです。

なお、「Worker Status for ajp13」の左側の「R」をクリックする事でワーカのStatusをリセットする事ができます。


2.4. JMS

JMSのチューニングについて説明します。ここでは、主に、メッセージの滞留に関するチューニングポイントについて説明しています。

以降の説明で、「設定方法」には、設定対象となる統合運用管理ツール上の項目名や、MOの属性名を記述しています。設定方法の詳細については、 [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.1. JMSサービスの操作 ] を参照してください。

2.4.1. JMSサーバの設定

JMSサーバの設定について説明します。

2.4.1.1. JVMヒープサイズの設定

JMSサーバにおけるJVMヒープの最大サイズは、デフォルトで192Mバイトに設定されています。通常、大量のメッセージ送受信でJMSサーバに負荷がある場合は、JVMヒープサイズを大きくする必要があります。

JMSサーバのJVMヒープの消費は、主にJMSサーバ内に滞留するメッセージの数とサイズに比例します。システムの運用上想定している数のメッセージが滞留した場合に、 どの程度のメモリが消費されるかを確認して十分なヒープサイズを設定することが必要になります。また、逆にシステムのリソースに合わせて、後述する設定を行うことにより滞留自体を抑止することも有効です。

確認方法

JVMヒープ内のその時点での総メモリ量と、使用可能な空きメモリ量は、JMSサーバに関する統計情報から確認できます。

統合運用管理ツールの場合:

総メモリ量 [WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[MemoryTotal]
空きメモリ量 [WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[MemoryFree]

運用管理コマンドの場合:

総メモリ量
otxadmin> get --monitor=true server.jms-service.MemoryTotal-Count
空きメモリ量
otxadmin> get --monitor=true server.jms-service.MemoryFree-Count

統計情報取得に必要な設定などの詳細については、マニュアル [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.4. JMSサービスの統計情報取得 ] を参照してください。

設定方法

必要な値を設定し、JMSサーバを再起動してください。

統合運用管理ツールで設定する場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[起動属性]-[JavaVM引数]

運用管理コマンドで設定する場合:

otxadmin> set server.jms-service.vmargs=<JavaVM引数>

例)
 統合運用管理ツールでの指定 : -Xms128 -Xmx384
 運用管理コマンド :

otxadmin> set server.jms-service.vmargs=”-Xms128 -Xmx384”

2.4.1.2. JMS起動タイムアウトの設定

JDBCストア利用時に、送信先にメッセージが大量に蓄積されていると、JMSサーバの起動に時間がかかり、JMSサーバの起動に失敗する場合があります。

この場合、ドメイン起動におけるJMSサーバ起動完了待ち時間を長くする必要があります。

確認方法

JMSサーバの起動に要する時間は、環境によって異なりますが、参考となる値は${INSTANCE_ROOT}/logs/wojms/wojmsserver.logから調べることができます。

ログレベルがデフォルトのINFOである場合、

[2008-06-05 11:17:30,892] [INFO]
==================================================================
WebOTX JMS
NEC Corporation.
バージョン: 8.10.0000
コンパイル: Thu 05/29/2008 09:25:02
==================================================================

が起動開始を示し、

[2008-06-05 11:17:35,986] [INFO] [B1039]: Broker "wojmsbroker@xxx:9700" ready.

が起動完了を示しますので、それぞれの先頭で出力されているタイムスタンプから、起動に必要となる時間を算出してください。

設定方法

設定した値は、次回のドメイン起動から有効になります。

統合運用管理ツールで設定する場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[起動属性]-[起動完了待ち時間]

運用管理コマンドで設定する場合:

otxadmin> setserver.jms-service.init-timeout-in-seconds=<起動完了待ち時間>

【備考】

2.4.2. 送信先の設定

物理的な送信先の設定について説明します。

2.4.2.1. プロデューサ最大数の設定

JMSサーバに必要以上にメッセージを滞留させないためには、メッセージを生成するプロデューサ数を制限することも有効な方法です。

確認方法

送信先の現在のプロデューサ数は、次の操作で確認できます。

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]- [送信先名]-[<送信先名>]-情報取得

運用管理コマンドの場合:

otxadmin> get-jmsdest-info <送信先名>

上記の操作で表示される、「Current Number of Producers」の値が現在のプロデューサ数です。

操作の詳細については、マニュアル [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.2. 送信先の操作 > 7.3.2.4. 情報取得 ] を参照してください。

設定方法

統合運用管理ツールで設定する場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[プロデューサの最大数]

運用管理コマンドで設定する場合:

otxadmin > set server.jms-service.jms-physical-destitination.<送信先名>.maxNumProducers=<プロデューサの最大数>

【備考】

2.4.2.2. アクティブコンシューマ数の設定

複数のキューコンシューマが送信先のメッセージを処理する効率は、ここで説明するアクティブコンシューマ数と、JMSサーバが一度の処理でコンシューマに配信するメッセージ数(「メッセージ滞留抑止の設定」参照)によって左右されます。

効率よくメッセージを処理するためには、十分な数のアクティブコンシューマがメッセージの配信に遅れずに対応する必要があります。メッセージがキューに蓄積している場合、メッセージを処理するアクティブコンシューマ数が不十分であることが考えられます。

確認方法

送信先に対する現在のアクティブコンシューマ数は、次の操作で確認できます。

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]- [送信先名]-[<送信先名>]-情報取得

運用管理コマンドの場合:

otxadmin> get-jmsdest-info <送信先名>

上記の操作で表示される、「Current Number of Active Consumers」の値が現在のアクティブコンシューマ数です。

操作の詳細については、マニュアル [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.2. 送信先の操作 > 7.3.2.4. 情報取得 ] を参照してください。

設定方法

統合運用管理ツールで設定する場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[アクティブコンシューマの最大数]

運用管理コマンドで設定する場合:

otxadmin > set server.jms-service.jms-physical-destitination.<送信先名>.maxNumActiveConsumers=<アクティブコンシューマの最大数>

【備考】

2.4.2.3. コンシューマへのフロー制限数の設定

JMSサーバが一度の処理でコンシューマに配信するメッセージ数が大きすぎる場合、メッセージがコンシューマ上で滞留する可能性があります。

たとえば、コンシューマへのフロー制限数が大きすぎると、ある一つのコンシューマがキュー内のすべてのメッセージを受信し、そのほかのコンシューマは何も受信していないことがあります。コンシューマの処理が高速であれば、これは問題になりませんが、コンシューマでの処理に時間がかかるような場合、メッセージを各コンシューマに均等に分散させるために、コンシューマへのフロー制限数を小さくする必要があります。

コンシューマでの滞留もメモリ消費につながるため、クライアントのJVMヒープサイズと合わせてフロー制限数を調整する必要があります。

設定方法

統合運用管理ツールで設定する場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[コンシューマへのフロー制限数]

運用管理コマンドで設定する場合:

otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.consumerFlowLimitNum=<コンシューマへのフロー制限数>

ただし、各コンシューマが使用するコネクションファクトリで指定された制限値の方が小さい場合は、その値のほうが優先されます。

【備考】

2.4.2.4. メッセージ滞留抑止の設定

送信先のメッセージ滞留を抑止するために、送信先単位、または、JMSサーバ全体でメッセージ数とメッセージの合計サイズを設定できます。送信先のメッセージ数、または、メッセージのバイト数が設定された制限に達した場合の動作は、次のものから選択することができます。

表2.4.2.4-1
動作 説明
REMOVE_OLDEST もっとも古いメッセージを削除する。
REMOVE_LOW_PRIORITY メッセージの有効期間に従いもっとも優先度の低いメッセージを削除する。
FLOW_CONTROL プロデューサとの間でフロー制御が行われ、プロデューサがブロックされる。
REJECT_NEWEST 新しいメッセージを拒否する。永続メッセージの場合はメッセージ拒否の例外をスローする。
確認方法

送信先に設定されている制限到達時の振る舞いは、以下で確認できます。

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[制限到達時の振る舞い]

運用管理コマンドの場合:

otxadmin > get server.jms-service.jms-physical-destitination.<送信先名>.limitBehavior

送信先、または、JMSサーバ全体の現在のメッセージ数とメッセージのバイト数を監視するには、統合運用管理ツールから参照できる統計情報を利用します。

送信先の場合は、[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]- [送信先名]-[<送信先名>]、JMSサーバ全体の場合は、[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]の「統計情報採取開始」を実行します。

送信先

メッセージ数 : MessagesNow
メッセージのバイト数 : MessageBytesNow

JMSサーバ全体

メッセージ数 : MessagesNow
メッセージのバイト数 : MessageBytesNow

統計情報取得に必要な設定などの詳細については、マニュアル [ ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.3. JMS > 7.3.2. 送信先の操作 > 7.3.2.4. 情報取得 ] を参照してください。

設定方法

送信先ごとのメッセージ滞留抑止に関する値は、以下で設定します。

統合運用管理ツールで設定する場合:

メッセージの最大数
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[メッセージの最大数]

メッセージの最大サイズ
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[メッセージの最大合計サイズ]

制限到達時の振る舞い
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[送信先名]-[<送信先名>]-[拡張]-[制限到達時の振る舞い]

運用管理コマンドで設定する場合:

メッセージの最大数

otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.maxNumMsgs=<メッセージの最大数>

メッセージの最大サイズ

otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.maxTotalMsgBytes=<メッセージの最大合計サイズ>

制限到達時の振る舞い

otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.limitBehavior=<制限到達時の振る舞い>

JMSサーバ全体のメッセージ滞留抑止に関する値は、以下で設定します。

統合運用管理ツールで設定する場合:

メッセージの最大数
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[JMSサーバ情報]-[JMSサーバ内メッセージ最大数]

メッセージの最大サイズ
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-[JMSサーバ情報]-[JMSサーバ内メッセージ最大合計サイズ]

運用管理コマンドで設定する場合:

メッセージの最大数

otxadmin> set server.jms-service.systemMaxCount=<JMSサーバ内メッセージ最大数>

メッセージの最大サイズ

otxadmin> set server.jms-service.systemMaxSize=<JMSサーバ内メッセージ最大合計サイズ>
【備考】
【注意】

2.4.3. コネクションの設定

コネクション関連の設定について説明します。

2.4.3.1. クライアント・サーバ間の相互監視の設定

WebOTX JMSは、サーバとクライアント間の相互通信にTCP/IPプロトコルを利用していますが、データ受信を主体としている場合、ネットワークの異常を検知できないような事象(簡単な例だと、 相手側のケーブルが抜けたような場合)が発生する場合があり、次のような問題を引き起こす可能性があります。

このような問題を防ぐために、クライアントアプリケーションのライブラリレベルで、JMSサーバとの接続を定期的にチェックする機能を提供しています。

この機能はデフォルトで動作しますが、監視間隔は任意の値に変更することができます。

設定方法(JMSサーバ)

JMSサーバに対する設定は、次のプロパティが対象になります。

wojms.ping.enabled
wojms.ping.interval

起動引数として設定する方法と、config.propertiesファイルに設定する方法とがあります。設定方法や設定値の詳細については、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.1. JMS設定項目・設定方法 ] をご覧ください。

起動引数

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサーバ]-[起動属性]-[起動引数]で以下の設定を行ってください。

-Dwojms.ping.enabled=true -Dwojms.ping.interval=120

運用管理コマンドの場合:
setコマンドで以下の設定を行ってください。

otxadmin> set server.jms-service.start-args=” -Dwojms.ping.enabled=true -Dwojms.ping.interval=120”

config.properties

ファイルに以下の設定を行ってください。

wojms.ping.enabled=true
wojms.ping.interval=120
設定方法(JMSクライアント)

コネクションファクトリリソース

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[JMSリソース]-[コネクションファクトリリソース]-[<コネクションファクトリ名>]-[接続]-[接続監視の間隔]

運用管理コマンドの場合:

otxadmin> set server.resources.jms-resource.jms-connection-factory.<コネクションファクトリ名>.wojmsPingInterval=<接続監視の間隔>

2.4.3.2. JMSサーバからの受諾通知タイムアウト時間の設定

プロデューサからのメッセージ送信に対して、JMSサーバが受諾通知を返すようになっているときに、JMSサーバへの負荷が高い場合や、ネットワークの通信速度が遅いような場合、 プロデューサが受諾通知を受け取るまでに時間がかかることがあります。このような場合、デフォルトでは、JMSサーバから受諾通知が届くまで、プロデューサの呼び出しスレッドはブロックするようになっています。

この、受諾通知を待ち合わせる時間は、コネクションファクトリのwojmsAckTimeout(通知タイムアウト)で決めることができます。デフォルトでは、タイムアウトせず、必ず待ちあわせる設定になっています。

受諾通知を待ち続けるのではなく、決められた時間以内に届かないときにはエラーを発生させたい場合、この値を設定してください。

確認方法

コネクションファクトリの現在の通知タイムアウト値は、以下で確認できます。

コネクションファクトリリソース

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[JMSリソース]-[コネクションファクトリリソース]-[<コネクションファクトリ名>]-[フロー制御]-[通知タイムアウト]

運用管理コマンドの場合:

otxadmin> get server.resources.jms-resource.jms-connection-factory.<コネクションファクトリ名>.wojmsAckTimeout

設定方法

コネクションファクトリリソース

統合運用管理ツールの場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[JMSリソース]-[コネクションファクトリリソース]-[<コネクションファクトリ名>]-[フロー制御]-[通知タイムアウト]

運用管理コマンドの場合:

otxadmin> set server.resources.jms-resource.jms-connection-factory.<コネクションファクトリ名>.wojmsAckTimeout=<通知タイムアウト>

【備考】

2.4.4. JMSクライアントのチューニング情報採取

JMSクライアントについてのチューニング情報採取について説明します。ここで採取した情報から、クライアント側にメッセージが滞留することによるメモリ負荷の状況を把握することができます。

まず、JMSサーバ側で提供する情報によって、どのJMSクライアントに問題がありそうかを把握し ([ 2.4.4.1. JMSサーバ側での情報採取 ] )、 その後、問題のありそうなJMSクライアント側で情報を採取する ([ 2.4.4.2. JMSクライアント側での情報採取 ] ) という手順になります。

2.4.4.1. JMSサーバ側での情報採取

JMSサーバ側ではコネクション単位にメモリ情報を採取し、コネクション一覧で採取した情報を表示します。

設定方法

統合運用管理ツールで設定する場合:
以下の属性をチェックします。

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]- [JMSサーバ情報]-[JMSクライアントメモリ情報採取]

運用管理コマンドで設定する場合:

otxadmin> set server.jms-service.enableClientMetrics=true

採取情報

コネクション単位に次の情報を採取します。

表2.4.4.1-1
項目 説明
Max Memory JavaVMの最大メモリ量(バイト数)。
Current Memory JavaVMの総メモリ量(バイト数)
Peak Memory JavaVMのメモリ最大使用量(バイト数)
確認方法

採取された情報は、以下の操作で確認できます。

統合運用管理ツールで確認する場合:

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[JMSサービス]-<コネクション一覧の取得>

運用管理コマンドで確認する場合:

otxadmin> list-jms-connections

【備考】

2.4.4.2. JMSクライアント側での情報採取

JMSクライアント実行時にJavaシステムプロパティを設定することにより、メモリ状況や、フロー制御に関する項目をログ出力することが可能です。

コネクションファクトリのwojmsConsumerFlowLinit(滞留可能なメッセージ数の制限値)や、wojmsConsumerFlowThreshold(配信を再開するポイント)、 JMSクライアントのメモリサイズの決定には、ここで採取できる情報も参考になります。

設定方法

JMSクライアントのJavaシステムプロパティとして、以下の値を指定します。

表2.4.4.2-1
プロパティ 設定値
wojms.client.metrics true
wojms.client.metrics.interval 例) 10000
省略可能。デフォルト値は、5000(ミリ秒)。
wojms.client.metrics.log 例)C:\client.log
省略可能。ログファイル名を指定しない場合は、標準出力に表示。

プロパティの詳細については、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.2. JMS設定項目一覧 > 1.7.2.7. JMSのプロパティ/属性一覧 ] をご覧ください。

採取情報

ログに出力する情報は次のとおりです。

コンシューマレベルのフロー制御について

コンシューマレベルでは、コンシューマ単位に滞留可能なメッセージ数の制限値(wojmsConsumerFlowLimit)と、配信を再開するポイント(wojmsConsumerFlowThreshold)をコネクションファクトリに設定してフロー制御を行っています。

コンシューマレベルのフロー制御
図2.4.4.2-1


クライアントへ送信されたJMSメッセージ数が、wojmsConsumerFlowLimitに達すると、JMSサーバはメッセージの配信を停止し、未消費メッセージ数がwojmsConsumerFlowThreshold(%)を下回ると配信を再開します。 配信再開後、JMSサーバから送信されるメッセージ数は、「wojmsConsumerFlowLimit - (コンシューマで未消費のメッセージ数)」となります。

1つのコンシューマでは、最大、「Peak count of unprocessing」×(1メッセージのサイズ)のメモリが滞留メッセージによって消費されることになります。「Peak count of unprocessing」の値を参考に、コネクションファクトリのwojmsConsumerFlowLimitの値や、コンシューマ数、メモリサイズを調整します。

また、「Pause count」は、wojmsConsumerFlowLimitの値に達して停止した回数を示し、「Resume count」は、wojmsConsumerFlowThresholdを下回って、配信を再開する要求を行った回数になります。受信したメッセージ数と比較して、「Pause count」や、「Resume count」の値が大きい場合は、wojmsConsumerFlowLimitが小さすぎるか、wojmsConsumerFlowThresholdが大きすぎて、スループットを低下させている可能性があるため、これらの値を調整する目安とします。

【備考】
コネクションレベルのフロー制御について

コネクションレベルでは、同一コネクション上のすべてのコンシューマで滞留可能なメッセージ数の制限値(wojmsConnectionFlowLimit)をコネクションファクトリに設定してフロー制御を行います。 ただし、このフロー制御は、wojmsConnectionFlowLimitEnabledがtrueのとき行われ、デフォルトでは制御を行わない(false)設定になっています。

コンシューマ数が決まっていないような場合は、コネクションレベルでの制御が有効です。

コネクションレベルのフロー制御
図2.4.4.2-2


コネクション上のすべてのコンシューマの未消費メッセージがwojmsConnectionFlowLimitを超えると、合計数がコネクションの制限を下回るまで、コネクション経由のメッセージ配信を停止します。

コネクションレベルで制御を行っている場合は、1つのコネクションについて、最大、「Peak count of unprocessing」×(1メッセージのサイズ)のメモリが滞留メッセージによって消費されることになります。「Peak count of unprocessing」の値を参考に、メモリサイズの調整を行ってください。

【備考】

2.5. Transactionサービス

Transactionサービスのチューニングについて説明します。

以降の説明で、「設定方法」には、設定対象となる統合運用管理ツール上の項目名や、MOの属性名を記述しています。設定方法の詳細については、 マニュアル [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ] を参照してください。

2.5.1. トランザクションタイムアウト時間について

ここではトランザクションタイムアウト時間とObject Brokerのリクエスト呼び出しのタイムアウト時間の関係について、トランザクション実行中にサーバアプリケーションを呼び出さない場合とトランザクション実行中にサーバアプリケーションを呼び出す場合で分けて説明します。

なお、データベース等のリソースのタイムアウト設定はトランザクションタイムアウト時間を元にTransactionサービスで適宜変更しているので調整の必要はありません。

「トランザクションタイムアウト時間」

トランザクションを開始してから一定時間が経過してもコミットやロールバックなどの完了処理が発行されない場合に、自動的にトランザクションをロールバックするまでの時間です。Transactionサービスの機能であり、統合運用管理ツールなどで設定することができます。


「Object Brokerのリクエスト呼び出しのタイムアウト時間」

クライアントアプリケーションからサーバアプリケーションに対して処理要求を行う際に、Object Brokerが基盤となって橋渡しを行います。クライアントアプリケーションでは、この処理要求が一定時間経過しても戻ってこない場合に要求が失敗したとみなしてエラーとする機能を提供しています。この一定時間のことを「Object Brokerのリクエスト呼び出しのタイムアウト時間」と呼び、統合運用管理ツールなどで設定することができます。詳細は次のマニュアルを参照してください。「リファレンス集 運用管理・設定編」-「1.10. Object Broker

設定方法

サーバアプリケーションでトランザクションを開始し、統合運用管理ツールで設定する場合:

[WebOTX[<ホスト名>]]-[<ドメイン名>]-[server]-[transactionservice]-[TM設定]-[トランザクションタイムアウト時間]

サーバアプリケーションでトランザクションを開始し、運用管理コマンドで設定する場合:

otxadmin> set server.transactionservice.tx-timeout=600(秒)

クライアントアプリケーションでトランザクションを開始する場合:

Javaクライアントでは以下の形式でシステムプロパティを指定します。
-DTxTimeout=<トランザクションタイムアウト時間(秒)>

2.5.2. トランザクション高速化設定

JDBCコネクションとEJBインスタンスの関連付け機能の無効化

EJBを利用する場合、トランザクションの開始(begin())の前に取得したJDBCコネクションをそのトランザクションに参加させることができます。 これは、EJBインスタンスとJDBCコネクションの関連付けを行っているためです。そうした制御を行う必要がない場合には、該当機能を無効に することで、トランザクションの実行性能を向上させることができます。

具体的には以下のようなケースで高速化が可能です。

トランザクションの高速化は、${INSTANCE_ROOT}/config/TS/jta.confに以下を追加したあとドメイン再起動することにより行なうことができます。
wojta.enlistPrecreatedConnection=false

2.6. Webサービス

Webサービスのチューニングについて説明します。

2.6.1. SOAP通信高速化設定

JAX-PRCを利用したWebサービスでは、高速なXMLパーサを利用することができます。高速なXMLパーサを有効にするにはWebサービスを実行するドメインの起動オプションに設定を追加します。この設定により、SOAPメッセージのxml階層が深いパターン等で高速化の効果が期待できますが、最終的には必ずご自身の作成したアプリケーションを用いてこの設定の有無を変えてパフォーマンスを測定し、安定して高いパフォーマンスが得られる設定を採用してください。なお、この設定を行うとUTF-8のSOAPメッセージしか扱うことができないなどの[制限事項]がありますので、注意してください。

Express/Standard以上かつスタンダードモードの場合 EXPSTDENT StdM

SOAP通信高速化設定は、運用管理コマンド(otxadmin)を使い、次のように設定します。
   ※ 設定を有効にするにはドメインの再起動が必要です。

otxadmin> login --user admin --password ***** --port 6212 (これはログインの例です)
otxadmin> create-jvm-options -Dwoparser=true

この設定を無効化するには、運用管理コマンド(otxadmin)を使い、次のように設定します。
   ※ 設定を有効にするにはドメインの再起動が必要です。

otxadmin> login --user admin --password ***** --port 6212 (これはログインの例です)
otxadmin> delete-jvm-options -Dwoparser=true

(*)SOAP通信高速化オプションを設定しない場合、UTF-8、UTF-16を扱うことができます。

Standard以上かつアドバンスドモードの場合 STDENT AdvM

SOAP通信高速化設定は、運用管理コマンド(otxadmin)を使い、次のように設定します。

otxadmin> login --user admin --password ***** --port 6212 (これはログインの例です)
otxadmin> stop-apg [アプリケーショングループ名]
otxadmin> add-pg-javasystem-property --apgroup [アプリケーショングループ名] --javasystemprop woparser --value true [プロセスグループ名]
otxadmin> start-apg [アプリケーショングループ名]

この設定を無効化するには、運用管理コマンド(otxadmin)を使い、次のように設定します。

otxadmin> login --user admin --password ***** --port 6212 (これはログインの例です)
otxadmin> stop-apg [アプリケーショングループ名]
otxadmin> delete-pg-javasystem-property --apgroup [アプリケーショングループ名] --javasystemprop woparser [プロセスグループ名]
otxadmin> start-apg [アプリケーショングループ名]

(*)SOAP通信高速化オプションを設定しない場合、UTF-8、UTF-16を扱うことができます。

2.6.2. タイムアウトの設定

Webサービスクライアントでは、実行時に次のシステムプロパティを設定することで、Webサービスとの通信タイムアウトを制御することができます。

2.6.2.1. JAX-WS用のJavaシステムプロパティ

表2.6.2.1-1
プロパティ名 説 明 既定値
com.nec.webotx.webservice.xml.ws.connect.timeout 接続完了を待ち合わせる時間を設定します 30000[ms]
com.nec.webotx.webservice.xml.ws.request.timeout 応答を待ち合わせる時間を設定します 300000[ms]

2.6.2.2. JAX-RPC用のJavaシステムプロパティ

表2.6.2.2-1
プロパティ名 説 明 既定値
com.nec.webotx.webservice.http.connect.timeout 接続完了を待ち合わせる時間を設定します なし
com.nec.webotx.webservice.http.read.timeout 応答を待ち合わせる時間を設定します なし

2.6.2.3. SAAJ用のJavaシステムプロパティ

表2.6.2.3-1
プロパティ名 説 明 既定値
com.nec.webotx.webservice.xml.messaging.saaj.connect.timeout 接続完了を待ち合わせる時間を設定します 30000[ms]
com.nec.webotx.webservice.xml.messaging.saaj.request.timeout 応答を待ち合わせる時間を設定します 300000[ms]

 

設定方法

エージェントプロセスで動作する場合EXP STDENT StdM

otxadmin> create-jvm-options -Dプロパティ名=タイムアウト値

設定を無効化するには、次のコマンドを実行します。

otxadmin> delete-jvm-options -Dプロパティ名=タイムアウト値

Standard/Enterpriseのプロセスグループで動作する場合 STDENT AdvM

otxadmin> add-pg-javasystem-property --apgroup アプリケーショングループ名 --javasystemprop プロパティ名 --value タイムアウト値 プロセスグループ名

設定を無効化するには、次のコマンドを実行します。

otxadmin> delete-pg-javasystem-property --apgroup アプリケーショングループ名 --javasystemprop プロパティ名 プロセスグループ名
実行例

エージェントプロセス上にJAX-WSの接続タイムアウト時間を20秒で設定する場合

otxadmin> create-jvm-options -Dcom.nec.webotx.webservice.xml.ws.connect.timeout=20000

2.7. JDBCデータソース

JDBCデータソースのチューニングについて説明します。ここでは、主に、コネクションプール数に関するチューニングポイントについて説明しています。

以降の説明で、「設定方法」には、設定対象となる統合運用管理ツール上の項目名や、MOの属性名を記述しています。設定方法の詳細については、 マニュアル [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.8. JDBCデータソース > 1.8.1. JDBCデータソース設定項目・設定方法 ] を参照してください。

2.7.1. コネクションプール数の設定

コネクションプール数の設定について説明します。

2.7.1.1. 最小プールサイズの設定

アプリケーションの性能に大きな影響があるため、最小プールサイズを適切にチューニングすることが重要です。

最小プールサイズ[minPoolSize]にはデフォルトで4が設定されています。最小プールサイズに、アプリケーションの動作スレッド数と同じ値を設定すると、最も高い性能を得ることができますが、 反面、多くのコネクションやメモリなどの資源が必要となります。このため、一般的には、データベースサーバ側の接続数の制限に合わせてコネクションプール数のチューニングを行います。

最小プールサイズには、システム内で使用される全コネクション数がデータベースサーバ側の接続数の制限を越えない範囲で、アプリケーションの動作スレッド数か、それより小さい値を設定してください。 コネクションプールは、アプリケーションプロセス毎に、JDBCデータソースの定義数分存在します。それらのコネクションプールの最小プール数を合計し、運用管理操作で必要となるコネクション数などを考慮した上で、 最小プールサイズ、または、データベースサーバ側の接続数の制限値を調整してください。

最小プールサイズを超えて払い出されたコネクションは、アプリケーションが使い終わった後で破棄されます。その際、アプリケーションが使い終わった直後にコネクションが破棄されると、負荷が高い場合に、 コネクションの接続および切断を繰り返すことで性能が極端に低下することが懸念されます。そのための対策として、コネクション解放の待ち合わせ時間[shrinkDelayTime]のデフォルト値が15秒に設定されています。 それでもなお、度々コネクションの接続および切断が繰り返される状況になる場合は、コネクション解放の待ち合わせ時間を長くすることで性能を改善できます。

確認方法

アプリケーションの動作スレッド数は、最小プールサイズに設定する最大値です。その値と、負荷をかけた際の次の統計情報(使用中コネクションの最大数)の値を照らし合わせて、 最終的に最小プールサイズに設定すべき値を決定してください。

統合運用管理ツールで確認する場合:

エージェントプロセスで動作する場合

 [WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[統計情報]-[<ドメイン名>]-[アプリケーションサーバ]-[リソース]-[jdbc-datasource.JDBCデータソース名]-[プール中のコネクション数]-[NumConnUsed]-[使用中コネクション数の最大値]

Standard/Enterprise のプロセスグループで動作する場合

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[統計情報]-[<ドメイン名>]-[TPシステム]-[アプリケーショングループ]-[アプリケーショングループ名]-[プロセスグループ]-[プロセスグループ名]-[process]-[プロセスID]-[リソース]-[jdbc-datasource.JDBCデータソース名]-[プール中のコネクション数]-[NumConnUsed]-[使用中コネクション数の最大値]

運用管理コマンドで確認する場合:

エージェントプロセスで動作する場合

otxadmin> get --monitor *.*.jdbc-datasource*.NumConnUsed-HighWaterMark

Standard/Enterprise のプロセスグループで動作する場合

otxadmin> get --monitor tpsystem.*.*.*.*.*.*.jdbc-datasource*.NumConnUsed-HighWaterMark

統計情報は、JDBCデータソースの統計情報の採取レベルをLOWに設定した上で、JDBCデータソースから最初にコネクション取得を行った際に表示されます。採取レベルの変更方法は次のとおりです。

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[アプリケーションサーバ]-[モニタリングサービス]-[モジュールモニタリングレベル]-[jdbc datasourceモニタリングレベル]

運用管理コマンドで設定する場合:

otxadmin> set server.monitoring-service.module-monitoring-levels.jdbc-datasource=LOW
設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[コネクションプール]-[最小プールサイズ]

[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[コネクションプール]-[コネクション解放までの待ち時間]

運用管理コマンドで設定する場合:

otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.minPoolSize=10
otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.shrinkDelayTime=60

2.7.1.2. 初期プールサイズの設定

初期プールサイズ[initialPoolSize]に0が設定されている場合、アプリケーションがコネクションを取得する際に、必要に応じて接続されます。このため、業務の運用開始直後は、コネクションの接続を行う分、業務の性能が悪くなります。

EJBアプリケーションやWebアプリケーションでは、初期プールサイズで指定された数のコネクションが、アプリケーションプロセス起動時に予め接続されていますので、業務の運用開始直後の性能劣化を防ぐことができます。

初期プールサイズには、最小プールサイズで指定された数以下の値を指定してください。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[コネクションプール]-[初期プールサイズ]

運用管理コマンドで設定する場合:

otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.initialPoolSize=4

2.7.1.3. 最大プールサイズの設定

特定のアプリケーションプロセスで、極端に多くのコネクションを取得してしまうと、他のアプリケーションプロセスでデータベースに 接続できなくなってしまう恐れがあります。このような状況を防止するための対策としては、最大プールサイズの設定が有効です。
最大プールサイズ[maxPoolSize]には、最小プールサイズよりも大きく、データベースサーバ側の最大接続数よりも小さい値を設定してください。
また、データベースサーバの状態監視オプション[checkServerOption]に「定期的にデータベースサーバの状態を確認[monitor]」を指定し、 データベースサーバの監視コマンド[checkServerCommand]にconnect以外を指定する場合は、アプリケーションで使用するJDBCコネ クション数にデータベースサーバを監視するための接続(1本)を加えた値を設定してください。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[コネクションプール]-[最大プールサイズ]

運用管理コマンドで設定する場合:

otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.maxPoolSize=10

2.7.2. その他の設定

その他の設定について説明します。

2.7.2.1. ステートメントの最大プール数の設定

JDBCドライバでステートメントプール機能をサポートしている場合、その機能を利用することで、ステートメントの生成コスト分の性能を改善することができます。

JDBCデータソースがサポートするJDBCドライバの中では、OracleとSequeLinkのJDBCドライバで、ステートメントプール機能をサポートしています。

ステートメントプール機能では、文字列化されたSQL命令をキーにしてステートメントの検索が行われます。このため、文字列化されたSQL命令に、可変の値が含まれないjava.sql.preparedStatementを利用し、 検索効率を高めることが重要です。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、反映ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[コネクションプール]-[ステートメントの最大プール数]

運用管理コマンドで設定する場合:

otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.maxStatements=20

2.7.2.2. テンプレートによるカスタマイズの設定

JDBCデータソースの登録および更新時に、カスタマイズテンプレート[customizeTemplate]を選択することで性能や信頼性に関わる複数の属性を一括で推奨値にできます。次のテンプレートを選択可能です。

表2.7.2.2-1
テンプレート 説 明
性能重視でカスタマイズ
(Performance)
性能を向上させるためにデータソースをカスタマイズします。
信頼性重視でカスタマイズ
(Reliability)
信頼性を向上させるためにデータソースをカスタマイズします。
性能と信頼性重視でカスタマイズ
(PerformanceAndReliability)
性能と信頼性を向上させるためにデータソースをカスタマイズします。
カスタマイズなし
(none)
性能と信頼性観点でのカスタマイズを行いません。

JDBCデータソースの性能向上や信頼性に関する属性のデフォルトカスタマイズ値は以下の表に示します。

表2.7.2.2-2
属性名 カスタマイズ値 設定値の根拠 性能向上/信頼性
maxPoolSize 20 スレッド数のデフォルト値です。 性能向上
minPoolSize 20 スレッド数のデフォルト値です。
initialPoolSize 5 プロセスグループのスレッド数のデフォルト値(1〜3)に近い値で、初期接続による性能改善効果が得られる値です。
shrinkDelayTime 60 デフォルト値の15秒を大きく上回り、性能改善効果が高い時間です。(単位:秒)
waitFreeConnTimeout 20 高負荷時に誤動作しにくく、リトライを行ってもCORBAのリクエストタイムアウトが発生しにくい間隔です。(単位:秒)
maxStatements 20 性能改善効果があり、カーソル数の最大数超過となりにくい値です。
connectRetryMax 1 計画停止等でエラーを復旧できる回数です。 信頼性
connectRetryInterval 10 1回リトライを行ってもCORBAのリクエストタイムアウトが発生しにくい間隔です。(単位:秒)
checkServerOption monitor 負荷に影響が少ない方のオプションです。
checkServerInterval 60 負荷をなるべく抑えつつ、デフォルト値の180秒より短時間に障害を検出できる間隔です。(単位:秒)
checkServerCommand connect 障害検出までの時間が短いコマンドです。
queryTimeout 300 トランザクションのタイムアウト時間のデフォルト値の範囲内で十分長い時間です。(単位:秒)
readTimeout 315 queryTimeoutプラスアルファの時間です。(単位:秒)
loginTimeout 15 1回リトライを行ってもCORBAのリクエストタイムアウトが発生しにくい間隔です。(単位:秒)

テンプレートの内容は、次のファイルに格納されています。これらの内容を修正することによって、カスタマイズすることができます。

表2.7.2.2-3
テンプレート テンプレートファイル名
性能重視でカスタマイズ
(Performance)
createJdbcDataSourceGUI;in_customizeTemplate;Performance.xml
信頼性重視でカスタマイズ
(Reliability)
createJdbcDataSourceGUI;in_customizeTemplate;Reliability.xml
性能と信頼性重視でカスタマイズ
(PerformanceAndReliability)
createJdbcDataSourceGUI;in_customizeTemplate;PerformanceAndReliability.xml

格納ディレクトリ:
            ${INSTALL_ROOT}/lib/dynamic-change/
            ${INSTANCE_ROOT}/config/dynamic-change/

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更します。カスタマイズの更新後に再表示の操作を行ってください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[カスタマイズ]-[カスタマイズテンプレート]

運用管理コマンドで設定する場合:

otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.customizeTemplate=Performance

2.7.2.3. トランザクションで使用する物理コネクション数に関する設定

JTAのトランザクション制御を行う場合、JTAのトランザクション毎に1つの物理コネクションを使用するかどうか[useOneConnectionPerTransaction] にtrueを設定することで、一部のトランザクション制御のシーケンスが省略され、性能が改善される可能性があります。

データソース種別[dataSourceType]がDB2のOptional Package API[JDBCEX_DB2]やPostgreSQLのOptional Package API[JDBCEX_PostgreSQL]、JDBC API[JDBC]の場合、 JTAのトランザクション毎に1つの物理コネクションを使用するかどうか[useOneConnectionPerTransaction]の設定に関わらずtrueの場合の動作になります。 それ以外の場合で、JTAのトランザクション内で、同一データベースに対する複数のJDBCコネクションを同時に利用する場合に性能が改善します。また、EJBから 別のEJBを呼び出す場合の性能が改善されることがあります。

プログラミング方法の制約等については、 マニュアル [ アプリケーション開発ガイド(共通) > 3. JDBCアプリケーションの開発 > 3.1. プログラミング・開発ガイド > 3.1.5. JTAのトランザクションで、同時に複数のJDBCコネクションを利用する方法 ] を参照してください。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、反映ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[<ドメイン名>]-[リソース]-[jdbcデータソース]-[JDBCデータソース名]-[拡張]-[JTAのトランザクション毎に1つの物理コネクションを使用するかどうか]

運用管理コマンドで設定する場合:

otxadmin> set server.resources.jdbc-datasource.<JDBCデータソース名>.useOneConnectionPerTransaction=true

2.8. EJBコンテナ

ExpressおよびStandard/EnterpriseにおけるEJBコンテナのチューニング方法に関して説明します。

2.8.1. EJB種類別のチューニング

EJBには、ステートフルセッションBean、ステートレスセッションBean、エンティティBean、メッセージドリブンBeanの4種類があり、用途に応じて使い分けられます。

2.8.1.1. ステートレスセッションBeanのチューニング

ステートレスセッションBeanは名前のとおり状態(ステート)を持ちません。そのため事前にインスタンスを生成し、プールしておくことが可能です。インスタンス生成はCPUリソースを消費し、 時間がかかりますので、運用中のインスタンス生成を避けるために事前生成とプーリングが行われます。

また複数クライアントから同時に呼び出しが行われることを想定して、複数のインスタンスをプールしておくことも可能です。プールするインスタンス数を増やすと、プール数に比例してメモリを消費します。

ステートレスセッションBeanのチューニングはインスタンスプールのプール数の調整によって行われます。これはエディションによって設定項目が変わります。

Standard/Enterpriseの場合

リモートインタフェースを使用した場合、プールするインスタンス数はプロセスグループのスレッド数と同じ値になります。 [2.1. APサーバ > 2.1.3. 性能チューニング > 2.1.3.1. 多重度のチューニング ] を参考にスレッド数を設定してください。

配備されたアプリケーション単位でプールするインスタンス数を調整することも可能です。以下のどちらかの方法により0〜スレッド数の間で設定してください。

ローカルインタフェースを使用した場合、プールするインスタンス数はEJBコンテナの設定項目である「通常プールサイズ」で設定されます。既定値では「通常プールサイズ」は0になっています。インスタンス事前生成機能を有効にするには、「通常プールサイズ」を1以上にしてください。
設定方法は、次の「Expressの場合」を参照してください。

Expressの場合

プールするインスタンス数はEJBコンテナの設定項目である「通常プールサイズ」で設定されます。既定値では「通常プールサイズ」は0になっています。インスタンス事前生成機能を有効にするには、「通常プールサイズ」を1以上にしてください。

2.8.1.2. ステートフルセッションBeanのチューニング

ステートフルセッションBeanは状態を持ちますので事前生成は行えません。クライアントからステートフルセッションBeanが利用される時、必ずインスタンス生成/破棄が行われます。状態が必要ないアプリケーションの場合、ステートレスセッションBeanで設計し、事前生成・プーリング機能を有効にした方が実行性能は良くなります。

ステートフルセッションBeanではプールの代わりにキャッシュが使われます。メモリ上に作られ、破棄されていないインスタンスが長時間アクセスされない場合、状態がファイルにキャッシュされます。頻繁にキャッシングが行われる場合、アプリケーションの問題(クライアントからbeanのremove()メソッドが呼ばれていない)もしくはインスタンスのタイムアウト設定時間が短すぎることが考えられます。インスタンスのタイムアウト設定時間は次のように設定します。

2.8.1.3. エンティティBeanのチューニング

エンティティBeanはプールとキャッシュ両方を利用します。プーリングについては [ 2.8. EJBコンテナ > 2.8.1. EJB種類別のチューニング > 2.8.1.1. ステートレスセッションBeanのチューニング ] 、 キャッシングについては [ 2.8. EJBコンテナ > 2.8.1. EJB種類別のチューニング > 2.8.1.2. ステートフルセッションBeanのチューニング ] を参照してください。

2.8.1.4. メッセージドリブンBeanのチューニング

ステートレスセッションBeanと同様に事前生成・プーリングが行われます。 [ 2.8. EJBコンテナ > 2.8.1. EJB種類別のチューニング > 2.8.1.1. ステートレスセッションBeanのチューニング ] を参照してください。ただしExpressでの通常プールサイズの設定はEJBコンテナではなく、独自のMDBコンテナの設定に拠ります。

2.8.2. EJBメソッド呼び出しのパフォーマンスの改善

EJBのリモートメソッド呼び出しの際に、パフォーマンス劣化が発生する場合があります。 典型的な例では、EJBのリモートメソッドのメソッド引数やメソッド戻り値を、CollectionインタフェースやMapインタフェースの実装クラス にした場合が挙げられます。このパフォーマンス劣化の度合は、引数や戻り値オブジェクトの要素数に比例します。

引数や戻り値に独自に定義したクラスを使った場合でも、参照するオブジェクトが多いクラスや参照のネストが深くなるクラスでは、同様にパフォーマンスが劣化します。

これは、リモートインタフェースを使用したEJBでは、既定ではオブジェクトが値渡し(call by value)されるからです。値渡しをするためには、 オブジェクトをコピーする必要がありますが、これはJavaのシリアライズ機構を用いたディープコピーになります。 オブジェクトの参照構造の末端までを辿って全てのオブジェクトをシリアライズする必要があるため、参照するオブジェクトが多いクラスや参照のネストが深くなるクラスは 処理量が増え、時間を消費することになります。

この問題に対処するために、WebOTXでは、引数および戻り値オブジェクトを参照渡し(call by reference)する仕組みが用意されています。 参照渡しを行えば、通常のJavaメソッド呼び出しと同じく、メソッドに渡されるのはオブジェクトのポインタになりますので、オブジェクトコピーのオーバーヘッドが発生しません。 参照渡しには、以下の2つの方法があります。どちらも呼び出し元と呼び出し先が同じプロセスで動作していることが必須条件です。

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

ローカルインタフェースを使用することにより、EJBメソッド呼び出しを参照渡しにすることが可能です。 ローカルインタフェースはEJB 2.0より定義されています。

同一プロセス内での呼び出しが発生する場合は、設計の段階でローカルインタフェースの採用を検討し、パフォーマンスの向上を図ることを推奨します。

2.8.2.2. call-by-reference

NEC固有配備記述子 nec-ejb-jar.xml の中で ejb 要素直下にpass-by-reference 要素を追加し、値を true に指定することにより、リモートインタフェースを使用したEJBに対しても 参照渡しをさせることができます。システム開発の後期でパフォーマンス問題が発生し、EJBのインタフェースの設計を変更できない場合に有効です。

ただし、ローカル呼び出しができていないとこれは機能しません。ローカル呼び出しの詳細については、 [ ドメイン構築・基本設定ガイド > 5. アプリケーション > 5.9. クラスローダ > 5.9.8. ライブラリの配置計画 ] を参照してください。

2.8.3. staticclassgenによるパフォーマンスの改善(EJB 3.0以上)

EJB 3.0以上を動作させるのに、アプリケーション開発者が作成しなければならないインタフェースは、ビジネスインタフェースのみです。 煩雑なリモートインタフェースとホームインタフェースは必須ではなくなりました。

しかしながら、内部的には、クライアントアプリケーションはEJBメソッド実行時、リモートインタフェースとホームインタフェースを必要とします。 そのため、既定ではクライアント側で、ビジネスインタフェース名での初回のlookup時(@EJBアノテーションを利用しているときは、DI解決時)に、 ビジネスインタフェースを元に動的にリモートインタフェースとホームインタフェースを生成します。 一度生成されたリモートインタフェースとホームインタフェースは、クライアントJavaプロセス内のメモリ中で保持されます。 よって、クライアントJavaプロセスからの2回目以降のビジネスインタフェース名でのlookupはEJB 2.1と同等の早さですが、初回lookupはEJB 2.1よりも遅くなります。

WebからEJBを呼び出したり、EJBからEJBを呼び出したりするアプリケーションでは、一般的にこの初回lookupのオーバーヘッドはあまり問題になりません。 Javaプロセスのライフタイムが長いからです。 問題となる場合があるのは、Javaプロセスのライフタイムが一般的に短い、アプリケーションクライアントです。

もし、EJB 3.0以上の初回呼び出しのオーバーヘッドが問題になる場合は、staticclassgenを用いて、静的にリモートインタフェースとホームインタフェースを生成し、 アプリケーションクライアントのクラスパスに追加してください。 [ 運用ツールガイド > 3. その他機能 > 3.3. staticclassgen ]

staticclassgenで静的生成されたクラスはビジネスインタフェースと同じクラスローダでロードされるように配置してください。 アプリケーションクライアントの場合、ビジネスインタフェースが-client引数で指定されたファイル内にあるなら、-appcpathで静的生成されたクラスを指定すると同じクラスローダでロードされます。 サーバ上で動作するアプリケーション(Webアプリケーション、EJBアプリケーション)のクラスローダについては、 [ ドメイン構築・基本設定ガイド > 5. アプリケーション > 5.9. クラスローダ ] を参照してください。 クラスローダが違う場合、lookupでjava.lang.NoClassDefFoundError(ビジネスインタフェースが静的生成クラスよりも下位のクラスローダにある場合)あるいはjava.lang.ClassCastException(ビジネスインタフェースが静的生成クラスよりも上位のクラスローダにある場合)が発生します。

2.9. 通信

ブラウザからWebサーバを経由しAPサーバにアクセスする場合の、WebOTX以外の通信に関するチューニングについて説明します。

2.9.1. TCP/IPに関する設定

全ての通信の基本であるOSのTCP/IPに関する設定について説明します。

概要

TCP/IPに関する最も重要な設定は、送信タイムアウト時間KeepAliveの設定です。例えば、通信相手のサーバマシンの電源が落ちて、TCP/IPの切断処理が行われないままとなった場合、 クライアントでは、送信タイムアウト時間KeepAliveのどちらかの設定によって障害が検出されるまで、通信できない状態になります。

大抵の場合、送信タイムアウト時間の設定によって、長くて10分程度で障害を検出することができます。ただ、稀に受信待ちとなった場合には、 KeepAliveのOSのデフォルト設定で約2時間障害を検出できません。

KeepAliveの設定は、サーバ側で無効なコネクションを破棄するために利用することがより一般的です。

システムの障害復旧時間の要件に応じて、これらの設定のチューニングを行ってください。

OSの設定方法

設定内容や設定方法は、次に示すとおり、OS毎に異なります。詳細については、各OSのリファレンスをご覧ください。

HP-UXの場合)

/etc/rc.config.d/nddconf に次のように設定します。

送信タイムアウト時間(データ送信時):

  TRANSPORT_NAME[num]=tcp

  NDD_NAME[num]=tcp_ip_abort_interval

  NDD_VALUE[num]=600000

送信タイムアウト時間(接続要求時):

  TRANSPORT_NAME[num]=tcp

  NDD_NAME[num]=tcp_ip_abort_cinterval

  NDD_VALUE[num]=75000 

KeepAlive:

  次のデフォルトの設定では、tcp_ip_abort_intervalの値を加えた2時間10分で障害を検出します。

  TRANSPORT_NAME[num]=tcp

  NDD_NAME[num]=tcp_keepalive_interval

  NDD_VALUE[num]=7200000

Linuxの場合)

/etc/sysctl.conf に次のように設定します。

送信タイムアウト時間(データ送信時):

  次のデフォルトの設定では、13〜30分で障害を検出します。

  net.ipv4.tcp_retries2 = 15 

送信タイムアウト時間(接続要求時):

  net.ipv4.tcp_syn_retries = 5 

KeepAlive:

  次のデフォルトの設定では、7200秒 + 75 x 9秒で、約2時間11分で障害を検出します。

  net.ipv4.tcp_keepalive_intvl = 75

  net.ipv4.tcp_keepalive_proves = 9

  net.ipv4.tcp_keepalive_time = 7200

Solarisの場合)

/etc/system に次のように設定します。

送信タイムアウト時間(データ送信時):

  set tcp:tcp_ip_abort_interval = 480000

送信タイムアウト時間(接続要求時):

  set tcp:tcp_ip_abort_cinterval = 180000

KeepAlive:

  次のデフォルトの設定では、tcp_ip_abort_intervalを加えた2時間8分で障害を検出します。

  set tcp:tcp_ip_keepalive_interval = 7200000

Windowsの場合)

レジストリHKEY_LOCAL_MACHINE\System\CurrentControlSet\services\Tcpip\Parametersキーの値を次のように設定します。

送信タイムアウト時間(データ送信時):

次の設定では、アダプタ毎のレジストリ値TcpInitialRTTの値が3000ミリ秒である場合、

3 + (3 x 2) + (6 x 2) + (12 x 2) + (24 x 2)秒で、約93秒で障害を検出します(リトライする度に、リトライの間隔が直前の間隔の2倍になります)。

TcpMaxDataRetransmissions REG_DWORD 5

送信タイムアウト時間(接続要求時):

次の設定では、アダプタ毎のレジストリ値TcpInitialRTTの値が3000ミリ秒である場合、

3 + (3 x 2) + (6 x 2)秒で、約21秒で障害を検出します(リトライする度に、リトライの間隔が直前の間隔の2倍になります)。

TcpMaxConnectRetransmissions

REG_DWORD

3

KeepAlive:

  次のデフォルトの設定では、7200秒 + 5x1000ミリ秒で、約2時間で障害を検出します。

KeepAliveTime

REG_DWORD

7200000

KeepAliveInterval

REG_DWORD

1000

TcpMaxDataRetransmissions

REG_DWORD

5

次のレジストリ値TcpInitialRTTは、設定場所やデフォルト値がOS毎に異なります。

デフォルト値についてはOS毎に確認して頂く必要がありますが、TcpMaxConnectRetransmissionsやTcpMaxDataRetransmissionsといった再送回数のチューニングだけを行うようにすれば、 設定場所まで意識する必要はありません。

TcpInitialRTT

REG_DWORD

3000

KeepAliveを有効にするための設定

WebOTXでは、デフォルトの設定でKeepAliveの動作が有効になります。このため、設定変更を行う必要はありません。ここでは、WebOTXで利用することが多いOracleクライアントでの設定方法について説明します。 詳細については、Oracleのリファレンスを参照してください。

Oracle thinドライバでKeepAliveを有効にするための設定

JDBCデータソースのデータソース名[dataSourceName]に設定する接続文字列として、次の形式(例)で設定してください。

"jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.xxx)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCL))(ENABLE=BROKEN))"

Oracle OCIドライバおよびC++アプリケーションでKeepAliveを有効にするための設定

Oracle Net Serviceの tnsnames.oraファイルに、次の形式(例)で設定してください。

ORCL = (DESCRIPTION= (ADDRESS=(PROTOCOL=TCP)(HOST=xxx.xxx.xxx.xxx)(PORT=1521))(CONNECT_DATA= (SERVICE_NAME=ORCL))(ENABLE=BROKEN))

(*)Windowsの初期値はOSにより様々です。OSのリファレンスやホームページで確認してください。

2.9.2. クライアント(Web ブラウザ)に関する設定

Web ブラウザからリクエストを送信後、応答までのタイムアウト値を設定します。本設定は通常ブラウザ側で行います。使用するブラウザにより、設定箇所が異なります。詳細は各ブラウザのマニュアルを参照してください。

Internet Explorer を使用した場合、以下のレジストリキーに対しReceiveTimeout という DWORD 値を追加して、値の データを <秒数>*1000 に設定します。Internet Explorer 7 の場合、タイムアウト時間は 60分です。

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

2.10. Working Domain Coordinator

ワーキングドメインコーディネータのチューニングについて説明します。

2.10.1. ビジネスロジックグループのプライオリティに関する設定

業務アプリケーション毎に優先度を設定することで、ドメイン切り替え発生時に停止対象に選択されるかどうかを調整することができます。

複数の業務アプリケーションがある場合

複数のビジネスロジックグループのプライオリティに異なる値を設定しておくことで、ドメインの切り替え発生時、最も優先度が低い業務アプリケーション(ビジネスロジックグループ)が稼動している ドメインが停止の対象となります。

停止できないの業務アプリケーションがある場合

停止できない、優先度の高い業務アプリケーションがある場合、対象のビジネスロジックグループのプライオリティに最高値の5を設定することで、その業務アプリケーションが稼動しているドメインを停止の対象からはずすことができます。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[cluster]-[アプリケーションサーバ]-[ワーキングドメインコーディネータ]-[ビジネスロジックグループ]-[<設定対象のビジネスロジックグループ名>]-[優先度]

運用管理コマンドで設定する場合:

otxadmin> set server.workingDomainCoordinator.businessLogicGroups.<group-name>.priority=5

group-nameには、設定対象のビジネスロジックグループ名を指定します。

2.10.2. ドメイン切り替えの発生頻度を下げる設定

高負荷が発生する状況でもドメインの切り替えを頻発させたくない場合、次の方法でドメイン切り替えの発生頻度を下げて業務にかかる負荷を下げることができます。

(1)定期監視間隔を長く設定する

Working Domain Coordinator は、通常時、一定間隔で負荷監視対象の業務アプリケーションが稼動するプロセスグループのキュー滞留数を監視します。この定期監視間隔は、既定値600秒ですが、これをより長く設定することにより、ドメイン切り替えの発生頻度を下げて業務にかかる負荷を下げることが可能です。

対象業務のビジネスロジックグループの属性 定期監視間隔を、長く設定してください。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[cluster]-[アプリケーションサーバ]-[ワーキングドメインコーディネータ]-[ビジネスロジックグループ]-[<設定対象のビジネスロジックグループ名>]-[定期監視間隔]

運用管理コマンドで設定する場合:

otxadmin> set server.workingDomainCoordinator.businessLogicGroups.<group-name>.observationInterval=1200

group-nameには、設定対象のビジネスロジックグループ名を指定します。

(2)最低稼動時間を長く設定する

ビジネスロジックグループごとに、その業務が稼動するドメインの最低稼働時間を指定することができます。(既定値3600秒)ドメインの稼働時間がこの値を超えない場合、切り替えは行いません。(該当ドメインを停止しません。)この最低稼動時間をより長く設定することにより、ドメイン切り替えの発生頻度を下げることが可能です。

対象業務のビジネスロジックグループの属性 最低稼働時間を、長く設定してください。

設定方法

統合運用管理ツールで設定する場合:

次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[cluster]-[アプリケーションサーバ]-[ワーキングドメインコーディネータ]-[ビジネスロジックグループ]-[<設定対象のビジネスロジックグループ名>]-[最低稼動時間]

運用管理コマンドで設定する場合:

otxadmin> set server.workingDomainCoordinator.businessLogicGroups.<group-name>.warmingUpTimeToSwitch=7200

group-nameには、設定対象のビジネスロジックグループ名を指定します。

2.11. チューニング補助機能

[2. チューニング]の各章に記載されているように、WebOTX Application Serverの属性には、性能を最大限に生かすため他の属性との間に特定の条件式を満たすことが推奨されるものがあります。以下、その条件のことを推奨条件と記載します。チューニング補助機能は、それらの属性値が変更された際に、推奨条件を満たしているかどうかを判定し、併せて変更すべき属性値を通知します。

チューニング補助機能を利用するには以下の方法があります。
[2.11.1. setコマンドのcheckオプションを利用 ]

チューニング補助機能が判定する推奨条件、及び対象となる属性は以下に記載しています。
[2.11.2. 推奨条件・機能の対象となる属性 ]

2.11.1. setコマンドのcheckオプションを利用

運用管理サブコマンドのsetコマンドを使用して属性値を変更する際、checkオプションをつけて実行すると、オペランドに指定した属性値と他の属性との間に推奨条件があるか否かを調査し、結果を表示します。オペランドに指定した属性が推奨条件を持つ場合は、その条件を満たしているかどうか判断し、結果を表示します。

otxadmin> set --check=true server.web-container.plugin-config.plugin-pool-size=10
この属性に関連する属性がありますが、すべて推奨条件を満たしています。
詳細を表示するには、detailオプションをつけて再度実行してください。
setコマンドを実行します。
server.web-container.plugin-config.plugin-pool-size = 10
checkオプションと併用するオプション

checkオプションと共にdetailオプションとcancelableオプションを使用することで、推奨条件の判定結果をより詳細に表示する、推奨条件を満たしていない場合にsetコマンドを中止することができます。各オプションの詳細は以下の通りです。

detailオプションとの併用

detailオプションをtrueにすると、運用管理コマンドを実行した際に、より詳細な情報をコマンドの戻り値に表示することができます。既定値はfalseです。

otxadmin> set --check=true --detail=true --cancelable=true server.web-container.plugin-config.plugin-pool-size=250
OTX01080005: この属性に関連する属性がありますが、すべて推奨条件を満たしています 。
推奨条件: server.web-container.plugin-config.plugin-pool-size <= server.WebServer.MaxClients
OK: server.WebServer.MaxClients = 250
オペランドに指定した属性を変更します。
server.web-container.plugin-config.plugin-pool-size = 250

通常表示される情報は次の通りです。

detail オプション付加時に追加される情報は次の通りです。


cancelableオプションとの併用

cancelableオプションをtrueにすると、推奨条件を判定した結果がNGとなった場合に、オペランドに指定した属性値の変更を中止します。推奨条件の判定結果がOKの場合は属性値を変更します。既定値はfalseです。

otxadmin> set --check=true --detail=true --cancelable=true server.web-container.plugin-config.plugin-pool-size=300
OTX01080003: この属性に関連する属性の中に、推奨条件を満たさない属性があります。
推奨条件: server.web-container.plugin-config.plugin-pool-size <= server.WebServer.MaxClients
NG: server.WebServer.MaxClients = 250
属性値を変更するためには以下のコマンドを実行してください。 set server.WebServer.MaxClients=属性値
オペランドに指定した属性は変更しません。
Did not set the operand by cancelable option.

ログファイル

checkオプションにより判定された結果は${INSTANCE_ROOT}/logs/agent/webotx_related_attributes.logに保存されます。

保存される内容は以下の通りです。

detailオプション、cancelableオプションの引数に関わらず、上記のすべての内容が保存されます。

2.11.2. 推奨条件・機能の対象となる属性

機能の対象となる属性と条件は、OS、WebOTXのエディション、Webコンテナの動作モード、Webサーバの種類、リスナの種類により異なります。
OS毎の対象属性はこちらをご覧ください。

機能の対象となる属性と条件は、以下に記載された内容に基づいて、属性値が推奨条件を満たしているか判定します。チューニングの方針等はこちらをご覧ください。

2.11.2.1. Windows

Expressエディション
推奨条件一覧
表2.11.2.1-1 推奨条件一覧 Expressエディション
Webサーバ 推奨条件
WebOTX Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients
内蔵Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout


対象属性一覧
表2.11.2.1-2 対象属性一覧 Expressエディション
Webサーバ 対象属性
WebOTX Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
内蔵Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

各属性については以下をご覧ください。

Standardエディション ・ Enterpriseエディション
推奨条件一覧
表2.11.2.1-3 推奨条件一覧 Standardエディション ・ Enterpriseエディション
Webコンテナの動作モード Webサーバ リスナの種類 推奨条件
スタンダードモード WebOTX Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients

server.web-container.plugin-config.plugin-pool-size = server.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
アドバンストモード WebOTX Webサーバ AJPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients
tpsystem.AJPListener.simultaneousConnectionClients (※1)

tpsystem.applicationGroups.{1}.processGroups.{2}.processCount × tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount (※1)
IIOPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients

tpsystem.IIOPListener.multiplexprocess (※2)
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount × tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount (※2)

(※1)すべてのプロセスグループのprocessCount × threadCountを合計した値は、tpsystem.AJPListener.simultaneousConnectionClientsに関連しています。これらの属性値の大小関係についてはシステムの設計指針によって異なります。これらのうちのいずれかの属性値を変更した場合は、その他の(※1)の属性値もシステムの設計指針に沿っていることを確認してください。

(※2)すべてのプロセスグループのprocessCount × threadCountを合計した値は、tpsystem.IIOPListener.multiplexprocessに関連しています。これらの属性値の大小関係についてはシステムの設計指針によって異なります。これらのうちのいずれかの属性値を変更した場合は、その他の(※2)の属性値もシステムの設計指針に沿っていることを確認してください。

対象属性一覧
表2.11.2.1-4 対象属性一覧 Standardエディション ・ Enterpriseエディション
Webコンテナの動作モード Webサーバ リスナの種類 対象属性
スタンダードモード WebOTX Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
server.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
アドバンストモード WebOTX Webサーバ AJPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
tpsystem.AJPListener.simultaneousConnectionClients
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount
tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount
IIOPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
tpsystem.IIOPListener.multiplexprocess
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount
tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount

各属性については以下をご覧ください。

2.11.2.2. Unix

Expressエディション
推奨条件一覧
表2.11.2.2-1 推奨条件一覧 Expressエディション
Webサーバ 推奨条件
WebOTX Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients

server.WebServer.MaxClients ≤ httpd.confに設定されたServerLimit × httpd.confに設定されたThreadsPerChild
内蔵Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout


対象属性一覧
表2.11.2.2-2 対象属性一覧 Expressエディション
Webサーバ 対象属性
WebOTX Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
httpd.confに設定されたServerLimit
httpd.confに設定されたThreadsPerChild
内蔵Webサーバ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

各属性については以下をご覧ください。

Standardエディション ・ Enterpriseエディション
推奨条件一覧
表2.11.2.2-3 推奨条件一覧 Standardエディション ・ Enterpriseエディション
Webコンテナの動作モード Webサーバ リスナの種類 推奨条件
スタンダードモード WebOTX Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients

server.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size = server.web-container.plugin-config.plugin-pool-size

server.WebServer.MaxClients ≤ httpd.confに設定されたServerLimit × httpd.confに設定されたThreadsPerChild
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
アドバンストモード WebOTX Webサーバ AJPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients

tpsystem.AJPListener.simultaneousConnectionClients ≤ server.WebServer.MaxClients

server.WebServer.MaxClients ≤ httpd.confに設定されたServerLimit × httpd.confに設定されたThreadsPerChild

tpsystem.AJPListener.simultaneousConnectionClients (※3)
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount × tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount(※3)
IIOPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

server.WebServer.MaxClients ≤ httpd.confに設定されたServerLimit × httpd.confに設定されたThreadsPerChild

server.web-container.plugin-config.plugin-pool-size ≤ server.WebServer.MaxClients

tpsystem.IIOPListener.multiplexprocess × tpsystem.IIOPListener.simultaneousConnectionClient ≤ server.WebServer.MaxClients

tpsystem.IIOPListener.multiplexprocess (※4)
tpsystem.IIOPListener.simultaneousConnectionClient (※4)
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount × tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount (※4)
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.connectRetryInterval

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.loginTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.queryTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.readTimeout

server.resources.jdbc-datasource.{1}.connectRetryMax × server.resources.jdbc-datasource.{1}.connectRetryInterval < server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

(※3)すべてのプロセスグループのprocessCount × threadCountを合計した値は、tpsystem.AJPListener.simultaneousConnectionClientsに関連しています。これらの属性値の大小関係についてはシステムの設計指針によって異なります。これらのうちのいずれかの属性値を変更した場合は、その他の(※3)の属性値もシステムの設計指針に沿っていることを確認してください。

(※4)すべてのプロセスグループのprocessCount × threadCountを合計した値は、tpsystem.IIOPListener.simultaneousConnectionClientとtpsystem.IIOPListener.multiplexprocessに関連しています。これらの属性値の大小関係についてはシステムの設計指針によって異なります。これらのうちのいずれかの属性値を変更した場合は、その他の(※4)の属性値もシステムの設計指針に沿っていることを確認してください。

対象属性一覧
表2.11.2.2-4 対象属性一覧 Standardエディション ・ Enterpriseエディション
Webコンテナの動作モード Webサーバ リスナの種類 対象属性
スタンダードモード WebOTX Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
server.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size
httpd.confに設定されたServerLimit
httpd.confに設定されたThreadsPerChild
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
アドバンストモード WebOTX Webサーバ AJPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
tpsystem.AJPListener.simultaneousConnectionClients
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount
tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount
httpd.confに設定されたServerLimit
httpd.confに設定されたThreadsPerChild
IIOPリスナ server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout
server.WebServer.MaxClients
server.web-container.plugin-config.plugin-pool-size
tpsystem.IIOPListener.multiplexprocess
tpsystem.IIOPListener.simultaneousConnectionClient
tpsystem.applicationGroups.{1}.processGroups.{2}.processCount
tpsystem.applicationGroups.{1}.processGroups.{2}.threadCount
httpd.confに設定されたServerLimit
httpd.confに設定されたThreadsPerChild
内蔵Webサーバ なし server.resources.jdbc-datasource.{1}.connectRetryMax
server.resources.jdbc-datasource.{1}.connectRetryInterval
server.resources.jdbc-datasource.{1}.loginTimeout
server.resources.jdbc-datasource.{1}.queryTimeout
server.resources.jdbc-datasource.{1}.readTimeout
server.resources.jdbc-datasource.{1}.waitFreeConnTimeout

各属性については以下をご覧ください。

2.12. インメモリデータグリッド連携部品

インメモリデータグリッド連携部品のチューニングについて説明します。

2.12.1. データプリロードの対象エンティティの設定

より初回アクセス時の応答の性能を向上させるためには、 データプリロードの読み込み対象エンティティは、参照回数が多いエンティティを優先してください。
以下の手順で設定します。

(1)JPAの性能情報の採取

インメモリデータグリッド連携部品の性能情報機能を利用してJPAの性能情報を採取します。
性能情報採取の開始・停止の詳細は、 [ドメイン構築・基本設定ガイド > 7.9.3. 性能情報採取の開始・停止 ]を参照してください。

(2)JPAランキング情報の生成

JPAランキング情報生成コマンドで、採取したJPAの性能情報から、JPAランキング情報を生成します。
ランキング情報は、「エンティティ」に対して「エンティティ参照回数の昇順」で生成します。
実行例)

> create-jpa-ranking.sh -domainname domain1 -type ENTITY -order ENTITY_REF_COUNT 

コマンドについての詳細は [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.11. インメモリデータグリッド連携部品コマンド] を参照してください。

(3)プリロード対象エンティティの設定

設定は、統合運用管理ツールで行います。
ツリービューより「<エンティティ名>」−「プリロード対象エンティティID指定方法」で「ランキング順」を指定します。
「データプリロード」−「ランキングデータのパス」に生成したランキング情報のファイルパスを指定します。
設定についての詳細は、 [ドメイン構築・基本設定ガイド > 7.9. インメモリデータグリッド連携部品 ]、 [リファレンス集 運用管理・設定編 > 1.19. インメモリデータグリッド連携 ]を参照してください。

(4)データプリロードの実行

データプリロードを実行してください。
データプリロードを実行する詳細な手順は、 [ドメイン構築・基本設定ガイド > 7.9.2.データプリロード の実行 ]を参照してください。

1つのエンティティをインメモリデータグリッドに格納した場合のデータのサイズは以下の計算式で求めることができます。

エンティティIDのバイト数 + シリアライズされたエンティティオブジェクトのバイト数

5KB程のサイズのエンティティを1つロードするのにかかる時間は約13msです。
エンティティ単位のタイムアウト時間の既定値(60秒)でデータプリロードを実行した場合に、ロード可能な件数は約4600件となります。
ロードするデータの件数が多い場合、および、エンティティのサイズが大きい場合はタイムアウト時間の調整が必要です。

設定方法

統合運用管理ツールで設定する場合:

全体のタイムアウト時間は次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[アプリケーションサーバ]-[永続化サービス]-[データプリロード]の[データプリロードのタイムアウトまでの時間]

エンティティ単位のタイムアウト時間は次の属性の値を変更し、更新ボタンを押してください。
[WebOTX管理ドメイン[<ホスト名>]]-[アプリケーションサーバ]-[永続化サービス]-[データプリロード]-[永続化ユニット]-[<永続化ユニット名>]-[データプリロード対象エンティティ]-[<エンティティ名>]の[同期タイムアウト]

運用管理コマンドで設定する場合:

全体のタイムアウト時間:

otxadmin> set server.persistence-service.data-pre-loads.data-pre-load-timeout=60

エンティティ単位のタイムアウト時間:

otxadmin> set server.persistence-service.data-pre-loads.persistence-unit.<persistence-unit-name>.data-pre-load.<entity-name>.synchronous-timeout=120

persistence-unit-nameには、設定対象の永続化ユニット名を指定します。

entity-nameには、設定対象のエンティティ名を指定します。

2.12.2. ファイル容量について

JPAの性能情報データおよび、ランキング情報は、ファイルとして出力されます。
それぞれ、採取量により以下のファイル容量が必要となりますので、ディスク容量にご注意ください。 不要となったファイルは、適宜削除してください。

性能情報データ

find()を1000回呼び出した場合に出力されるファイルのサイズ :約 2.6MB
1回の呼び出しあたり約2.6KBの情報を出力します。

コマンド作業用一時ファイル

find()を1000回呼び出した場合に出力されるファイルのサイズ :約 2.4MB
1回の呼び出しあたり約2.4KBの情報を出力します。