5. チューニング

本章では、WebOTX ESBのチューニングの方法について説明します。チューニングは大きく分けて2種類あり、WebOTX ESB全体に関するチューニングと各コンポーネント毎のチューニングがあります。また、チューニングの他にも性能に影響する設定項目の説明もします。

5.1. WebOTX ESB全体

WebOTX ESB全体に関するチューニングを説明します。

5.1.1. DocumentBuilder数

WebOTX ESBでは、DOM解析処理を行うDocumentBuilderオブジェクトをプールにより管理しており、ESB全体で共有しています。そのため、システムで想定される負荷に応じてDocumentBuildrのプールのサイズを調整することが可能です。このDocumentBuilderオブジェクトはSOAP BCのSUで「XML処理のタイプ」で指定した場合や、各種ハンドラでDOM操作を行う場合に利用されます。

[関連する設定項目]



5.1.2. メッセージログ

メッセージログ機能を有効にすると、ESBはNMRを流れるメッセージを監視するため、若干性能が下がります。メッセージログ機能は初期状態では無効となっています。 メッセージログをファイルに出力する場合、非同期出力にすることで性能の劣化をある程度抑えることができます。ただし、非同期出力にした場合は、 高負荷時にログ出力が遅延し、キュー最大値を超えて要求されたメッセージログについてはロストするため注意が必要です。

[関連する設定項目]

メッセージログ機能の設定方法については、[ 2. メッセージログ ]を参照ください。


5.1.3. プロセスグループのプロセス数(マルチプロセスモードの場合のみ)

WebOTX ESBはTPモニタで管理されるプロセスのプロセス中で動作します。その為、最適な性能を得るにはプロセスグループの「プロセス数」のチューニングを行う必要があります。

[関連する設定項目]

プロセスグループのチューニング方法は、WebOTXマニュアルの[ Application Server > 高度な管理と運用サイクルガイド > 2. チューニング ] を参照してください。


5.2. バインディングコンポーネント

5.2.1. 共通

ここでは、バインディングコンポーネントで共通のチューニング項目について説明します。

5.2.1.1. ログレベル

ログ出力量に応じて性能値が変化します。CONFIGレベルでは起動・停止および設定関連のログのみ出力しますので、通常動作ではCONFIGレベル(既定値)の設定を推奨します。正常動作時では、CONFIG〜OFFの性能値は変化しません。DEBUGよりも詳細なログレベルでは正常動作時にもログを出力しますので、ログを詳細にする毎に性能値が低下します。

[関連する設定項目]

「ログレベル」の設定は統合運用管理ツールを用いて行います。具体的な操作は[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.3. バインディングコンポーネントに関する設定 ] を参照してください。


5.2.1.2. モニタレベル

統計情報を採取するレベルに応じて性能値が変化します。既定値は"OFF"で、統計情報を採取しないため、最も高速です。"LOW"ではBC単位で統計情報を採取します。"HIGH"では、さらに配備されたエンドポイント毎の統計情報を採取します。

[関連する設定項目]

「モニタレベル」の設定は統合運用管理ツールを用いて行います。具体的な操作は[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.3. バインディングコンポーネントに関する設定 ] を参照してください。


5.2.1.3. 最大スレッド数/最小スレッド数

「最大スレッド数」は、該当BCのOutboundへ同時にアクセスされると予想する最大数に対して余裕を持って設定します。最大スレッド数を超えた数のアクセスを行うとErrorメッセージが返却されます。
「最小スレッド数」は、平常稼動時に該当BCのOutboundへ同時にアクセスすると予想される平均数の程度に設定します。「最小スレッド数」を越えた数のアクセスを行った場合、スレッドが新たに生成されます。その後、「最小スレッド数」を越えて生成されたスレッドが使用されなかった場合、「スレッド解放までの時間」で設定した時間後にスレッドが自動で解放されます。

[関連する設定項目]

「最大スレッド数」および「最小スレッド数」の設定は統合運用管理ツールを用いて行います。具体的な操作は[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.3. バインディングコンポーネントに関する設定 ] を参照してください。


5.2.1.4. EventManagerスレッド数(FTP BC は除く)

NMR内を通るメッセージを、各コンポーネントのInbound/Outboundのスレッドに振り分けるEventManagerスレッドの数を設定します。 大量のメッセージがNMR内を通る時に、EventManagerによるメッセージの振り分けがボトルネックとなり、CPUリソースに空きがあるにも関わらず性能が頭打ちになるケースがあります。 各コンポーネントの統計情報として取得できる「DeliveryChannelQueueCountNow」の値が大きい場合(100以上など)に、 「EventManagerスレッド数」を調整することによって上記のようなケースにおける性能の頭打ちが解消される可能性があります。

[関連する設定項目]

「EventManagerスレッド数」の設定は統合運用管理ツールを用いて行います。具体的な操作は[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.3. バインディングコンポーネントに関する設定 ] を参照してください。

5.2.1.5. エラーリトライ時の認証・認可の再実行スキップ

エラーリトライを設定している場合、エラー発生時にInboundのコンポーネントからメッセージが再送されます。
セキュリティ機能が有効になっている場合、再送後のメッセージに対しても認証・認可が実施されますが、オプション一覧に名前:AUTHORIZE_SKIP、値:trueを設定することで認証・認可機能をスキップさせることができます。

認可の条件に時間を設定しているような場合、スキップを行うと予期せぬ時間にエンドポイントが実行される可能性があります。AUTHORIZE_SKIPの設定は十分検討してから設定を行うようにしてください。

[関連する設定項目]

設定方法は、WebOTXマニュアルの[ アプリケーション開発ガイド(Enterprise Service Bus) > 2. プログラミング・開発ガイド > 2.9. バインディングコンポーネントの定義 の各コンポーネントで記載されているオプション一覧の説明を参照してください。

以降では、各コンポーネント毎のチューニング方法をそれぞれ説明します。

5.2.2. SOAP BC

SOAP BCを利用する場合の性能チューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント ] を参照してください。

Webサーバを使用する場合は、併せてWebサーバのチューニングが必要になります。Webサーバについては [ アプリケーションサーバマニュアル > ドメイン構築・基本設定ガイド > 7.WebOTXの内部サービス > 7.6.WebOTX Webサーバ ] を参照してください。

以下はSOAP BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.2a】SOAP BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1Webサーバのスレッド数を設定します。 クライアント数が増加し、接続できない場合ご利用のWebサーバのチューニング方法に従い、設定してください。
2-1AJPリスナを設定します。(Express、またはStandard以上のシングルプロセスモード)  WebOTXマニュアルのチューニングをご確認ください。
2-2IIPOリスナを設定します。(Standard以上のマルチプロセスモード)  WebOTXマニュアルのチューニングをご確認ください。
3Inboundの受信用スレッド数を設定します。Webコンテナのスレッドを利用しており、リクエストを受けるたびに1つ消費します。 Endpointの流量制御が必要な場合WebOTXマニュアルのチューニングをご確認ください。
4EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
5Outbound、およびInbound返信用のワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」
6HTTPチューニングパラメータ Keep-alive, Expect-contineなどが必要な場合ProviderのEndpointの各種設定項目

【表5.2.2a】SOAP BCのチューニングポイントの説明

5.2.2.1. XML処理方式の選択

SOAP BCでは、内部で用いるXML処理の方式をDOMとSAXから選択できます。 基本的にSAXは高速かつ低メモリで処理が可能ですが、接続するBC/SEに応じてDOMの方が高速になることがあります。 具体的には、CORBA BC、RMI BC、JDBC BCは内部でDOM処理を行いますので、SOAP BCからこれらのBCへ接続する場合はDOMとした方が高速となる可能性が高くなります。 また、SOAPメッセージのバージョンが1.2の場合、およびSOAP Header内に要素がある場合は、設定に関係なくDOMで処理を行います。

[関連する設定項目]


5.2.2.2. HTTP処理スレッド数のチューニング

SOAP BCのInboundはWebコンテナ上のHTTPリスナのスレッドで動作します。 そのため、SOAP BCにアクセスするクライアントの予想される多重度に合わせて、WebコンテナのHTTP処理スレッド数を調節します。

[関連する設定項目]


5.2.3. JMS BC

JMS BCを利用する場合のチューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

以下はJMS BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.3a】JMS BCのチューニングポイントの全体図(リソースアダプタを利用する場合)


番号説明チューニング観点設定場所
1JCAコンテナ上で動作するMessageListenerの多重度を指定します。 JMS送信先にメッセージが滞留する場合(多重度を上げる)
ESBにメッセージが滞留してきた場合(多重度を下げる)
エンドポイント:「リソースアダプタ」-「ActivationSpec定義」
2EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
3Outbound、およびInbound返信用のワーカスレッド数を設定します。 JMS BCにメッセージが滞留してきた場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.3a】JMS BCのチューニングポイントの説明

【図5.2.3b】JMS BCのチューニングポイントの全体図(リソースアダプタを利用しない場合)


番号説明チューニング観点設定場所
1EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
2Outbound、およびInbound返信用のワーカスレッド数を設定します。 JMS BCにメッセージが滞留してきた場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.3b】JMS BCのチューニングポイントの説明

5.2.3.1. JMSのチューニング

利用するJMSの設定を適切にする必要があります。

[関連する設定項目]

WebOTX JMSについては、WebOTXマニュアルの[ Application Server > 高度な管理と運用サイクルガイド > 2. チューニング > 2.4. JMS ] を参照してください。

5.2.3.2. JMSリソースアダプタのチューニング

利用するJMSリソースアダプタに関する設定(ActivationSpecやコネクタコネクションプールのプロパティ)を適切にする必要があります。
例えば、Inbound多重度を増やすことで同時に処理するメッセージ数を増やしたり、JMSサーバへの接続リトライ数や間隔を設定することにより再起動時に自動的に再接続させることも可能です。

[関連する設定項目]

WebOTX JMSリソースアダプタに関する設定は、WebOTXマニュアルの[ Application Server > リファレンス集 運用管理・設定編 > 1.7. JMS > 1.7.3. その他の設定項目・設定方法 > 1.7.3.19. ActivationSpec に設定可能なプロパティ] を参照してください。
汎用JMSリソースアダプタに関する設定は、WebOTXマニュアルの[ Application Server > リファレンス集 運用管理・設定編 > 1.7. JMS > 1.7.3. その他の設定項目・設定方法 > 1.7.3.18. 他社JMSプロバイダ接続の設定] を参照してください。
他社JMSリソースアダプタに関する設定は、提供元のマニュアルを参照してください。

5.2.4. JCA BC

JCA BCを利用する場合のチューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント ] を参照してください。

以下はJCA BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.4a】JCA BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
2Outbound、およびInbound返信用のワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.4a】JCA BCのチューニングポイントの説明

5.2.4.1. EISのトランザクションタイムアウトを意識したチューニング

Inboundでは、プロバイダ側の処理能力により、リソースアダプタへの応答が遅延することが考えられます。この応答が遅延すると、EISでトランザクションのタイムアウトが発生する原因になります。
JCA BCでは、プロバイダ側からの応答を待たずに即座にリソースアダプタに応答を返す設定や指定時間だけ待ち合わせる設定を提供しています。必要に合わせて、設定を調整してください。

[関連する設定項目]


5.2.5. RMI BC

RMI BCを利用する場合のチューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

以下はRMI BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.5a】RMI BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
2Outbound、およびInbound返信用のワーカスレッド数を設定します。 RMI BCにメッセージが滞留してきた場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.5a】RMI BCのチューニングポイントの説明

5.2.5.1. リクエストタイムアウト

OutboundでのEJB呼び出しに遅延が生じると、InboundからのリクエストがESB内に滞留することになり、処理遅延やメモリ不足などの問題を引き起こすことも考えられます。これを回避するためには、EJB呼び出しをタイムアウトさせることが有効となります。
EJBの呼び出しは、Object Broker Javaが提供するRMI-IIOP通信基盤を通して行われます。Objetct Broker Javaでは、クライアントからのサーバ呼び出しで想定以上の遅延を生じさせないためにリクエストタイムアウトの仕組みが提供されています。

[関連する設定項目]

設定は、Object Brokerコンフィグのドメイン共通となる設定項目「リクエスト呼び出しのタイムアウト時間」で行います。デフォルト値は30秒です。
RMI BCでは、この設定値より優先される、RMI BC共通の設定項目「CORBAのリクエストタイムアウト値」とエンドポイント単位の設定項目「リクエストタイムアウト値」を提供しています。後者はサービスアセンブリ開発時にサービスユニット内に設定します。

5.2.6. File BC

File BCを利用する場合のチューニングについて説明します。 File BCに特有な性能チューニングはありません。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

以下はFile BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.6a】File BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1.1Endpointの流量制御  エンドポイント:「エンドポイント単位の同時処理最大リクエスト数」
1.21プロセスのInboundスレッドで同時処理最大ファイル数  コンポーネント:1プロセスのInboundスレッドで同時処理最大ファイル数
1.3マルチプロセスのInboundで同時処理最大ファイル数  コンポーネント:マルチプロセスのInboundで同時処理最大ファイル数
2EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
3書き込み制御世代数  エンドポイント:出力ファイルの世代数
4Outbound、およびInbound返信用のワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.6a】File BCのチューニングポイントの説明


5.2.7. CORBA BC

CORBA BCを利用する場合のチューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

【図5.2.7a】CORBA BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
2Outbound、およびInbound返信用のワーカスレッド数を設定します。 CORBA BCにメッセージが滞留してきた場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.7a】CORBA BCのチューニングポイントの説明

5.2.7.1. リクエストタイムアウト

OutboundでのCORBAアプリケーションの呼び出しに遅延が生じると、InboundからのリクエストがESB内に滞留することになり、処理遅延やメモリ不足などの問題を引き起こすことも考えられます。これを回避するためには、CORBAアプリケーション呼び出しをタイムアウトさせることが有効となります。
CORBAアプリケーションの呼び出しは、Object Broker Javaが提供するIIOP通信基盤を通して行われます。Objetct Broker Javaでは、クライアントからのサーバ呼び出しで想定以上の遅延を生じさせないためにリクエストタイムアウトの仕組みが提供されています。

[関連する設定項目]

設定は、Object Brokerコンフィグのドメイン共通となる設定項目「リクエスト呼び出しのタイムアウト時間」で行います。デフォルト値は30秒です。
CORBA BCでは、この設定値より優先される、CORBA BC共通の設定項目「CORBAのリクエストタイムアウト値」とエンドポイント単位の設定項目「リクエストタイムアウト値」を提供しています。後者はサービスアセンブリ開発時にサービスユニット内に設定します。

5.2.8. JDBC BC

JDBC BCを利用する場合のチューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

【図5.2.8a】JDBC BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1データ有無の監視間隔を設定します。 メッセージの入力頻度の調整エンドポイント:オペレーションの設定「データ有無の監視間隔」
コンポーネント:「データ有無の監視間隔」
2select実行時のレコードの取得上限値を設定します。 メッセージの同時処理数の調整エンドポイント:オペレーションの設定「クエリのレコード数上限値」
コンポーネント:「クエリのレコード数上限値」
3EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
4Outbound、およびInbound返信用のワーカスレッド数を設定します。 JDBC BCにメッセージが滞留してきた場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.8a】JDBC BCのチューニングポイントの説明

5.2.8.1. クエリ実行タイムアウト

Outboundでのデータベースアクセスに遅延が生じると、InboundからのリクエストがESB内に滞留することになり、処理遅延やメモリ不足などの問題を引き起こすことも考えられます。これを回避するためには、SQL命令の実行をタイムアウトさせることが有効となります。
JDBCデータソースでは、使用するjava.sql.Statementのタイムアウトを利用するための設定が提供されています。

[関連する設定項目]

設定は、JDBCデータソースの設定項目「クエリタイムアウト」で行います。デフォルトではタイムアウトしません。
JDBC BCでは、独自に、JDBC BC共通の設定項目「クエリ実行タイムアウト値」とエンドポイント単位の設定項目「クエリ実行タイムアウト値」を提供しています。後者はサービスアセンブリ開発時にサービスユニット内に設定します。

5.2.8.2. 処理能力の向上

Inboundでのデータベースに対するクエリは、専用の受信スレッドが一定間隔でSQLを発行し、1度に取得したレコード群を1つのメッセージに対応付けてOutboundに送信しています。 データベースへの入力頻度とOutboundエンドポイントの処理能力に合わせて、単位時間あたりのリクエスト受付数が多くなりすぎないようにチューニングすることが必要です。

[関連する設定項目]

SQLの発行間隔は「データ有無の監視間隔」、一度に取得するレコード数は「クエリのレコード上限数」という設定項目を、JDBC BC共通の設定とエンドポイント単位の設定の2通りを用意しています。後者はサービスアセンブリ開発時にサービスユニット内に設定します。

5.2.8.3. 二重処理の抑止

クエリで処理対象となったレコードは、応答メッセージが戻るまで更新されません。そのため、Outbound処理が遅延した場合、次のクエリで再度対象となり、二重にリクエストメッセージを生成する可能性があります。
この問題を回避するには、次のような方法が考えられます。
1つは、Outbound処理で遅延を発生させない設定(例えばRMI BCのリクエストタイムアウト等)をし、「データ有無の監視間隔」を想定される遅延時間以上に設定しておくことが考えられます。
もう1つは、データベースプロバイダの実装に依存した方法です。例えば、Oracleでは"SELECT 〜 FOR UPDATE [WAIT | NOWAIT]"という明示的な行ロックを行えるSQLを提供しています。これを応答メッセージを受け付けるまでの間、XAトランザクションに連携させることで二重処理を回避します。

[関連する設定項目]

XAトランザクションを利用するためには、エンドポイント単位の設定項目「トランザクション」で行います。サービスアセンブリ開発時にサービスユニット内に設定します。

5.2.8.4. JDBCデータソースのチューニング

利用するJDBCデータソースの設定を適切にする必要があります。

[関連する設定項目]

詳細は、WebOTXマニュアルの[ Application Server > 高度な管理と運用サイクルガイド > 2. チューニング > 2.7. JDBCデータソース ] を参照してください。

5.2.9. FTP BC

FTP BCを利用する場合の性能チューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

以下はFTP BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.9a】FTP BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1.1Endpointの流量制御  エンドポイント:「エンドポイント単位の同時処理最大リクエスト数」
1.21プロセスのInboundスレッドで同時処理最大ファイル数  コンポーネント:「1プロセスのInboundスレッドで同時処理最大ファイル数」
1.3マルチプロセスのInboundで同時処理最大ファイル数  コンポーネント:「マルチプロセスのInboundで同時処理最大ファイル数」
2Outboundのスレッド数を設定します。 Queueにメッセージが滞留している場合コンポーネント:「アウトバウンドのスレッド数」
3書き込み制御世代数  エンドポイント:出力ファイルの世代数
4Outbound返信用のワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.2.9a】FTP BCのチューニングポイントの説明


5.2.9.1. 直接転送を有効にする

ESBを経由せず、メッセージをFTPサーバ間で直接転送するかを指定する項目です。 true(直接転送する)の方が性能面で有利ですが、ESB内でファイル内の情報を扱えなくなります。例えば、ファイル内容に基づいたルーティングなどは行えません。既定値は false です。

[関連する設定項目]


5.2.9.2. 監視間隔

FTPサーバのディレクトリをポーリングする間隔です。短く設定することでリアルタイム性が向上しますが、FTPサーバからファイルを取得した後の処理が過負荷になることが考えられます。

[関連する設定項目]


5.2.9.3. アウトバウンドのスレッド数

アウトバウンドで起動させるスレッド数を指定する項目です。1に設定することでメッセージ処理の順序保証が可能ですが、性能面で問題となる場合があります。順序性が求められない場合は、多重度をあげることで性能向上が期待できます。

[関連する設定項目]


5.2.10. HTTP BC

HTTP BCを利用する場合の性能チューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

Webサーバを使用する場合は、併せてWebサーバのチューニングが必要になります。Webサーバについては [ アプリケーションサーバマニュアル > ドメイン構築・基本設定ガイド > 7.WebOTXの内部サービス > 7.6.WebOTX Webサーバ ] を参照してください。

以下はHTTP BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.10a】HTTP BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1Webサーバのスレッド数を設定します。 クライアント数が増加し、接続できない場合ご利用のWebサーバのチューニング方法に従い、設定してください。
2-1AJPリスナを設定します。(Express、またはStandard以上のシングルプロセスモード)  WebOTXマニュアルのチューニングをご確認ください。
2-2IIPOリスナを設定します。(Standard以上のマルチプロセスモード)  WebOTXマニュアルのチューニングをご確認ください。
3Inboundの受信用スレッド数を設定します。Webコンテナのスレッドを利用しており、リクエストを受けるたびに1つ消費します。 Endpointの流量制御が必要な場合WebOTXマニュアルのチューニングをご確認ください。
4EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
5Outbound、およびInbound返信用のワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」
6HTTPチューニングパラメータ Keep-alive, Expect-contineなどが必要な場合ProviderのEndpointの各種設定項目

【表5.2.10a】HTTP BCのチューニングポイントの説明


5.2.10.1. HTTP処理スレッド数のチューニング

HTTP BCのInboundはWebコンテナ上のHTTPリスナのスレッドで動作します。 そのため、HTTP BCにアクセスするクライアントの予想される多重度に合わせて、WebコンテナのHTTP処理スレッド数を調節します。

[関連する設定項目]


5.2.11. Proxy BC

Proxy BCに特有な性能チューニングはありません。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。


5.2.12. TCP/IP BC

TCP/IP BCを利用する場合の性能チューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

以下はTCP/IP BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.12a】TCP/IP BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1Endpoint流量制御 Endpointの流量制御が必要な場合エンドポイント:「エンドポイント単位の同時処理最大リクエスト数」
2クライアントアプリケーションとInbound間コネクション数。コネクションとスレッドプール内のスレッドが一対一で対応します。 同時接続コネクション数を制限したいときエンドポイント:「最大コネクション数」
3EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
4Outboundのワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」
5コネクションプールサイズ エンドポイント:「最大プールサイズ」、「最小プールサイズ」、「初期プールサイズ」

【表5.2.12a】TCP/IP BCのチューニングポイントの説明


5.2.12.1. 最大コネクション数

TCP/IP BCのInboundは接続するコネクションの最大数を設定可能です。 TCP/IP BCのInboundにアクセスするクライアントの予想される多重度に合わせて、最大コネクション数を調節します。

[関連する設定項目]


5.2.12.2. コネクションプールサイズ

TCP/IP BCのOutboundはサーバアプリケーションとの接続をキープするコネクション数を設定可能です。 最小プールサイズを値を十分大きくするとコネクションを再利用することができコネクション確立のコストを 抑えることができますが、プールサイズを大きくしすぎると大量のコネクションをキープするのでリソースを消費してしまいます。 また最大プールサイズを超えてコネクションの確立は行いません。 TCP/IP BCのOutboundが同時アクセスする予想される多重度に合わせて、最大コネクション数、最小コネクション数を調節します。

[関連する設定項目]


5.2.13. Salesforce BC

Salesforce BCを利用する場合の性能チューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント ] を参照してください。

Webサーバを使用する場合は、併せてWebサーバのチューニングが必要になります。Webサーバについては [ アプリケーションサーバマニュアル > ドメイン構築・基本設定ガイド > 7.WebOTXの内部サービス > 7.6.WebOTX Webサーバ ] を参照してください。

以下はSalesforce BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.13a】Salesforce BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1Webサーバのスレッド数を設定します。 クライアント数が増加し、接続できない場合ご利用のWebサーバのチューニング方法に従い、設定してください。
2-1AJPリスナを設定します。(Express、またはStandard以上のシングルプロセスモード)  WebOTXマニュアルのチューニングをご確認ください。
2-2IIPOリスナを設定します。(Standard以上のマルチプロセスモード)  WebOTXマニュアルのチューニングをご確認ください。
3Inboundの受信用スレッド数を設定します。Webコンテナのスレッドを利用しており、リクエストを受けるたびに1つ消費します。 Endpointの流量制御が必要な場合WebOTXマニュアルのチューニングをご確認ください。
4EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
5Outbound、およびInbound返信用のワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」
6HTTPチューニングパラメータ Keep-alive, Expect-contineなどが必要な場合ProviderのEndpointの各種設定項目

【表5.2.13a】Salesforce BCのチューニングポイントの説明


5.2.13.1. XML処理方式の選択

Salesforce BCでは、内部で用いるXML処理の方式をDOMとSAXから選択できます。 基本的にSAXは高速かつ低メモリで処理が可能ですが、接続するBC/SEに応じてDOMの方が高速になることがあります。 具体的には、CORBA BC、RMI BC、JDBC BCは内部でDOM処理を行いますので、Salesforce BCからこれらのBCへ接続する場合はDOMとした方が高速となる可能性が高くなります。 また、Salesforceメッセージのバージョンが1.2の場合、およびSOAP Header内に要素がある場合は、設定に関係なくDOMで処理を行います。

[関連する設定項目]



5.2.13.2. HTTP処理スレッド数のチューニング

Salesforce BCのInboundはWebコンテナ上のHTTPリスナのスレッドで動作します。 そのため、Salesforce BCにアクセスするクライアントの予想される多重度に合わせて、WebコンテナのHTTP処理スレッド数を調節します。

[関連する設定項目]


5.2.14. HL7 BC

HL7 BCを利用する場合の性能チューニングについて説明します。 各BCで共通のチューニングは[ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。

以下はHL7 BCのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.2.14a】HL7 BCのチューニングポイントの全体図


番号説明チューニング観点設定場所
1Endpoint流量制御 Endpointの流量制御が必要な場合エンドポイント:「エンドポイント単位の同時処理最大リクエスト数」
2クライアントアプリケーションとInbound間コネクション数。コネクションとスレッドプール内のスレッドが一対一で対応します。 同時接続コネクション数を制限したいときエンドポイント:「最大コネクション数」
3EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
4Outboundのワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」
5コネクションプールサイズ エンドポイント:「最大プールサイズ」、「最小プールサイズ」、「初期プールサイズ」

【表5.2.14a】HL7 BCのチューニングポイントの説明


5.2.14.1. 最大コネクション数

HL7 BCのInboundは接続するコネクションの最大数を設定可能です。 HL7 BCのInboundにアクセスするクライアントの予想される多重度に合わせて、最大コネクション数を調節します。

[関連する設定項目]


5.2.14.2. コネクションプールサイズ

HL7 BCのOutboundはサーバアプリケーションとの接続をキープするコネクション数を設定可能です。 最小プールサイズを値を十分大きくするとコネクションを再利用することができコネクション確立のコストを 抑えることができますが、プールサイズを大きくしすぎると大量のコネクションをキープするのでリソースを消費してしまいます。 また最大プールサイズを超えてコネクションの確立は行いません。 HL7 BCのOutboundが同時アクセスする予想される多重度に合わせて、最大コネクション数、最小コネクション数を調節します。

[関連する設定項目]


5.3. サービスエンジン

5.3.1. 共通

サービスエンジンにおいても、チューニング項目はバインディングコンポーネントと共通です。 [ 5.2. バインディングコンポーネント > 5.2.1. 共通 ] を参照してください。


以下はXSLT/Sequencing/CBR/UserProcessor SEのチューニングポイントを表した図とチューニングポイントの説明です。

【図5.3.1a】Service Engineのチューニングポイントの全体図


番号説明チューニング観点設定場所
1EventManagerのスレッド数を設定します。EventMangerはNMRのQueueからメッセージを取り出し、ワーカスレッドへ割り当てます。 Queueにメッセージが滞留している場合コンポーネント:「EventManagerスレッド数」
2ワーカスレッド数を設定します。 大量メッセージを受信する場合コンポーネント:「最大スレッド数」、「最小スレッド数」

【表5.3.1a】Service Engineのチューニングポイントの説明

5.3.2. XSLT SE

XSLT SEを利用する場合の性能チューニングについて説明します。

5.3.2.1. メモリ上での実行の可否

XSLT変換をメモリ上で実行するかどうか選択します。 trueの方が性能面で有利ですが、大容量のファイルを扱うときにメモリ不足などの問題が発生する可能性があります。既定値は trueです。

[関連する設定項目]


5.3.3. Sequencing SE

Sequencing SEに特有な性能チューニングはありません。



5.3.4. CBR SE

CBR SEに特有な性能チューニングはありません。


5.3.5. UserProcessor SE

UserProcessor SEに特有な性能チューニングはありません。