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

[アーティクル]
07/21/2023

次の推奨事項を使用して、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 コンピューター上で優先度の高いアプリケーションを実行しているホストの配置に対応します。

注意

追加のホストインスタンスを作成することには利点がありますが、作成されるホストインスタンスが多すぎると、潜在的な欠点もあります。各ホストインスタンスは Windows サービス (BTSNTSvc.exe) であり、MessageBox データベースに対して追加の負荷を生成し、コンピューターリソース (CPU、メモリ、スレッドなど) を消費します。

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

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

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

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

HAT 追跡データは、MessageBox データベースから BizTalk Tracking データベースに移動されません。
BAM 追跡データは、MessageBox データベースから BAM プライマリインポートデータベースに移動されません。
データは移動されないため、MessageBox データベースから削除することはできません。
追跡データデコードサービスが停止しても、追跡インターセプターは引き続き発生し、追跡データは MessageBox データベースに書き込まれます。データが移動されないと、MessageBox データベースが肥大化し、時間の経過と同時にパフォーマンスに影響します。カスタムプロパティが追跡されない場合や BAM プロファイルが設定されていない場合でも、既定では、一部のデータ (パイプラインの受信/送信イベント、オーケストレーションイベントなど) が追跡されます。 Tracking Data Decode サービスを実行しない場合は、インターセプターがデータベースにデータを保存しないように、すべての追跡をオフにします。グローバル追跡を無効にするには、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 データベースのデータを移動する追跡ホストインスタンスが複数存在することはありません。たとえば、MessageBox データベースが 3 つあり、追跡ホストインスタンスが 2 つだけの場合、ホストインスタンスの 1 つは、2 つの MessageBox データベースのデータを移動する必要があります。 3 番目の追跡ホストインスタンスを追加すると、追跡ホストの作業が、BizTalk Serverを実行している別のコンピューターに配布されます。このシナリオでは、4 番目の追跡ホストインスタンスを追加しても、追跡ホストの作業は分散されませんが、フォールトトレランスのために追加の追跡ホストインスタンスが提供されます。

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

注意

maxconnection パラメーターの値を、呼び出される Web サーバーが HTTP 接続で圧倒されるような大きな値に増やさないでください。 maxconnection パラメーターの値を変更した後、各宛先 Web サーバーに要求を送信してストレステストを実行し、適切なパフォーマンスを提供する maxconnection の値を決定し、HTTP はターゲット Web サーバーを圧倒することなく送信します。

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

<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 ヘルプ」の「HTTP アダプターのパフォーマンスに影響を与える可能性がある https://go.microsoft.com/fwlink/?LinkID=154200 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 or ASP.NET Apps v4.0.30319 \Request Execution Time パフォーマンスカウンターが異常に高くなっています。
- ASP.NET Apps v2.0.50727\Request Wait Time or 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 アプリケーションから Web サービス要求を行うときの競合、パフォーマンスの低下、デッドロック 821268マイクロソフトサポート技術情報の記事 (https://go.microsoft.com/fwlink/?LinkID=144169) を参照してください。

統合モードで実行されている 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 値を設定する

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

警告

レジストリエディターは、各自の責任で使用してください。正しく使用しないと、オペレーティングシステムを再インストールする必要がある問題が発生する可能性があります。レジストリをバックアップ、復元、変更する方法の詳細については、「 Microsoft サポート技術情報の記事 256986 - 上級ユーザー向けの Windows レジストリ情報」を参照してください。

[スタート] メニューの [実行] プロンプトを見つけて起動し、「regedit.exe」と入力し、[OK] を選択してレジストリエディターを起動します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0 に移動する
次の手順に従ってキーを作成します。
1. [ 編集 ] メニューの [ 新規作成] を選択し、[キー] を選択 します。
2. 「maxConcurrentRequestsPerCPU」と入力し、Enter キーを押します。
3. maxConcurrentRequestsPerCPU キーの下に、maxConcurrentRequestsPerCPU の新しい値を持つ DWORD エントリを作成します。
4. レジストリエディターを閉じます。

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

Microsoft .NET Framework 3.5 Service Pack 1 をダウンロードしてインストールします。これは、構成ファイルで次の値を設定するために必要です。フルバージョンも利用できます。
アプリケーションプールの aspnet.config ファイルを開きます。
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 です。これは非常に大きな数であるため、多数の非同期要求を同時に実行できます。詳細については、「applicationPool> 要素 (Web 設定)」 () を参照してください<。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 値を設定する

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

警告

[スタート] メニューの [実行] プロンプトを見つけて起動し、「regedit.exe」と入力し、[OK] を選択してレジストリエディターを起動します。
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\4.0.30319.0に移動します。
次の手順に従ってキーを作成します。
1. [ 編集 ] メニューの [ 新規作成] を選択し、[キー] を選択 します。
2. 「maxConcurrentRequestsPerCPU」と入力し、Enter キーを押します。
3. maxConcurrentRequestsPerCPU キーの下に、maxConcurrentRequestsPerCPU の新しい値を持つ DWORD エントリを作成します。
4. レジストリエディターを閉じます。

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

構成ファイルで次の値を設定するために必要な Microsoft .NET Framework 4 をダウンロードしてインストールします。
アプリケーションプールの aspnet.config ファイルを開きます。
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 コンピューターで過剰なスレッド割り当てが発生し、MessageBox データベースで過剰なロック競合が発生する可能性があります。

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

注意

ワーカースレッド はキューに登録された作業項目を処理するために使用され、 I/O スレッド は I/O 完了ポートに関連付けられた専用のコールバックスレッドであり、完了した非同期 I/O 要求を処理します。

スレッドの設定	既定値	推奨値
最大 IO スレッド数	250	250
ワーカースレッドの最大数	25	100 重要: この値を 100 を超えると、BizTalk Server MessageBox データベースをホストしているSQL Server コンピューターのパフォーマンスに悪影響を及ぼす可能性があります。この問題が発生した場合、SQL Server でデッドロック状態が発生することがあります。このパラメーターを 100 を超えて増やしないことをお勧めします。
最小 IO スレッド数	25	25
最小ワーカースレッド数	5	25

注意

推奨される値は絶対値ではなく、BizTalk アプリケーションによっては調整が必要になる場合があります。一度に 1 つのパラメーターを変更し、追加の変更を行う前に、BizTalk プラットフォームのパフォーマンスと安定性への影響を測定します。

注意

これらの値には、サーバー上のプロセッサの数が暗黙的に乗算されます。たとえば、 MaxWorkerThreads エントリを 100 の値に設定すると、4 つの CPU サーバーで実際には 400 の値が設定されます。

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

データを MessageBox データベースに書き込み、BizTalk Tracking データベースに非同期的に移動する必要がある場合、追跡では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 が複雑なマッピング操作を実行するときに、一時場所を使用してファイルをディスクにストリーミングするためです。

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

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

参照

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

次の方法で共有

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

MSDTC の構成

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

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

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

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

maxconnection パラメーターの値を変更して、許可される HTTP 同時接続の数を増やす

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参照

フィードバック

フィードバック

その他のリソース

次の方法で共有

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

MSDTC の構成

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

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

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

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

maxconnection パラメーターの値を変更して、許可される HTTP 同時接続の数を増やす

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参照

フィードバック

フィードバック

その他のリソース

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

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

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

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

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

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

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

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