次の方法で共有

BizTalk Server WCF アダプターのパフォーマンスの最適化

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

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

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

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

    • WCF サービスが、ASMX Web サービスを必要とする WebSphere Web サービスや .NET 1.1 アプリケーションなどのレガシ クライアントをサポートする必要がある場合は、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 テキスト メッセージ 障害者 WS-AtomicTransactions
NetTcpBinding TCP バイナリ トランスポート 障害者 オレトランザクション
NetNamedPipesBinding 名前付きパイプ バイナリ トランスポート サポートされていません オーレトランザクションズ
NetMsmqBinding MSMQ (マイクロソフト メッセージキュー) バイナリ メッセージ サポートされていません サポートされていません
カスタムバインディング あなたが決めてください あなたが決める 決めてください 君が決めてください あなたが決めて

通信のニーズに基づいて特定のバインディングを選択できます。 例えば次が挙げられます。

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

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

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

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

注

バインディングには、応答時間とスループットの点で異なる特性があります。 そのため、パフォーマンスを向上させる一般的なアドバイスは、可能であれば 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 >= 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*プロセッサ数 1 >= 20 を試す
TcpTransportBindingElement.MaxPendingConnections - サービスでのディスパッチを待機している接続の最大数を取得または設定します。 これにより、ディスパッチを待機している同時クライアント接続の数が制限されます。 この値が低すぎると、クライアント接続の試行がサービスによって拒否される可能性があります。 高すぎると、負荷の高い期間中にサービスが遅くなったり、クライアントに応答しなくなったりする可能性があります。 このプロパティは、サービスを最大容量で実行できる値に設定する必要があり、それ以上は実行できません。 スタック内の上位レイヤーが AcceptDispatch を呼び出すと、その接続はディスパッチを待機している接続のキューから削除されます。 このプロパティの詳細については、MSDN の ConnectionOrientedTransportBindingElement.MaxPendingConnections プロパティ (https://go.microsoft.com/fwlink/?LinkId=157735) を参照してください。 10 16*プロセッサ数 10 >= 20 を試す
TcpTransportBindingElement.ListenBacklog - 保留中のキュー接続要求の最大数を取得または設定します。 ListenBacklog は、キューに入れる "保留中の受け入れ" 要求の数を記述するソケット レベルのプロパティです。 基になるソケット キューが同時接続の最大数を超えないようにします。 このプロパティの詳細については、MSDN の TcpTransportBindingElement.ListenBacklog プロパティ (https://go.microsoft.com/fwlink/?LinkId=157734) を参照してください。 10 16*ProcessorCount 10 >= 20 を試す

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

注

ServiceThrottlingBehavior サービスの動作の要素を変更する前に、まず、WCF-Custom* トランスポート プロパティ ダイアログ ボックスの [動作] タブに serviceThrottling動作拡張機能を追加する必要があります。 動作の一覧に 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 および WCF-CustomIsolated 受信アダプター の MaxConcurrentCalls プロパティの 既定値は、CPU あたり 16 です 。 手記：BizTalk Server WCF は、WCF-Custom および WCF-CustomIsolated アダプター以外のアダプターを受信し、[WCF- * トランスポートのプロパティ] ダイアログ ボックスの [バインド] タブで最大同時呼び出しプロパティを公開して、この動作を構成します。 [同時呼び出しの最大数] 動作の既定値は 200 です。 16*プロセッサーカウント 16*ProcessorCount - BizTalk WCF-Custom および WCF-CustomIsolated 受信アダプターの場合は 16。
- 他の WCF 受信アダプターの場合は 200。		 - WCF-Custom と WCF-CustomIsolated 受信アダプターに対して >= 200 を試してください。
- BizTalk Server WCF の [WCF- * トランスポートのプロパティ] ダイアログ ボックスの [バインディング] タブにある [同時呼び出しの最大数] プロパティについて、WCF-Custom および WCF-CustomIsolated アダプター以外のアダプターに対して、200> を試してください。
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) としてマークされているためです。 すべての受信要求は同じシングルトン オブジェクトによって管理され、このパラメーターは無視されます。 そのため、アクティブなインスタンスの数は常に 1 であるため、特定の WCF-Custom 受信場所に maxConcurrentInstances プロパティを設定しても効果はありません。 116*ProcessorCount 116*ProcessorCount 26 >= 200 を試す
ServiceThrottlingBehavior.MaxConcurrentSessions - MaxConcurrentSessions プロパティは、 ServiceHost オブジェクトが一度に受け入れることができるセッションの最大数を取得または設定します。 この場合のセッションは、信頼できるセッションをサポートするチャネルのみに限定されるわけではないことを理解しておくことが重要です。 各リスナー オブジェクトには、WCF がチャネル セッションを受け入れてチャネル セッション メッセージの処理を開始するまで MaxConcurrentSessions の 値に対してカウントされない保留中のチャネル セッションを 1 つ持つことができます。 このプロパティは、セッションを利用するシナリオで最も役立ちます。 このプロパティがクライアント スレッドの数より小さい値に設定されている場合、複数のクライアントからの要求が同じソケット接続でキューに入れられます。 サービスとのセッションを作成していないクライアントからの要求はブロックされます。 サービス上の開いているセッションの数が MaxConcurrentSessions に指定された値に達した場合、サービスが他のクライアントとのセッションを閉じるまでブロックされたままになります。 サービスが提供されていないクライアント要求はタイムアウトになり、サービスはセッションを閉じます。 このような状況を回避するには、異なるアプリケーション ドメインからクライアント スレッドを実行して、要求メッセージが異なるソケット接続によって受け入れられるようにすることを検討してください。 このプロパティの詳細については、MSDN の ServiceThrottlingBehavior.MaxConcurrentSessions プロパティ (https://go.microsoft.com/fwlink/?LinkId=157864) を参照してください。 100*ProcessorCount 100*プロセッサ数 10 >= 200 を試す

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

こちらもご覧ください

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