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. 多重度の確認

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

• クライアント多重度

  使用中の接続クライアント数については [3. モニタリング > 3.1. モニタリング情報の採取 > 3.1.3. モニタリングの利用例 > 3.1.3.4. 接続クライアント数のモニタリング] を参照してください。

• スレッド多重度

  WebOTXは稼動スレッド数などを記録するためにオペレーションジャーナルを採取しています。オペレーションジャーナルを編集することにより、稼動スレッド数を時間毎に調査することができます。 [ドメイン構築・基本設定ガイド > 7. WebOTXの内部サービス > 7.1. TPシステム > 7.1.10. 統計情報(オペレーションジャーナル) ] を参照してください。

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が発生します。

設定方法

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

• [アプリケーションサーバ]-[JVM構成]-[最大Javaヒープサイズ] の値を編集

  この値は、JVMオプションの一種である -Xmx(下図参照) を指定することと同様の意味を持ちます。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> set server.java-config.max-heap-size=<サイズ>
  

  <サイズ>には、-Xmxオプションと同様の指定方法でサイズを指定します。例えば、768Mバイトに指定する場合は "768m" とします。

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

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

• [アプリケーションサーバ]-[JVM構成]-[最大Javaパーマネントサイズ]の値を編集

  この値は、JVMオプションの一種である -XX:MaxPermSize(下図参照) を指定することと同様の意味を持ちます。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> set server.java-config.max-perm-size=<サイズ>
  

  <サイズ>には、-XX:MaxPermSizeオプションと同様の指定方法でサイズを指定します。例えば、256Mバイトに指定する場合は "256m" とします。

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

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

• [アプリケーションサーバ]-[JVM構成]-[初期Javaヒープサイズ]

  この値は、JVMオプションの一種である -Xms(下図参照) を指定することと同様の意味を持ちます。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> set server.java-config.heap-size=<サイズ>
  

• [アプリケーションサーバ]-[JVM構成]-[初期Javaパーマネントサイズ]

  この値は、JVMオプションの一種である -XX:PermSize(下図参照) を指定することと同様の意味を持ちます。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> set server.java-config.perm-size=<サイズ>
  

  <サイズ>の部分の指定方法はこれまでと同様です。

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

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

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

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

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

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

• -XX:NewSize

  Young領域(下図参照)の初期サイズを指定します。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> create-jvm-options "-XX\:NewSize=<サイズ>"
  

• -XX:MaxNewSize

  Young領域(下図参照)の最大サイズを指定します。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> create-jvm-options "-XX\:MaxNewSize=<サイズ>"
  

  <サイズ>の部分の指定方法はこれまでと同様です。

• -XX:NewRatio

  Old領域/Young領域 の比(Young : Old = 1 : x)を指定します。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> create-jvm-options "-XX\:NewRatio=<x>"
  

• -XX:SurvivorRatio

  Eden領域/Survivor領域(1つ分)の比(Survivor : Eden = 1 : x)を指定します。
  運用管理コマンドの場合は、次のように指定します。

  otxadmin> create-jvm-options "-XX\:SurvivorRatio=<x>"
  

図2.1.2.1-1

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

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

設定方法

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

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

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

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

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

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

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

設定方法

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

• [アプリケーションサーバ]-[内部ライフサイクルモジュール]-[（各サービス）]-[設定項目(Configurations)]-[起動の可否]

  表示されていないサービスを表示させるためには、統合運用管理ツールの[システム]-[システム設定]-[画面表示]において、管理対象の表示レベルと属性の表示レベルを詳細レベルの情報を表示するように変更してください。

  これらのサービスのうち、以下のサービスについては設定を変更しないで下さい。次回以降、ドメインが正常に起動できなくなる可能性があります。

  • JavaEEUtilityLifecycle
  • TPモニタマネージャサービス(TPMonitorManagerService)
  • Transactionサービス(TransactionService)

otxadmin> set system-applications.application.manager.enabled=false

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. 多重度のチューニング

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

理論的に算出

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

• 平均到着間隔:Ta

  単位時間のトランザクション処理件数の逆数です。既存システムもしくはユーザ要件から算出してください。

• 平均サービス時間:Ts

  サーバでのその処理の実行時間です。既存システムもしくはユーザ要件から算出してください。

• レスポンス時間:R

  クライアントからみた応答時間です(サービス時間+待ち時間)。既存システムもしくはユーザ要件から算出してください。

• 多重度:N

  プロセスグループの多重度です。

これらを待ち行列理論で計算して必要な多重度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

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

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

(※)優先度を維持するためには優先度を固定化する必要があります。また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サーバとの通信が行われます。

設定方法

otxadmin> set-ospi-java-property PoolClasses true

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

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

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

図2.1.4-1

図2.1.4-2

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

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

設定方法

otxadmin> set tpsystem.startTimeOut=120

otxadmin> set tpsystem.stopTimeOut=120

otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.startTimeOut=120

otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.stopTimeOut=120

otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.startTimeOut=120

otxadmin> set tpsystem.applicationGroups.<アプリケーショングループ名>processGroups.<プロセスグループ名>.stopTimeOut=120

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

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

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

• コンストラクタ・デストラクタ(アパートメントの場合)

• 常駐オブジェクトのコンストラクタ・デストラクタ

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

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

• コンストラクタ・デストラクタ(ステートレスフリーの場合)

• コンポーネント初期化インタフェース

• 実装情報の定義関数

• プロセス起動および終了時のコールバック関数

• WO_ObjectListener (JavaAPでフリースレッドモデルの場合のみ)

• BindingHooks (ステートレスフリーで名前サーバへの登録方法が一時的の場合のみ)

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

設定方法

1. スレッド初期化時間

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

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

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

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

• クライアント側で設定する場合

  クライアント側でオペレーション実行要求を出してからその応答をもらうまでのタイムアウト値を設定します。 このタイムアウト値を設定することで、クライアントが無応答となることを抑止します。このタイムアウト値はサーバでの実行時間のほかに通信に要する時間およびキュー待ち時間を考慮して設定します。

  表2.1.4.3-1

  設定項目	説明	既定値	設定値範囲
  1. Javaクライアントからのオペレーション呼び出しタイムアウト時間	EJB、JNDIなどRMI-IIOP通信を使用する呼び出しのタイムアウト時間です。	30秒	0以上 ※0を指定した場合は無制限
  2. Javaクライアントでの無通信監視タイムアウト時間	クライアント側で一定時間送受信要求のないコネクションをクローズするまでのタイムアウト時間です。	無制限	0以上 ※0を指定した場合は無制限
  3. オペレーション呼び出しのタイムアウト時間	CORBA通信を使用する呼び出しのタイムアウト時間です。	30秒	0以上 ※0を指定した場合は無制限
  4. コネクションラウンドロビンでのオペレーション呼び出しのタイムアウト時間	多重化オブジェクトによるコネクションラウンドロビン機能を利用する場合に有効になります。個々のサーバへのオペレーション呼び出しのタイムアウト時間です。	オペレーション呼び出しのタイムアウト時間の値	0以上 ※0を指定した場合は無制限

  設定方法

  1. Javaクライアントからのオペレーション呼び出しタイムアウト時間

  • Javaコマンドラインで指定する場合

    以下の形式でシステムプロパティを指定

    -Djp.co.nec.orb.RequestTimeout=<タイムアウト時間(秒)>

  • J2EEサーバ(Webコンテナ、JNDIサーバ)に指定する場合

    統合運用管理ツールのserver.java-configの「JVMオプション」に以下の形式でシステムプロパティを追加

    -Djp.co.nec.orb.RequestTimeout=<タイムアウト時間(秒)>

  • プロセスグループ(EJBコンテナ)に指定する場合：

    統合運用管理ツールのtpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>の「Javaシステムプロパティ」で行の追加を実行し、 1列に「jp.co.nec.orb.RequestTimeout」、2列に秒数を指定

  2. Javaクライアントでの無通信監視タイムアウト時間

  • Javaコマンドラインで指定する場合

    以下の形式でシステムプロパティを指定

    -Djp.co.nec.orb.ClientAutoTimeout=<タイムアウト時間(秒)>

  • J2EEサーバ(Webコンテナ、JNDIサーバ)に指定する場合

    統合運用管理ツールのserver.java-configの「JVMオプション」に以下の形式でシステムプロパティを追加

    -Djp.co.nec.orb.ClientAutoTimeout=<タイムアウト時間(秒)>

  • プロセスグループ(EJBコンテナ)に指定する場合

    統合運用管理ツールのtpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>の「Javaシステムプロパティ」で行の追加を実行し、 1列に「jp.co.nec.orb.ClientAutoTimeout」、2列に秒数を指定

  3. オペレーション呼び出しのタイムアウト時間

  • 統合運用管理ツールで指定する場合

    server.objectbrokerconfigの「共通」タブの「リクエスト呼び出しのタイムアウト時間」に秒数を指定

  • コマンドで指定する場合

    otxadmin> set server.objectbrokerconfig.RequestTimeout=<設定値>
    

    Caution
    Javaクライアントの場合、上記の「Javaクライアントからのオペレーション呼び出しタイムアウト時間」が設定されていれば、そちらが本設定よりも優先されます

  4. コネクションラウンドロビンでのオペレーション呼び出しのタイムアウト時間

  • 統合運用管理ツールで指定する場合

    server.objectbrokerconfig.の「Cpp」タブの「多重化使用時の最大待ち時間」に秒数を指定

  • コマンドで指定する場合

    otxadmin> set server.objectbrokerconfig.ConnectionRoundRobinTimeout=<設定値>
    

• サーバ側で設定する場合(キュー滞留時間監視タイマ)

  オペレーション実行要求をサーバが受け付けてからその応答を返すまでのタイムアウト値を設定します(既定値：上限なし)。このタイムアウト値を設定することで、 クライアントが無応答となることを抑止します。このタイムアウト値はサーバでの実行時間のほかに通信に要する時間およびキュー待ち時間を考慮して設定します。 各オペレーションの実行時間(予測値)の最大値よりは大きな値を設定する必要があります。設定を反映させるためにはアプリケーショングループの再起動が必要です。

  なお、キュー滞留時間監視タイマを超過した場合、クライアントにエラーは返りますがサーバAPは処理を継続したままなのでサーバAPの無応答状態が改善するわけではありません。

  設定方法

    統合運用管理ツールのプロセスグループの[上限設定]-[キュー滞留時間監視タイマ]

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システムの再起動が必要です。

設定方法

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

2.1.4.6. キューイング数上限

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

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

設定方法

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

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

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

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

設定方法

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

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

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

設定方法

   統合運用管理ツールの[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リスナ]-[クライアント制御]-[接続要求最大保留数]

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. Webサーバ(Apache)

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

2.2.1. リクエスト処理

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

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

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

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

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

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

UNIX

Windows

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

2.2.1.2. その他の設定項目

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

UNIX: Apache2.2

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

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

Windows

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

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）が定義されています。

• http-thread-pool

  外部Webサーバ（リスナID:ajp-listener-1）、内蔵Webサーバ（リスナID：http-listener-1, http-listener-2）と連携している場合、共通です。

• admin-thread-pool

  Web版運用管理コンソール用のリスナ（リスナID:admin-listener）に対する処理スレッドを制御しています。

• thread-pool-1

  定義はされていますが、利用しているリスナはありません。

スレッドプールがどのリスナで利用しているかの確認は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）が定義されています。

• 外部Webサーバ（リスナID:ajp-listener-1）、内蔵Webサーバ（リスナID：http-listener-1, http-listener-2）と連携している場合、共通です

  http-thread-pool

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

ドメインを WebOTX Web Server などの外部の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 です。

値を反映するには 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.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.*

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

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

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" と一緒に考えます。

• ThreadsPerChild > connection_pool_size の時

  WebOTX Webサーバには接続されますが、プラグインの処理数が少ないため 500エラーが多く発生するようになります。しかし、WebOTX Webサーバのバックログキューには溜まらないためレスポンスはある程度確保できます。

• ThreadsPerChild == connection_pool_size の時

  ThreadsPerChild と connection_pool_size が同じであるため 500エラーは発生しにくいですが、ThreadsPerChild を超えてきたリクエストは WebOTX Webサーバのバックログキューに溜まります。その結果レスポンスタイムが悪化します。

• ThreadsPerChild < connection_pool_size の時

  プラグインでは来たリクエストを確実にさばき、WebOTX Webサーバやプラグインよりも後段で流量の制御を行う場合に設定します。 ThreadsPerChild を超えてきたリクエストは WebOTX Webサーバのバックログキューに溜まります。

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

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

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

2.3.4.3. アドバンスドモード（単一サーバ）

アドバンスドモードでは WebOTX WebServer を利用することが前提となり、IIOPプラグインを利用します。

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

図2.3.4.3-1

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

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) は接続してくるクライアント１つあたりの多重度となりますので、WebOTX Webサーバの同時クリエスと処理数（ThreadsPerChild）と同じ数になるように設定します。

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

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

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

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

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

2.3.4.4. アドバンスドモード（複数サーバ）

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

図2.3.4.4-1

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

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

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

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

• WebOTXのエディションとの関係

  Expressエディションはスタンダードモードのみ選択できますが、StandardとEnterpriseの両エディションではスタンダードモードとアドバンスドモードが選択できます。 コネクター種別の選択は、スタンダードモードの場合のみ利用可能です。ただし、外部Webサーバと連携して利用したい場合は、利用可能なコネクターは、”AJP”に限定されます。
  アドバンスドモードで利用する場合は、WebOTX Webサーバの専用プラグインからIIOPリスナを経由して電文を受け取ります。 各エディションとモードの詳細については、 [ 製品構成と提供機能 > 3. 提供機能 > 3.2. Web層 > 3.2.2. Webコンテナ > 3.2.2.5. Web コンテナの機能構造 ] を参照してください。

• Webアプリケーションで利用したい機能による選択

  Webアプリケーション等で利用したい機能を考慮して、表2.3.4.5-1を参考に利用可能なコネクター種別の選択肢を確認します。 たとえば、WebSocketを利用したい場合は、利用可能なコネクターは、”NIO”に限定されます。
  

• 最適なスレッド数の決定

  次に、利用するWebアプリケーションを使って負荷試験を行い図2.3.4.5-1や図2.3.4.5-3の結果から、最適なスレッド数を 決めてください。スレッド数を増やすことで同時処理を増やすことができますが、TATは悪くなります。
  コネクター種別毎の傾向は、Webアプリケーション毎にはあまり変わりませんが、最適なスレッド数は利用するWebアプリケーション に依存します。

• スレッド数とクライアント数(同時接続数)による選択

  スレッド数とクライアント数(同時接続数)の大小関係を確認し、スレッド数のほうが多い場合、BIOコネクターを選択します。 スレッド数のほうが少ない場合、NIO或いはGrizzlyコネクターを選択します。
  NIO、Grizzlyのどちらか選択する場合、WebSocketを利用しないのであれば、Grizzlyコネクターを選択します。

外部サーバ（Apache）連携用のコネクター

• 外部サーバ（Apache）を連携した場合、AJP コネクターを使用して下さい。

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

図2.3.4.5-1

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

図2.3.4.5-2

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

• BIO コネクターは Java のブロッキング I/O 機能を使用して、クライアントからのリクエストを処理します。適度な接続数（同時に接続するクライアント数）の場合、このコネクターは、最高のパフォーマンスを提供する可能性が高くなります。ただし 、接続数が多くなるとTATやスループットが急激に悪化する傾向があります。
• NIO コネクターは　Java の非ブロッキング I/O 機能を使用して、単一スレッドで複数接続を受け入れます。大量の接続数の場合でも、スレッドを効率的に利用することができます。このコネクターはスレッド・プールを調整する手間をかけずに、より高いスケーラビリティーを提供できます。
• Grizzly コネクターも、NIOと同じく Java の非ブロッキング I/O 機能に基づいて、Webサーバのパフォーマンスを最適化しますので、より少ないスレッドでより多い接続を受け入れます。

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

図2.3.4.5-3

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

図2.3.4.5-4

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サーバに関する統計情報から確認できます。

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

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

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サーバを再起動してください。

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

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

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である場合、

が起動開始を示し、

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

設定方法

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

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

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

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

【備考】

• JMSサーバ起動完了待ち時間のデフォルト値は、60(秒)です。

2.4.2. 送信先の設定

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

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

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

確認方法

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

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

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

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

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

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

設定方法

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

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

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

【備考】

• プロデューサ最大数のデフォルト値は-1(無制限)です。

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

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

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

確認方法

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

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

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

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

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

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

設定方法

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

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

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

【備考】

• アクティブコンシューマ数のデフォルト値は、-1(無制限)です。

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

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

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

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

設定方法

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

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

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

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

【備考】

• コンシューマへのフロー制限数のデフォルト値は1000です。

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

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

確認方法

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

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

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

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

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

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

送信先

JMSサーバ全体

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

設定方法

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

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

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

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サーバ全体のメッセージ滞留抑止に関する値は、以下で設定します。

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

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

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

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

【備考】

• メッセージの最大数、メッセージの最大合計サイズは、送信先、JMSサーバとも、-1(無制限)です。
• 送信先の制限到達時の振る舞いのデフォルト値はREJECT_NEWESTです。

【注意】

• JMSサーバ全体のデータには、運用管理操作(統計情報の採取も含む)での情報も含まれており、 JMSメッセージだけのメッセージ数やバイト数というわけではありません。

2.4.3. コネクションの設定

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

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

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

• JMSサーバが、クライアントの異常を検知できずに、クライアントに関するリソースがパージできない。

• JMSクライアントが、サーバの異常を検知できずに、メッセージ配信を待ちつづけてしまい、JMSサーバのクラスタ切り替えに対応できない。

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

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

設定方法（JMSサーバ）

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

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

起動引数

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

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

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

config.properties

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

設定方法（JMSクライアント）

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

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

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

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

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

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

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

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

確認方法

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

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

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

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

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

設定方法

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

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

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

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

【備考】

• デフォルトでは、JMSサーバは、プロデューサから受け付けた永続メッセージに対してのみ受諾通知を返すようになっています。

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

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

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

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

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

設定方法

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

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

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

採取情報

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

確認方法

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

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

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

otxadmin> list-jms-connections

【備考】

• 確認の結果、「Peak Memory」が、「Max Memory」に近いものがあれば、さらにそのクライアントに対して次項で説明しているログを採取し、 コネクションファクトリのフロー制御に関する設定値や、メモリサイズを調整します。

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

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

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

設定方法

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

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

採取情報

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

• メモリ状況に関する項目

  表2.4.4.2-2

  項目	説明
  TotalMemory	JavaVMの総メモリ量(バイト数)
  FreeMemory	JavaVMの空きメモリ量(バイト数)
  PeakMemory	JavaVMの最大使用メモリ量(バイト数)

  
  

• コンシューマレベルのフロー制御に関する項目

  表2.4.4.2-3

  項目	説明
  Count of unprocessing	コンシューマで未消費のメッセージ数
  Peak count of unprocessing	コンシューマ起動後の未消費メッセージ数の最大値
  Pause count	停止した回数
  Resume count	配信再開要求(RESUME_FLOW)を行った回数
  Last resume count	最後の配信再開要求(RESUME_FLOW)で、JMSサーバに要求したメッセージ数

  
  

• コネクションレベルのフロー制御に関する項目

  表2.4.4.2-4

  項目	説明
  Count of unprocessing	コネクションで未消費のメッセージ数
  Peak count of unprocessing	クライアントが起動後の未消費メッセージ数の最大値
  Pause count	停止した回数
  Resume count	配信再開要求(RESUME_FLOW)を行った回数

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

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

クライアントへ送信された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が大きすぎて、スループットを低下させている可能性があるため、これらの値を調整する目安とします。

【備考】

• wojmsConsumerFlowLimitのデフォルト値は1000、wojmsConsumerFlowThresholdのデフォルト値は、50(%)です。

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

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

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

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

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

【備考】

• wojmsConnectionFlowLimitのデフォルト値は1000です。

2.5. Transactionサービス

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

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

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

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

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

• トランザクション実行中にサーバアプリケーションを呼び出さない場合

  トランザクション実行中にサーバアプリケーションを呼び出さない場合とは、サーバアプリケーションでトランザクションを開始し、他のプロセス上のサーバアプリケーションを呼び出すことなくトランザクションが完結する場合のことです。自プロセス上のサーバアプリケーションの呼び出しもこの場合に該当します。

  この場合は、クライアントで設定するサーバアプリケーションを呼び出す際の通信のタイムアウト時間より短い値をトランザクションタイムアウト時間に設定します。

  これはクライアントからサーバへの呼び出しの中でトランザクションを実行するので、トランザクションのタイムアウトが発生した時点で通信のタイムアウトにより通信が切断されているとクライアントにトランザクションの成否を通知する手段が無くなるためです。

  具体的にはクライアントで設定されるObject Brokerのリクエスト呼び出しのタイムアウト時間(RequestTimeout: 既定値30秒)より短い値をサーバのトランザクションタイムアウト時間に設定します。

  
  図2.5.1-1

  
  
  

• トランザクション実行中にサーバアプリケーションを呼び出す場合

  トランザクション実行中にサーバアプリケーションを呼び出す場合とは、クライアントアプリケーションでトランザクションを開始した後、サーバアプリケーションを呼び出し実行する場合、もしくはサーバアプリケーションでトランザクションを開始した後、他のプロセス上のサーバアプリケーションを呼び出し実行する場合のことです。

  この場合は、クライアントからサーバアプリケーションを呼び出す際の通信のタイムアウト時間より長い値をトランザクションタイムアウト時間に設定します。

  これはトランザクションの開始と終了の間でサーバの呼び出しが行われるため、いくら通信のタイムアウト時間を長くしてもトランザクションタイムアウト時間が経過した時点でトランザクションはロールバックしてしまうためです。

  具体的にはクライアントで設定されるObject Brokerのリクエスト呼び出しのタイムアウト時間(RequestTimeout: 既定値30秒)より長い値をクライアントまたはサーバ(トランザクションを開始する方)のトランザクションタイムアウト時間に設定します。

  
  図2.5.1-2

  
  
  

設定方法

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

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

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

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

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

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

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

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

• トランザクションの開始前に取得したJDBCコネクションをそのトランザクションに参加させることはなく、JDBCコネクションの取得、及び、クローズがトランザクションの開始と終了の間で行なわれている。

  // JDBCコネクショとEJBインスタンスの関連付け機能が利用されるケース(高速化不可) UserTransaction utx = …; DataSource ds = …; Connection con = ds.getConnection(); utx.begin(); // コネクション(con)を利用したデータベース更新をここで行なう utx.commit(); con.close();

  // JDBCコネクショとEJBインスタンスの関連付け機能が利用されないケース(高速化可能) UserTransaction utx = …; DataSource ds = …; utx.begin(); Connection con = ds.getConnection(); // コネクション(con)を利用したデータベース更新をここで行なう con.close(); utx.commit();

  
  

• 他のBeanを呼び出す前にJDBCコネクションをクローズし、JDBCコネクションの引継ぎを行わない。

  // Bean間でJDBCコネクションを引き継ぐケース(高速化不可) DataSource ds = …; Connection con = ds.getConnection(); // コネクション(con)を利用したデータベース更新をここで行なう // 別Beanの呼び出し // コネクション(con)を利用したデータベース更新をここで行なう con.close();

  // Bean間でJDBCコネクションを引き継がないケース(高速化可能) DataSource ds = …; Connection con = ds.getConnection(); // コネクション(con)を利用したデータベース更新をここで行なう con.close(); // 別Beanの呼び出し Connection con = ds.getConnection(); // コネクション(con)を利用したデータベース更新をここで行なう con.close();

トランザクションの高速化は、${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.2. JAX-RPC用のJavaシステムプロパティ

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

設定方法

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

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

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

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

実行例

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秒に設定されています。 それでもなお、度々コネクションの接続および切断が繰り返される状況になる場合は、コネクション解放の待ち合わせ時間を長くすることで性能を改善できます。

確認方法

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

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

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

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

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

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

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

otxadmin> set server.monitoring-service.module-monitoring-levels.jdbc-datasource=LOW

設定方法

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

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

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

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

設定方法

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

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

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

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

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

設定方法

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

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

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

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

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

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

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

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

設定方法

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

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

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

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

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

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

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

設定方法

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

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

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〜スレッド数の間で設定してください。

• 統合運用管理ツール

  [(ドメイン名)]-[アプリケーション]-[WebOTXJ2EEアプリケーション]-[(モジュール名)]-[(ファイル名)]-[(アプリケーション名)]-[(リモートインタフェース)]の「一般」タブの「事前生成するオブジェクト数」

• 運用管理コマンド

  otxadmin> set applications.j2ee-applications.(モジュール名).(ファイル名).(アプリケーション名).(リモートインタフェース).priorGenerationCount=(設定したい数)

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

Expressの場合

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

• 統合運用管理ツール

  [(ドメイン名)]-[アプリケーションサーバ]-[EJBコンテナ]の「通常プールサイズ」

• 運用管理コマンド

  otxadmin> set server.ejb-container.steady-pool-size=(設定したい数)

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

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

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

• 統合運用管理ツール

  [(ドメイン名)]-[アプリケーションサーバ]-[EJBコンテナ]の「アイドルタイムアウト（キャッシュ）」

• 運用管理コマンド

  otxadmin> set server.ejb-container.pool-idle-timeout-in-seconds=(設定したい数)

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コンテナの設定に拠ります。

• 統合運用管理ツール

  [(ドメイン)]-[アプリケーションサーバ]-[MDBコンテナ]
  
  

• 運用管理コマンド

  otxadmin> set server.mdb-container.steady-pool-size=(設定したい数)

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秒で、約２時間１１分で障害を検出します。

  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を加えた２時間８分で障害を検出します。

  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倍になります）。

送信タイムアウト時間（接続要求時）：

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

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

KeepAlive：

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

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

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

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

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

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

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

(*)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を設定することで、その業務アプリケーションが稼動しているドメインを停止の対象からはずすことができます。

設定方法

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

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

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

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

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

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

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

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

設定方法

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

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

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

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

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

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

設定方法

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

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

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

2.11. インメモリデータグリッド連携部品

インメモリデータグリッド連携部品のチューニングについて説明します。

2.11.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つのエンティティをインメモリデータグリッドに格納した場合のデータのサイズは以下の計算式で求めることができます。

5KB程のサイズのエンティティを１つロードするのにかかる時間は約13msです。
エンティティ単位のタイムアウト時間の既定値(60秒)でデータプリロードを実行した場合に、ロード可能な件数は約4600件となります。
ロードするデータの件数が多い場合、および、エンティティのサイズが大きい場合はタイムアウト時間の調整が必要です。

設定方法

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

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

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

2.11.2. ファイル容量について

JPAの性能情報データおよび、ランキング情報は、ファイルとして出力されます。
それぞれ、採取量により以下のファイル容量が必要となりますので、ディスク容量にご注意ください。 不要となったファイルは、適宜削除してください。

性能情報データ

find()を1000回呼び出した場合に出力されるファイルのサイズ ：約 2.6MB
1回の呼び出しあたり約2.6KBの情報を出力します。

コマンド作業用一時ファイル

find()を1000回呼び出した場合に出力されるファイルのサイズ ：約 2.4MB
1回の呼び出しあたり約2.4KBの情報を出力します。