BizTalk Server の一般的な最適化 - パート 1

BizTalk Server のパフォーマンスを向上させるには、次の推奨事項を使用できます。 このトピックに記載されている最適化は、BizTalk Server をインストールして構成した後に適用されます。

MSDTC を構成する

SQL Server と BizTalk Server の間のトランザクションを容易にするには、Microsoft 分散トランザクション コーディネーター (MS DTC) を有効にする必要があります。 BizTalk Server で MSDTC を構成するには、 オペレーティング システムのパフォーマンス向上に関する一般的なガイドラインに関するトピックを参照してください。

BizTalk Server ホストを構成するための推奨事項

このセクションでは、BizTalk Server ホストを構成するための推奨事項について説明します。

複数の BizTalk Server ホストを作成し、機能別にホスト インスタンスを分離する

次のガイドラインに従って、複数の BizTalk Server ホストを作成し、それらのホストにワークロードを割り当てます。

• 送信、受信、処理、追跡機能用に個別のホストを作成します。 複数の BizTalk ホストを作成すると、BizTalk グループでワークロードを構成する際に柔軟性が得られます。これは、BizTalk グループ内の BizTalk Server を実行しているコンピューター間で処理を分散する主な手段です。 複数のホストを使用すると、他のホストに影響を与えることなく、1 つのホストを停止できます。 たとえば、メッセージの送信を停止して、別のホスト インスタンスで実行されている受信アダプターが受信メッセージを受信できるようにしながら、メッセージ ボックス データベースでキューに入れるようにすることができます。 ホスト インスタンスを機能別に分離すると、次の利点もあります。

  • 複数の BizTalk ホストを実行すると、各ホストに MessageBox データベース内の独自の作業キュー テーブルが割り当てられるため、MessageBox データベース のホスト キュー テーブルの競合が軽減されます。

  • スロットリングは、ホスト レベルで BizTalk Serverで実装されています。 これにより、ホストごとに異なる調整特性を設定できます。

  • セキュリティはホスト レベルで実装されます。各ホストは、個別の Windows ID で実行されます。 これにより、たとえば、他のホストがファイル共有にアクセスすることを許可せず、Host_A FileShare_Bへのアクセスを許可できます。

• 各ホスト インスタンスには、.NET スレッド プール内のメモリ、ハンドル、スレッドなどの独自のリソース セットがあります。 ホスト間でワークロードを割り当てる場合は、同じホストにまとめてスケーリングするリソースを配置することを検討してください。

• 異なるホスト内のリソースの優先順位が異なるアダプターとオーケストレーションを分離します。 この手法は、専用の BizTalk Server コンピューターで優先度の高いアプリケーションを実行しているホストの配置に対応します。

BizTalk Server ホストプロパティの変更の詳細については、BizTalk Server 2010 ヘルプの 「ホストのプロパティ (https://go.microsoft.com/fwlink/?LinkID=154359) を変更する方法」を参照してください。

専用の追跡ホストを構成する

BizTalk Server はスループット用に最適化されているため、主要なオーケストレーションエンジンとメッセージングエンジンは、ビジネスプロセスを実行するという主要な作業から注意が逸れるのを避けるため、メッセージを BizTalk 追跡データベースや BAM データベースに直接移動することはありません。 代わりに、BizTalk Server はメッセージ ボックス データベースにメッセージを残し、BizTalk 追跡データベースへの移動が必要なメッセージとしてマークします。 その後、バックグラウンド プロセス (追跡ホスト) によって、メッセージが BizTalk 追跡および BAM データベースに移動されます。 追跡はリソースを大量に消費する操作であるため、追跡専用の別のホストを作成する必要があるため、メッセージ処理専用のホストに対する追跡の影響を最小限に抑えます。 最適なパフォーマンスを得られるように、MessageBox データベースごとに追跡ホスト インスタンスが少なくとも 1 つ必要です。 追跡ホスト インスタンスの実際の数は N + 1 にする必要があります。N は MessageBox データベースの数です。 "+ 1" は、追跡をホストしているコンピューターの 1 つが失敗した場合に備え、冗長性を確保するためのものです。

専用の追跡ホストを使用すると、BizTalk Server の追跡を妨げることなく、他の BizTalk ホストを停止することもできます。 メッセージ ボックス データベースからの追跡データの移動は、正常な BizTalk Server システムにとって非常に重要です。 BizTalk グループ内の追跡データの移動を担当する BizTalk ホストが停止した場合、追跡データ デコード サービスは実行されません。 この影響は次のとおりです。

• HAT 追跡データは、メッセージ ボックス データベースから BizTalk 追跡データベースに移動されません。

• BAM 追跡データは、メッセージ ボックス データベースから BAM プライマリ インポート データベースに移動されません。

• データは移動されないため、MessageBox データベースから削除することはできません。

• 追跡データ デコード サービスが停止しても、追跡インターセプターは引き続き起動し、追跡データを MessageBox データベースに書き込みます。 データが移動されない場合、メッセージ ボックス データベースが肥大化し、時間の経過と同時にパフォーマンスに影響します。 カスタム プロパティが追跡されていない場合や BAM プロファイルが設定されていない場合でも、既定では、一部のデータ (パイプラインの受信/送信イベントやオーケストレーション イベントなど) が追跡されます。 追跡データ デコード サービスを実行しない場合は、すべての追跡をオフにして、インターセプターがデータベースにデータを保存しないようにします。 グローバル追跡を無効にするには、「BizTalk Server 2010 ヘルプでグローバル追跡 (https://go.microsoft.com/fwlink/?LinkID=154193) を無効にする方法」を参照してください。 BizTalk Server 管理コンソールを使用して、追跡イベントを選択的に無効にします。

  追跡ホストは、BizTalk Server を実行している少なくとも 2 台のコンピューターで実行する必要があります (1 台が失敗した場合の冗長性のため)。 最適なパフォーマンスを得られるように、MessageBox データベースごとに少なくとも 1 つの追跡ホスト インスタンスが必要です。 追跡ホスト インスタンスの実際の数は (N + 1) にする必要があります。N は MessageBox データベースの数です。 "+ 1" は、追跡をホストしているコンピューターの 1 つが失敗した場合に備え、冗長性を確保するためのものです。

  追跡ホスト インスタンスは、特定の MessageBox データベースの追跡データを移動しますが、特定の MessageBox データベースのデータを移動する追跡ホスト インスタンスが複数存在することはありません。 たとえば、3 つの MessageBox データベースがあり、追跡ホスト インスタンスが 2 つだけの場合、ホスト インスタンスの 1 つは、2 つの MessageBox データベースのデータを移動する必要があります。 3 番目の追跡ホスト インスタンスを追加すると、追跡ホストの作業が BizTalk Server を実行している別のコンピューターに配布されます。 このシナリオでは、4 番目の追跡ホスト インスタンスを追加しても、それ以上の追跡ホスト作業は分散されませんが、フォールト トレランスのために追加の追跡ホスト インスタンスが提供されます。

  BAM イベント バス サービスの詳細については、BizTalk Server 2010 ヘルプの次のトピックを参照してください。

• BAM イベント バス サービス (https://go.microsoft.com/fwlink/?LinkID=154194) の管理。

• BAM イベント バス サービス (https://go.microsoft.com/fwlink/?LinkID=154195) のインスタンスの作成。

必ず必要な場合を除き、BizTalk ホストをクラスター化しないでください

BizTalk Server 2010 では BizTalk ホストをクラスター リソースとして構成できますが、これは、複数の BizTalk コンピューター間でホストできないリソースに高可用性を提供する必要がある場合にのみ考慮する必要があります。 たとえば、FTP プロトコルではファイル ロックが提供されないため、FTP アダプターを使用するポートは 1 つのホスト インスタンスにのみ存在する必要があります。 ただし、これにより単一障害点が発生し、クラスタリングのメリットが得られる可能性があります。 ファイル、SQL、HTTP、ホストのみの処理などのアダプターを含むホストは、コンピューター間で内部的に負荷分散でき、クラスタリングの利点はありません。

maxconnection パラメーターの値を変更して、許可される HTTP コンカレント接続の数を増やす

既定では、HTTP アダプター (WCF ベースの HTTP アダプターを含む) は、BizTalk Server を実行している各コンピューターから特定の宛先サーバーへの 2 つの同時 HTTP 接続のみを開きます。

この設定は、HTTP 1.1 仕様の IETF RFC に準拠しており、ユーザー シナリオには適していますが、高スループットには最適化されていません。 この設定により、各サーバーへの送信 HTTP 呼び出しが、BizTalk Server を実行している各コンピューターからの 2 つの同時送信に効果的に調整されます。

同時接続の数を増やすには、BizTalk Server 構成ファイルの maxconnection パラメーターの値を、各 BizTalk Server の BTSNTSvc.exe.config (または 64 ビット ホストの場合は BTSNTSvc64.exe.config) に変更できます。 これは、呼び出される特定のサーバーに対して増やすことができます。 経験則として、maxconnection パラメーターの値は 12 * Web アプリケーションをホストしているコンピューター上の CPU またはコアの数に設定する必要があります。

最大接続数プロパティの構成例を次に示します。

<configuration>
  <system.net>
    <connectionManagement>
      <add address="http://www.contoso.com" maxconnection="24" />
      <add address="*" maxconnection="48" />
    </connectionManagement>
  </system.net>
</configuration>

maxconnection プロパティを設定する際には、HTTP、HTTPS、Web サイトの IP アドレス、およびポート番号を指定することができます。 その他の例を次に示します。

<add address="http://www.contoso.com" maxconnection="24" />
<add address="http://www.contoso.com:8080" maxconnection="24" />
<add address="http://<IP-address>" maxconnection="24" />

Web サービスの IIS と ASP.NET 設定のチューニングの詳細については、BizTalk Server 2010 ヘルプの「アダプターのパフォーマンス (https://go.microsoft.com/fwlink/?LinkID=154200) に影響する構成パラメーター」の「HTTP アダプターのパフォーマンスに影響を与える可能性がある ASP.NET 設定」セクションを参照してください。

分離された受信場所、バックエンド Web サービス、WCF サービスをホストできる Web アプリケーションの ASP.NET スレッドの使用状況または同時に実行される要求を管理する

分離された受信場所、バックエンド Web サービス、WCF サービスをホストする ASP.NET Web アプリケーションのワーカー スレッドと I/O スレッドの数 (クラシック モードの IIS 7.5 と IIS 7.0) または同時に実行される要求の数 (IIS 7.5 および 7.0 統合モード) は、次の条件で変更する必要があります。

• CPU 使用率は、ホスティング Web サーバーのボトルネックではありません。

• 〜の値

  • ASP.NET Apps v4.0.30319 \Request Wait Time または ASP.NET Apps v4.0.30319 \Request Execution Time のパフォーマンス カウンターが異常に高いです。

  • ASP.NET Apps v2.0.50727\Request Wait Time または ASP.NET Apps v2.0.50727\Request Execution Time のパフォーマンスカウンターが異常に高いです。

• Web アプリケーションをホストするコンピューターのアプリケーション ログに、次のようなエラーが生成されます。

  Event Type: Warning
  Event Source: W3SVC Event Category: None
  Event ID: 1013
  Date: 11/4/2010
  Time: 1:03:47 PM
  User: N/A
  Computer: <ComputerName>
  Description: A process serving application pool 'DefaultAppPool' exceeded time limits during shut down. The process id was '<xxxx>'
  

分離された受信場所、バックエンド Web サービス、およびクラシック モードで実行されている IIS 7.5 および IIS 7.0 上の WCF サービスをホストできる Web アプリケーションの ASP.NET スレッドの使用状況を管理する

クラシック モードで実行されている IIS 7.5 および IIS 7.0 サーバーの machine.config ファイルの autoConfig 値が true に設定されている場合、ASP.NET 2.0 と ASP.NET 4 は、関連付けられている IIS ワーカー プロセスに割り当てられているワーカー スレッドと I/O スレッドの数を管理します。

<processModel autoConfig="true" />

ASP.NET 2.0 および ASP.Net 4 Web アプリケーションのワーカー スレッドと I/O スレッドの数を手動で変更するには、関連付けられている machine.config ファイルを開き、 maxWorkerThreads パラメーターと maxIoThreads パラメーターの新しい値を入力します。

<!-- <processModel autoConfig="true" /> -->
    <processModel maxWorkerThreads="200" maxIoThreads="200" />

ASP.NET 2.0 Web アプリケーションの machine.config ファイルのチューニング パラメーターの詳細については、ASP.NET アプリケーション (821268 https://go.microsoft.com/fwlink/?LinkID=144169) から Web サービス要求を行うときの競合、パフォーマンスの低下、デッドロックに関するマイクロソフト サポート技術情報の記事を参照してください。

統合モードで実行されている IIS 7.5 および IIS 7.0 で分離された受信場所、バックエンド Web サービス、WCF サービスをホストできる、ASP.NET 2.0 Web アプリケーションに対して同時に実行される要求の数を管理する

ASP.NET 2.0 が IIS 7.5 および IIS 7.0 で統合モードでホストされている場合、スレッドの使用は、クラシック モードの IIS 7.5 および IIS 7.0 とは異なる方法で処理されます。 ASP.NET 2.0 が統合モードの IIS 7.5 と IIS 7.0 でホストされている場合、ASP.NET 2.0 では 、要求 を同時に実行する スレッド の数ではなく、同時に実行する要求の数が制限されます。 同期シナリオの場合、スレッドの数は間接的に制限されますが、非同期シナリオの場合、要求とスレッドの数は大きく異なる可能性があります。 統合モードで IIS 7.5 および IIS 7.0 で ASP.NET 2.0 を実行している場合、machine.config ファイル内の maxWorkerThreads パラメーターと maxIoThreads パラメーターは、実行中のスレッドの数を管理するために使用されません。 代わりに、 maxConcurrentRequestsPerCPU に指定された値を変更することで、同時に実行される要求の数を CPU あたり 12 の既定値から変更できます。 maxConcurrentRequestsPerCPU 値は、reqistry または aspnet.config ファイルの config セクションで指定できます。 maxConcurrentRequestsPerCPU の既定値を変更して、同時に実行される要求の数を制御するには、次の手順に従います。

レジストリで maxConcurrentRequestsPerCPU 値を設定する

この設定はグローバルであり、個々のアプリケーション プールまたはアプリケーションに対して変更することはできません。

1. [スタート] メニューから、[実行] プロンプトを見つけて起動し、「regedit.exe」と入力し、[OK] を選択してレジストリ エディターを起動します。

2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 に移動します

3. 次の手順に従ってキーを作成します。

   1. [編集] メニューで [新規] を選び、次に [キー] を選択します。

   2. maxConcurrentRequestsPerCPU と入力し、Enter キーを押します。

   3. maxConcurrentRequestsPerCPU キーの下に、maxConcurrentRequestsPerCPU の新しい値を持つ DWORD エントリを作成します。

   4. レジストリ エディターを閉じます。

aspnet.config ファイルの構成セクションで、アプリケーション プールの maxConcurrentRequestsPerCPU 値を設定します

1. 構成ファイルで次の値を設定するために必要な Microsoft .NET Framework 3.5 Service Pack 1 をダウンロードしてインストールします。 完全版も利用できます。

2. アプリケーション プールの aspnet.config ファイルを開きます。

3. maxConcurrentRequestsPerCPU パラメーターと requestQueueLimit パラメーターの新しい値を入力します。

   <system.web>
       <applicationPool maxConcurrentRequestsPerCPU="12" requestQueueLimit="5000"/>
   </system.web>
   

   注

   この値は、レジストリの maxConcurrentRequestsPerCPU に指定された値をオーバーライドします。 requestQueueLimit 設定は processModel/requestQueueLimit と同じですが、aspnet.config ファイルの設定は、machine.config ファイルの設定をオーバーライドします。

IIS 7.0 での ASP.NET スレッド使用量の構成の詳細については、IIS 7.0 での ASP.NET スレッドの使用状況に関する Thomas Marquardt のブログ (https://go.microsoft.com/fwlink/?LinkId=157518) を参照してください。

統合モードで実行されている IIS 7.5 および 7.0 で分離された受信場所、バックエンド Web サービス、WCF サービスをホストできる、ASP.NET 4 Web アプリケーションに対して同時に実行される要求の数を管理する

.NET Framework 4 では、maxConcurrentRequestsPerCPU の既定の設定は 5000 です。これは非常に大きな数であるため、多数の非同期要求を同時に実行できます。 詳細については、「https://go.microsoft.com/fwlink/?LinkID=205339」を参照してください。

IIS 7.5 および IIS 7.0 統合モードの場合、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0 内の MaxConcurrentRequestsPerCPU という名前の DWORD によって、CPU あたりの同時要求数が決まります。 既定では、レジストリ キーは存在せず、CPU あたりの要求数は 5000 に制限されています。

レジストリで maxConcurrentRequestsPerCPU 値を設定する

この設定はグローバルであり、個々のアプリケーション プールまたはアプリケーションに対して変更することはできません。

1. [スタート] メニューから、[実行] プロンプトを見つけて起動し、「regedit.exe」と入力し、[OK] を選択してレジストリ エディターを起動します。

2. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0に移動します。

3. 次の手順に従ってキーを作成します。

   1. [編集] メニューで [新規] を選び、次に [キー] を選択します。

   2. maxConcurrentRequestsPerCPU と入力し、Enter キーを押します。

   3. maxConcurrentRequestsPerCPU キーの下に、maxConcurrentRequestsPerCPU の新しい値を持つ DWORD エントリを作成します。

   4. レジストリ エディターを閉じます。

aspnet.config ファイルの構成セクションで、アプリケーション プールの maxConcurrentRequestsPerCPU 値を設定します

1. 構成ファイルで次の値を設定するために必要な Microsoft .NET Framework 4 をダウンロードしてインストールします。

2. アプリケーション プールの aspnet.config ファイルを開きます。

3. maxConcurrentRequestsPerCPU パラメーターと requestQueueLimit パラメーターに新しい値を入力します。

   次の例の値は既定値です。

   <system.web>
       <applicationPool maxConcurrentRequestsPerCPU="5000" requestQueueLimit="5000"/>
   </system.web>
   

   注

   この値は、レジストリの maxConcurrentRequestsPerCPU に指定された値をオーバーライドします。 requestQueueLimit 設定は processModel/requestQueueLimit と同じですが、aspnet.config ファイルの設定は、machine.config ファイルの設定をオーバーライドします。

BizTalk ホスト インスタンスの CLR ホスティング スレッド値を定義する

Windows スレッドは Windows プロセスで使用できる最も基本的な実行可能ユニットであるため、スレッド不足を防ぐために、BizTalk ホストのインスタンスに関連付けられている .NET スレッド プールに十分なスレッドを割り当てることが重要です。 スレッドの枯渇が発生した場合、要求された作業を実行するのに十分なスレッドがないため、パフォーマンスに悪影響を与えます。 同時に、ホストに関連付けられた .NET スレッド プールに、必要以上のスレッドを割り当てないように注意する必要があります。 ホストに関連付けられている .NET スレッド プールへのスレッドの割り当てが多すぎると、コンテキストの切り替えが増える可能性があります。 コンテキストの切り替えは、Windows カーネルが 1 つのスレッドの実行から別のスレッドに切り替えると発生し、パフォーマンス コストが発生します。 スレッドの割り当てが過剰になると、過剰なコンテキスト切り替えが発生し、全体的なパフォーマンスに悪影響を与える可能性があります。 BizTalk ホスト インスタンスの .NET スレッド プールに割り当てられるスレッドの既定の数は、インストールされている .NET Framework のバージョンによって異なります。 .NET Framework 4 と .NET Framework 3.5 SP1 によって既定値が大幅に増加し、BizTalk Server コンピューターでの過剰なスレッド割り当てや、メッセージ ボックス データベースでの過剰なロックの競合が発生する可能性があります。

BizTalk 設定ダッシュボードを使用すると、BizTalk ホストのインスタンスに関連付けられている .NET スレッド プールで使用できる Windows スレッドの数の既定値を変更できます。 .NET CLR 設定を変更する方法の詳細については、「 .NET CLR 設定を変更する方法 (https://go.microsoft.com/fwlink/?LinkID=205344)」を参照してください。 .NET CLR 設定はコアごとの CPU です。

BizTalk Server グループ レベルの追跡を無効にする

データをメッセージ ボックス データベースに書き込んだ後、BizTalk 追跡データベースに非同期的に移動する必要がある場合、BizTalk Server 内でパフォーマンスのオーバーヘッドが発生します。 運用環境の BizTalk Server 環境で追跡を構成する場合は、次の考慮事項が適用されます。

• 経験則として、追跡がビジネス要件でない場合は、グループレベルの追跡を無効にしてオーバーヘッドを削減し、パフォーマンスを向上させます。

  BizTalk Server グループ レベルの追跡を無効にするには、次の手順に従います。

  1. BizTalk Server 管理コンソールで、[BizTalk Server 管理] を展開し、[BizTalk グループ] を右クリックし、[設定] をクリックします。

  2. [BizTalk 設定ダッシュボード] ダイアログ ボックスの [グループ] ページで、[ グループ レベルの追跡を有効にする ] チェック ボックスをオフにします。

  3. [ OK] を クリックして変更を適用し、設定ダッシュボードを終了します。

• 必要に応じて、メッセージ本文の追跡のみを使用します。 メッセージのスループットとメッセージ サイズによっては、メッセージ本文の追跡によって大きなオーバーヘッドが発生する可能性があります。 BizTalk アクティビティの追跡には、デバッグと監査の利点は明らかですが、パフォーマンスとスケーラビリティにも大きな影響があります。 そのため、デバッグとセキュリティ上の理由から厳密に必要なデータのみを追跡し、冗長な情報の追跡を回避する必要があります。

• 既定では、オーケストレーションに対して次の追跡オプションが有効になっています。

  • オーケストレーションの開始と終了

  • メッセージの送受信

  • 図形の開始と終了

    オーケストレーション追跡オプション "Shape start and end" は大きなオーバーヘッドを発生させ、高スループットが必要な運用環境では有効にしないでください。 オーケストレーションの追跡オプションには、BizTalk 管理コンソールの [オーケストレーションのプロパティ] ダイアログ ボックスの [追跡 ] ページでアクセスできます。

  追跡の構成の詳細については、「 BizTalk Server 管理コンソールを使用した追跡の構成 (https://go.microsoft.com/fwlink/?LinkId=158021)」を参照してください。

高スループットのシナリオで、DTA 消去およびアーカイブ ジョブの消去期間を 7 日から 2 日に短縮する

既定では、BizTalk Server のデータを追跡するための消去間隔は 7 日に設定されています。 高スループットのシナリオでは、追跡データベース内のデータが過剰に蓄積され、最終的に MessageBox のパフォーマンスに影響を与え、メッセージ処理のスループットに悪影響を与える可能性があります。

高スループットのシナリオでは、ハードとソフトの消去間隔を既定の 7 日から 2 日に減らします。 消去間隔の構成の詳細については、BizTalk Server 2010 ヘルプの DTA の消去およびアーカイブ ジョブ (https://go.microsoft.com/fwlink/?LinkID=153814) を構成する方法を参照してください。

BizTalk サービス アカウントの %temp% パスが別のディスクまたは LUN を指すよう構成する

これは、BizTalk が複雑なマッピング操作を実行するときに、一時場所を使用してファイルをディスクにストリーミングするためです。

最新の Service Pack をインストールする

BizTalk Server と .NET Framework の両方の最新のサービス パックをインストールする必要があります。これらのサービス パックには、発生する可能性があるパフォーマンスの問題を修正できる修正プログラムが含まれています。

BizTalk Server ドキュメントのパフォーマンスの最適化

必要に応じて、BizTalk Server ドキュメントから次の推奨事項を適用します。

• MessageBox の待機時間に関する問題のトラブルシューティング (https://go.microsoft.com/fwlink/?LinkId=158019)

• パフォーマンスのボトルネックの特定 (https://go.microsoft.com/fwlink/?LinkID=154238)

• DBNETLIB 例外の回避 (https://go.microsoft.com/fwlink/?LinkID=155308)

• TCP/IP ポート不足の回避 (https://go.microsoft.com/fwlink/?LinkID=153240)

• EPM スレッド プール サイズの設定 (https://go.microsoft.com/fwlink/?LinkId=158020)

こちらもご覧ください

BizTalk Server のパフォーマンスの最適化