WebOTX Manual V10.3 (第4版) 目次を表示

---

6. チューニング

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

6.1. WebOTX ESB全体

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

6.1.1. DocumentBuilder数

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

[関連する設定項目]

• woesb.DocumentBuilderPoolSizeプロパティ
  <ドメインルート>/config/domain.xmlファイル中で、woesb.DocumentBuilderPoolSizeプロパティの値により設定します。プロパティ値を設定しない場合のデフォルトプールサイズは50です。例ではプールサイズを200に設定しています。

  otxadmin> set domain.applications.lifecycle-module.JBIFramework.property.woesb\\.DocumentBuilderPoolSize=200

  このプロパティに適切ではない値を設定しても正常動作ができなくなることはありません。しかし、設定したプールサイズを越えてDocumentBuilderオブジェクトを利用しようとした場合は、プールからではなく新たにDocumentBuilderオブジェクトが生成され、若干の性能劣化が発生します。また、プールサイズを大きく設定した場合は、その分だけJVMヒープメモリを消費します。そのため、最適な性能を得るにはSOAP BCやハンドラで同時にXML処理するプロセス数を考慮して適切に値を設定する必要があります。

6.1.2. メッセージログ

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

[関連する設定項目]

6.1.3. プロセスグループのプロセス数（Standardの場合のみ）

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

[関連する設定項目]

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

6.2.1. 共通

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

6.2.1.1. ログレベル

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

[関連する設定項目]

6.2.1.2. モニタレベル

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

[関連する設定項目]

6.2.1.3. 最大スレッド数／最小スレッド数

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

[関連する設定項目]

6.2.1.4. EventManagerスレッド数（FTP BC は除く）

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

[関連する設定項目]

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

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

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

[関連する設定項目]

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

6.2.2. SOAP BC

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

Webサーバを使用する場合は、併せてWebサーバのチューニングが必要になります。Webサーバについては [ WebOTX Webサーバ ] を参照してください。

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

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

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

6.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で処理を行います。

[関連する設定項目]

• XML処理タイプ
  SOAP BCのサービスユニットエディタで、項目"XML処理タイプ"をDOMおよびSAXから選択します。

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

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

[関連する設定項目]

• HTTPリスナの「最大プロセッサ数」および「最小プロセッサ数」
  Webコンテナのチューニングの具体的な操作はWebOTXマニュアルの[ Webコンテナ ] を参照してください。

6.2.3. JMS BC

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

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

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

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

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

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

6.2.3.1. JMSのチューニング

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

[関連する設定項目]

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

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

[関連する設定項目]

6.2.4. JCA BC

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

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

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

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

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

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

[関連する設定項目]

• NMRからのレスポンス
  
• メッセージ交換時の送信タイムアウト時間
  詳細は、WebOTXマニュアルの[ アプリケーション開発ガイド（Enterprise Service Bus） > 2.9. バインディングコンポーネントの定義 > 2.9.3. JCAバインディング ] を参照してください。

6.2.5. RMI BC

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

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

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

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

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

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

[関連する設定項目]

6.2.6. File BC

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

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

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

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

6.2.7. CORBA BC

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

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

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

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

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

[関連する設定項目]

6.2.8. JDBC BC

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

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

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

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

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

[関連する設定項目]

6.2.8.2. 処理能力の向上

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

[関連する設定項目]

6.2.8.3. 二重処理の抑止

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

[関連する設定項目]

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

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

[関連する設定項目]

6.2.9. FTP BC

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

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

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

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

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

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

[関連する設定項目]

• 直接転送を有効にする
  直接転送を有効にするにはFTP BCのサービスユニットエディタで、項目"直接転送を有効にする"をtrueに設定します。 既定値はfalseです。

6.2.9.2. 監視間隔

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

[関連する設定項目]

• 監視間隔
  FTP BCのサービスユニットエディタの項目"監視間隔"で設定します。

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

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

[関連する設定項目]

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

6.2.10. HTTP BC

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

Webサーバを使用する場合は、併せてWebサーバのチューニングが必要になります。Webサーバについては [ WebOTX Webサーバ ] を参照してください。

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

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

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

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

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

[関連する設定項目]

• HTTPリスナの「最大プロセッサ数」および「最小プロセッサ数」
  Webコンテナのチューニングの具体的な操作はWebOTXマニュアルの[ Webコンテナ ] を参照してください。

6.2.11. Proxy BC

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

6.2.12. TCP/IP BC

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

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

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

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

6.2.12.1. 最大コネクション数

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

[関連する設定項目]

• 「最大コネクション数」
  コネクションの最大数を設定します。数値(0〜2147483647)。

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

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

[関連する設定項目]

• 「最大プールサイズ」および「最小プールサイズ」
  コネクションの最大数（最小数）を設定します。数値(0〜2147483647)。

6.2.13. Salesforce BC

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

Webサーバを使用する場合は、併せてWebサーバのチューニングが必要になります。Webサーバについては [ WebOTX Webサーバ ] を参照してください。

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

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

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

6.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で処理を行います。

[関連する設定項目]

• XML処理タイプ
  Salesforce BCのサービスユニットエディタで、項目"XML処理タイプ"をDOMおよびSAXから選択します。

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

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

[関連する設定項目]

• HTTPリスナの「最大プロセッサ数」および「最小プロセッサ数」
  Webコンテナのチューニングの具体的な操作はWebOTXマニュアルの[ Webコンテナ ] を参照してください。

6.2.14. HL7 BC

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

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

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

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

6.2.14.1. 最大コネクション数

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

[関連する設定項目]

• 「最大コネクション数」
  コネクションの最大数を設定します。数値(0〜2147483647)。

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

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

[関連する設定項目]

• 「最大プールサイズ」および「最小プールサイズ」
  コネクションの最大数（最小数）を設定します。数値(0〜2147483647)。

6.2.15. Transport BC

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

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

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

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

6.2.16. SAP BC

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

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

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

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

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

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

[関連する設定項目]

• 「SAPシステム登録」操作における「コネクションプールの最大接続数」、「接続可能なコネクションの最大数」

6.3. サービスエンジン

6.3.1. 共通

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

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

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

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

6.3.2. XSLT SE

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

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

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

[関連する設定項目]

• メモリ上での実行の可否
  この設定は統合運用管理ツールを用いて行います。具体的な操作は[ リファレンス集 運用管理・設定・構成編 > 1. コンフィグレーション > 1.4. サービスエンジンに関する設定 > 1.4.1. XSLT SE ] を参照してください。

6.3.3. Sequencing SE

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

6.3.4. CBR SE

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

6.3.5. UserProcessor SE

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