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

  • [アーティクル]

このトピックでは、適切な WCF アダプターまたはバインドの種類を選択するための推奨事項と、さまざまな WCF アダプター構成オプションを適用するためのガイダンスについて説明します。

使用する WCF アダプター、または使用する WCF-Custom/WCF-CustomIsolated バインドの種類を選択する際の考慮事項

  • メッセージのサイズが大きくなるため、厳密に必要でない場合は、メッセージ レベルのセキュリティを使用しないでください。 これにより、ソリューションの全体的なスループットを最小限に抑えることができます。

  • 使用する WCF アダプター、または使用する WCF-Custom/WCF-CustomIsolated バインディングの種類 を選択する場合は、互換性、パフォーマンス、ホスティング プラットフォーム、セキュリティ、サポートされるトランスポートなどのアプリケーション要件を慎重に検討してください。 以下に示すガイドラインは、WCF 全般に適用され、BizTalk Serverに固有のものではありません。

    • ASMX Web サービスを必要とする WebSphere Web サービスや .NET 1.1 アプリケーションなどのレガシ クライアントを WCF サービスでサポートする必要がある場合は、BasicHttpBinding を使用する必要があります。 BasicHttpBinding では既定ではセキュリティが実装されないため、メッセージまたはトランスポート セキュリティが必要な場合は、このバインディングで明示的に構成する必要があります。 BASICHttpBinding を使用して、ASMX ベースの Web サービスと、WS-I Basic Profile 1.1 に準拠するその他のサービスと通信できるエンドポイントを公開します。 トランスポート セキュリティを構成する場合、BasicHttpBinding は既定で、従来の ASMX Web サービスと同様に資格情報を使用しません。 BasicHttpBinding を使用すると、IIS 7.5 または IIS 7.0 で WCF サービスをホストできます。

    • インターネット経由で WCF クライアントによって WCF サービスが呼び出される場合は、WsHttpBinding を使用する必要があります。 WsHttpBinding は、ASMX Web サービスを必要とするレガシ クライアントをサポートする必要がないインターネット シナリオに適しており、WsHttpBinding では IIS 7.5 または IIS 7.0 で WCF サービスをホストできます。 レガシ クライアントをサポートする必要がある場合は、代わりに BasicHttpBinding を使用することを検討してください。 WSHttpBinding は、WCF 受信場所を公開する必要がある場合や、WS-Security や WS-AtomicTransactions などの WS-* プロトコルをサポートする送信ポートを採用する必要がある場合に使用する必要があります。

    • NetTcpBinding は、イントラネット内のクライアントをサポートする必要がある場合に最適な選択肢です。 NetTcpBinding は、トランスポート パフォーマンスが重要な場合や、IIS ではなく Windows サービスでサービスをホストすることが許容される場合に、イントラネット シナリオに適しています。 このバインディングは、.NET-to-.NET マシン間通信用のセキュリティで保護された信頼性の高いバインド環境を提供する場合に使用します。 NetTcpBinding は、Windows サービスまたは IIS 7.5/7.0 でホストされている必要があることに注意してください。

    • サービスと同じコンピューターで WCF クライアントをサポートする必要がある場合は、NetNamedPipeBinding を使用する必要があります。 このバインディングは、クロスプロセスの同一コンピューター通信用のセキュリティで保護された信頼性の高いバインディング環境を提供します。 NamedPipe プロトコルを使用する場合は、このバインドを使用します。 NetNamedPipeBinding は、Windows サービスまたは IIS 7.5/7.0 でホストされている必要があることに注意してください。

    • 切断されたキューをサポートする必要がある場合は、NetMsmqBinding を使用する必要があります。 キューは、メッセージ キュー (MSMQ とも呼ばれます) をトランスポートとして使用して提供されます。これにより、切断された操作、障害の分離、読み込みの平準化をサポートできます。 クライアントとサービスを同時にオンラインにする必要がない場合は、NetMsmqBinding を使用できます。 読み込み平準化を使用して、任意の数の受信メッセージを管理することもできます。 メッセージ キューでは、他のメッセージの処理に影響を与えずにメッセージが失敗する可能性があるエラー分離がサポートされています。 NetMsmqBinding は、Windows サービスまたは IIS 7.5/7.0 でホストされている必要があることに注意してください。

    • 双方向サービスをサポートする必要がある場合は、WsDualHttpBinding を使用する必要があります。 双方向サービスは、双方向メッセージ パターンを使用するサービスであり、サービスがコールバックを介してクライアントに通信する機能を提供します。 WsDualHttpBinding は、Windows サービスまたは IIS 7.5/7.0 でホストされている必要があることに注意してください。

WCF バインディングの比較

バインディングは、チャネル スタックを構成するためのメカニズムを提供します。 バインディングは、トランスポート チャネル、メッセージ エンコーダー、および一連のプロトコル チャネルを使用してチャネル スタックを構築するプロセスを作成します。 Windows Communication Foundation には、最も一般的な通信シナリオに対処するために事前に構成された多数の組み込みバインディングが付属しています。

バインド クラス名 トランスポート メッセージ エンコーディング セキュリティ モード 信頼できるメッセージ機能 トランザクション フロー (既定では無効)
BasicHttpBinding HTTP テキスト なし サポートされていません サポートされていません
WSHttpBinding HTTP Text Message 無効 WS-AtomicTransactions
NetTcpBinding TCP Binary トランスポート 無効 OleTransactions
NetNamedPipesBinding 名前付きパイプ Binary トランスポート サポートされていません OleTransactions
NetMsmqBinding MSMQ Binary Message サポートされていません サポートされていません
Custombinding 決定する 決定する 決定する 決定する 決定する

通信のニーズに基づいて特定のバインディングを選択できます。 次に例を示します。

  • BasicHttpBinding は、単純な Web サービスとの相互運用性を考慮して設計されています。 BasicHttpBinding では、トランスポートに HTTP を使用し、メッセージ エンコードにテキストを使用します。

  • WSHttpBinding は、さまざまな WS-* プロトコルを利用する可能性がある、より高度な Web サービスとの相互運用性を考慮して設計されています。 WSHttpBinding では、トランスポートに HTTP を使用し、メッセージ エンコードのテキストも使用します。

  • NetTcpBinding と NetNamedPipeBinding は、マシン間または同じコンピューター上の他の WCF アプリケーションとの効率的な通信と実行を目的として設計されています。

  • 実行時に 1 つまたは複数のカスタム プロトコル チャネルを使用して最大限の柔軟性が必要な場合は、 CustomBinding を 使用して、バインドを構成するバインド要素を決定できます。

Note

バインディングには、応答時間とスループットの観点から異なる特性があります。 そのため、パフォーマンスを向上させる一般的なアドバイスは、可能な場合は NetTcpBindind と NetNamesPipeBinding を使用することです。

TCP トランスポートとバイナリ メッセージ エンコードを使用して、WCF アダプターのスループットを最大化し、WCF アダプターの待機時間を最小限に抑える

可能な場合は、WCF-NetTcp アダプターを使用してスループットを最大化します。 WCF-NetTcp アダプターは、TCP/IP トランスポート プロトコルとバイナリ メッセージ エンコードを使用します。これにより、他の WCF-* アダプターと比較してパフォーマンスが向上します。

または、 customBinding バインドの種類を使用して、WCF-Custom (または受信場所用の WCF-CustomIsolated アダプター) を構成することもできます。 次に、 binaryMessageEncoding バインディング拡張機能を追加して、バイナリ メッセージ エンコードを実装し、TCP/IP をメッセージ トランスポート プロトコルとして実装する tcpTransport バインド拡張機能を追加します。 この方法は、必要なバインド要素のみを選択して構成し、BizTalk メッセージング エンジンの既定の動作を拡張するためのカスタム チャネルを作成できるため、非常に柔軟です。 customBinding バインドの種類を使用して WCF-Custom アダプターを実装する場合は、スループットを最大化し、待機時間を最小限に抑えるために、バインド拡張機能の構成パラメーターにこれらの値を指定します。

送信ポートの構成値:

設定 既定値 推奨値
TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint - 接続プールにキャッシュされる各エンドポイントの送信接続の最大数を取得または設定します。 これは、一意の各リモート エンドポイント用にキャッシュされる接続数を制限します。 アクティブなクライアント接続が増えてこの値を超えた場合、サービスはクライアントに対して応答していないように見える可能性があります。この値は、一意のリモート エンドポイントごとにキャッシュされる予想される接続の最大数に対応するように調整する必要があります。 このプロパティの詳細については、MSDN の TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint プロパティ (https://go.microsoft.com/fwlink/?LinkId=157737) を参照してください。 10 Try >= 20

受信ポートの構成値:

設定 .NET Framework 4 の既定値 .NET Framework 4 の推奨値 .NET Framework 3.5 の既定値 .NET Framework 3.5 の推奨値
TcpTransportBindingElement.MaxPendingAccepts - サービスへの受信接続の処理に使用できる保留中の非同期受け入れ操作の最大数を取得または設定します。 同時接続開始のレベルが高いシナリオでは、この値が不十分である可能性があり、 MaxPendingConnections プロパティと共に調整して、より高いレベルの同時クライアント接続試行を処理する必要があります。 ただし、サービスをホストするマシンが備えるプロセッサの数より大きい値をこのプロパティに設定する必要はありません。 このプロパティの詳細については、MSDN の ConnectionOrientedTransportBindingElement.MaxPendingAccepts プロパティ (https://go.microsoft.com/fwlink/?LinkId=157738) を参照してください。 1 2*ProcessorCount 1 Try >= 20
TcpTransportBindingElement.MaxPendingConnections - サービスでのディスパッチを待機している接続の最大数を取得または設定します。 この値は、同時にディスパッチを待機しているクライアント接続の数を制限します。 この値が小さすぎると、クライアントの接続試行がサービスによって拒否される可能性があります。 値が大きすぎる場合は、負荷が大きくなると、サービスの速度が低下したり、サービスがクライアントに応答しなくなったりする可能性があります。 このプロパティは、サービスが最大能力で実行できる値に設定し、それを超えないようにする必要があります。 スタック内の上位レイヤーが AcceptDispatch を呼び出すと、その接続はディスパッチを待機している接続のキューから削除されます。 このプロパティの詳細については、MSDN の ConnectionOrientedTransportBindingElement.MaxPendingConnections プロパティ (https://go.microsoft.com/fwlink/?LinkId=157735) を参照してください。 10 16*ProcessorCount 10 Try >= 20
TcpTransportBindingElement.ListenBacklog - 保留中のキュー接続要求の最大数を取得または設定します。 ListenBacklog は、キューに登録する "保留中の受け入れ" 要求の数を記述するソケット レベルのプロパティです。 基になるソケット キューでコンカレント接続の最大数を超えないことを確認します。 このプロパティの詳細については、MSDN の TcpTransportBindingElement.ListenBacklog プロパティ (https://go.microsoft.com/fwlink/?LinkId=157734) を参照してください。 10 16*ProcessorCount 10 Try >= 20

ServiceThrottlingBehavior サービスの動作を WCF-Custom または受信場所 WCF-CustomIsolated 追加し、次の設定を使用します。

Note

ServiceThrottlingBehavior サービスの動作の要素を変更する前に、最初に serviceThrottling 動作拡張機能を [WCF-Custom* トランスポートのプロパティ] ダイアログ ボックスの [動作] タブに追加する必要があります。 [動作] の一覧に serviceThrottling を追加するには、[WCF-Custom* トランスポートのプロパティ] ダイアログ ボックスの [動作] タブを選択し、[動作] の下の [ServiceBehavior] を右クリックし、[拡張機能の追加] をクリックし、[serviceThrottling] を選択し、[OK] をクリックします。 次に、 ServiceThrottlingElement で使用できるプロパティをクリックして選択し、必要に応じてプロパティの値を変更します。

設定 .NET Framework 4 の既定値 .NET Framework 4 の推奨値 .NET Framework 3.5 の既定値 .Net Framework 3.5 の推奨値
ServiceThrottlingBehavior.MaxConcurrentCalls - ServiceHost 全体でアクティブに処理されるメッセージの最大数を指定する値を取得または設定します。 MaxConcurrentCalls プロパティは、ServiceHost オブジェクト全体でアクティブに処理するメッセージの最大数を指定します。 各チャネルには、WCF が処理を開始するまで MaxConcurrentCalls の値にカウントされない保留中のメッセージを 1 つ含めることができます。 このプロパティの詳細については、MSDN の ServiceThrottlingBehavior.MaxConcurrentCalls (https://go.microsoft.com/fwlink/?LinkId=157838) を参照してください。 BizTalk WCF-Custom および受信アダプター の MaxConcurrentCalls プロパティ WCF-CustomIsolated の既定値は、CPU あたり 16 です 。 注: BIZTALK SERVER WCF は、WCF-Custom および WCF-CustomIsolated アダプター以外のアダプターを受信し、[WCF* トランスポート プロパティ] ダイアログ ボックスの [バインド] タブで最大同時呼び出しプロパティを公開して、この動作を構成します。 最大同時呼び出し動作の既定値は 200 です。 16*ProcessorCount 16*ProcessorCount - BizTalk WCF-Custom および WCF-CustomIsolated 受信アダプターの場合は 16。
- 他の WCF 受信アダプターの場合は 200。		 - WCF-Custom に対して = 200 を試 >し、アダプターを受信 WCF-CustomIsolated。
- WCF-Custom > アダプターと WCF-CustomIsolated アダプター以外の WCF 受信アダプターの [WCF-* トランスポートのプロパティ] ダイアログ ボックスの [バインド] タブで、[最大同時呼び出し数] プロパティに対して 200 を試BizTalk Server。
ServiceThrottlingBehavior.maxConcurrentInstances - 一度に実行できるサービス内の InstanceContext オブジェクトの最大数を指定する値を取得または設定します。 MaxConcurrentInstances プロパティは、サービス内の InstanceContext オブジェクトの最大数を指定します。 MaxConcurrentInstances プロパティと InstanceContextMode プロパティの関係に留意することが重要です。 InstanceContextMode が PerSession の場合、結果の値はセッションの合計数になります。 InstanceContextMode が PerCall の場合、結果の値は同時呼び出しの数になります。 InstanceContext オブジェクトの最大数が既に存在している間にメッセージが到着した場合、メッセージは InstanceContext オブジェクトが閉じるまで保持されます。 このプロパティの詳細については、MSDN の ServiceThrottlingBehavior.MaxConcurrentInstances プロパティ (https://go.microsoft.com/fwlink/?LinkId=157897) を参照してください。 WCF-Custom および受信アダプター MaxConcurrentInstances プロパティ WCF-CustomIsolated の既定値は、CPU あたり 116 です。 メモ： WCF 受信場所は、Microsoft.BizTalk.Adapter.Wcf.Runtime.dll アセンブリに含まれる BizTalkServiceInstance クラスのインスタンスとして実装されるため、このクラスは ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple) としてマークされているためです。 すべての受信要求は同じシングルトン オブジェクトによって管理され、このパラメーターは無視されます。 そのため、特定の WCF-Custom 受信場所に maxConcurrentInstances プロパティを設定しても効果はありません。アクティブなインスタンスの数は常に 1 に等しいためです。 116*ProcessorCount 116*ProcessorCount 26 Try >= 200
ServiceThrottlingBehavior.MaxConcurrentSessions - MaxConcurrentSessions プロパティは、 ServiceHost オブジェクトが一度に受け入れられるセッションの最大数を取得または設定します。 この場合のセッションは、信頼できるセッションをサポートするチャネルのみに限定されないことを理解しておくことが重要です。 各リスナー オブジェクトには、WCF がチャネル セッションを受け入れてチャネル セッション メッセージの処理を開始するまで 、MaxConcurrentSessions の値にカウントされない保留中のチャネル セッションを 1 つ含めることができます。 このプロパティは、セッションを使用するシナリオで最も有用です。 このプロパティをクライアントのスレッド数より少ない値に設定すると、複数のクライアントからの要求が同じソケット接続でキューに置かれる場合があります。 サービスとのセッションを作成していないクライアントからの要求はブロックされます。 サービス上の開いているセッションの数が MaxConcurrentSessions に指定された値に達した場合、サービスが他のクライアントとのセッションを閉じるまでブロックされたままになります。 その後、提供されていないクライアント要求はタイムアウトになり、サービスはセッションを閉じます。 この状況を回避するには、要求メッセージが異なるソケット接続によって受け入れられるように、異なるアプリケーション ドメインからクライアント スレッドを実行することを検討してください。 このプロパティの詳細については、MSDN の「ServiceThrottlingBehavior.MaxConcurrentSessions プロパティ (https://go.microsoft.com/fwlink/?LinkId=157864)」を参照してください。 100*ProcessorCount 100*ProcessorCount 10 Try >= 200

ポート構成設定を変更する場合は、変更をメソッド的に適用します。各パラメーターを個別に変更し、パフォーマンスと全体的な安定性に対する変更の影響をテストします。 常に、適用する適切な値は、特定のシナリオによって異なります。値が低すぎると、スケーラビリティが低下する可能性があります。一方、値が高すぎると、アプリケーションの要件がコンピューター上の物理リソースの容量を超える可能性があります。 さらに、これらのプロパティは関連しているため、一貫した一貫性のある方法で設定する必要があります。 ServiceThrottlingBehavior を使用して WCF サービスのパフォーマンスを制御する方法の詳細については、MSDN の「ServiceThrottlingBehavior を使用した WCF サービス パフォーマンスの制御 (https://go.microsoft.com/fwlink/?LinkId=157908)」を参照してください。

参照

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