Share via

Optimieren der Leistung von WCF-Adaptern von BizTalk Server

  • Artikel

Dieses Thema enthält Empfehlungen für die Auswahl des entsprechenden WCF-Adapters oder Bindungstyps sowie Anleitungen zum Anwenden verschiedener WCF-Adapterkonfigurationsoptionen.

Überlegungen bei der Auswahl des WCF-Adapters oder des zu verwendenden WCF-Custom/WCF-CustomIsolated-Bindungstyps

  • Verwenden Sie keine Sicherheit auf Nachrichtenebene, wenn dies nicht unbedingt erforderlich ist, da dadurch die Größe von Nachrichten erhöht wird. Dies wiederum kann den Gesamtdurchsatz der Lösung minimieren.

  • Wenn Sie auswählen, welcher WCF-Adapter oder welcher WCF-CustomIsolated-Bindungstyp verwendet werden soll, sollten Sie alle Anwendungsanforderungen wie Kompatibilität, Leistung, Hostingplattform, Sicherheit und unterstützte Transporte sorgfältig berücksichtigen. Die unten aufgeführten Richtlinien gelten für WCF im Allgemeinen und sind nicht spezifisch für BizTalk Server:

    • BasicHttpBinding sollte verwendet werden, wenn der WCF-Dienst Legacyclients wie WebSphere-Webdienste oder .NET 1.1-Anwendungen unterstützen muss, die einen ASMX-Webdienst erwarten. Da BasicHttpBinding standardmäßig keine Sicherheit implementiert, sollten Sie diese explizit für diese Bindung konfigurieren, wenn Sie Nachrichten- oder Transportsicherheit benötigen. Verwenden Sie BasicHttpBinding, um Endpunkte verfügbar zu machen, die mit ASMX-basierten Webdiensten und Clients und anderen Diensten kommunizieren können, die dem WS-I Basic Profile 1.1 entsprechen. Beim Konfigurieren der Transportsicherheit verwendet BasicHttpBinding standardmäßig keine Anmeldeinformationen, genau wie ein klassischer ASMX-Webdienst. Mit BasicHttpBinding können Sie den WCF-Dienst in IIS 7.5 oder IIS 7.0 hosten.

    • WsHttpBinding sollte verwendet werden, wenn der WCF-Dienst von WCF-Clients über das Internet aufgerufen wird. WsHttpBinding ist eine gute Wahl für Internetszenarien, in denen Sie keine Legacyclients unterstützen müssen, die einen ASMX-Webdienst erwarten, und WsHttpBinding ermöglicht es Ihnen, den WCF-Dienst in IIS 7.5 oder IIS 7.0 zu hosten. Wenn Sie Legacyclients unterstützen müssen, sollten Sie stattdessen BasicHttpBinding verwenden. WsHttpBinding sollte verwendet werden, wenn Sie WCF-Empfangsspeicherorte verfügbar machen oder Sendeports einführen müssen, die WS-*-Protokolle wie WS-Security oder WS-AtomicTransactions unterstützen.

    • NetTcpBinding ist eine ausgezeichnete Wahl, wenn Sie Clients in Ihrem Intranet unterstützen müssen. NetTcpBinding ist eine gute Wahl für Intranetszenarien, wenn die Transportleistung für Sie wichtig ist und wenn es akzeptabel ist, den Dienst in einem Windows-Dienst statt in IIS zu hosten. Verwenden Sie diese Bindung, wenn Sie eine sichere und zuverlässige Bindungsumgebung für NET-to-.NET computerübergreifende Kommunikation bereitstellen möchten. Beachten Sie, dass netTcpBinding in einem Windows-Dienst oder in IIS 7.5/7.0 gehostet werden muss.

    • NetNamedPipeBinding sollte verwendet werden, wenn Sie WCF-Clients auf demselben Computer wie Ihr Dienst unterstützen müssen. Diese Bindung bietet eine sichere und zuverlässige Bindungsumgebung für prozessübergreifende Kommunikation am gleichen Computer. Verwenden Sie diese Bindung, wenn Sie das NamedPipe-Protokoll verwenden möchten. Beachten Sie, dass netNamedPipeBinding in einem Windows-Dienst oder in IIS 7.5/7.0 gehostet werden muss.

    • NetMsmqBinding sollte verwendet werden, wenn Sie getrennte Warteschlangen unterstützen müssen. Queuing wird mithilfe von Message Queuing (auch als MSMQ bezeichnet) als Transport bereitgestellt, wodurch die Unterstützung für getrennte Vorgänge, Fehlerisolation und Lastenausgleich ermöglicht wird. Sie können NetMsmqBinding verwenden, wenn Client und Dienst nicht gleichzeitig online sein müssen. Sie können auch eine beliebige Anzahl eingehender Nachrichten mithilfe der Lastenausgleichsverwaltung verwalten. Message Queuing unterstützt die Fehlerisolation, bei der Nachrichten fehlschlagen können, ohne die Verarbeitung anderer Nachrichten zu beeinträchtigen. Beachten Sie, dass netMsmqBinding in einem Windows-Dienst oder in IIS 7.5/7.0 gehostet werden muss.

    • WsDualHttpBinding sollte verwendet werden, wenn Sie einen Duplexdienst unterstützen müssen. Ein Duplexdienst ist ein Dienst, der Duplex-Nachrichtenmuster verwendet, wodurch ein Dienst die Möglichkeit bietet, über einen Rückruf an den Client zurück zu kommunizieren. Beachten Sie, dass WsDualHttpBinding in einem Windows-Dienst oder in IIS 7.5/7.0 gehostet werden muss.

WCF-Bindungsvergleich

Bindungen bieten einen Mechanismus zum Konfigurieren von Kanalstapeln. Eine Bindung erstellt einen Prozess zum Erstellen eines Kanalstapels mithilfe eines Transportkanals, eines Nachrichtenencoders und einer Reihe von Protokollkanälen. Windows Communication Foundation wird mit zahlreichen integrierten Bindungen ausgeliefert, die für die meisten gängigen Kommunikationsszenarien vorkonfiguriert sind.

Bindungsklassenname Transport Nachrichtenverschlüsselung Sicherheitsmodus Zuverlässiges Messaging Transaktionsfluss (standardmäßig deaktiviert)
BasicHttpBinding HTTP Text Keine Nicht unterstützt Nicht unterstützt
WSHttpBinding HTTP Text Meldung Disabled WS-AtomicTransactions
NetTcpBinding TCP Binary Transport Disabled OleTransactions
NetNamedPipesBinding Named Pipes Binary Transport Nicht unterstützt OleTransactions
NetMsmqBinding MSMQ Binary Meldung Nicht unterstützt Nicht unterstützt
Custombinding Sie entscheiden Sie entscheiden Sie entscheiden Sie entscheiden Sie entscheiden

Sie können eine bestimmte Bindung basierend auf Ihren Kommunikationsanforderungen auswählen. Beispiel:

  • BasicHttpBinding ist für die Interoperabilität mit einfachen Webdiensten konzipiert. BasicHttpBinding verwendet HTTP für den Transport und Text für die Nachrichtencodierung.

  • WSHttpBinding ist für die Interoperabilität mit fortschrittlicheren Webdiensten konzipiert, die verschiedene WS-*-Protokolle nutzen können. WSHttpBinding verwendet auch HTTP für den Transport und Text für die Nachrichtencodierung.

  • NetTcpBinding und NetNamedPipeBinding sind für eine effiziente und ant-Kommunikation mit anderen WCF-Anwendungen auf computern- bzw. auf demselben Computer konzipiert.

  • Wenn Sie maximale Flexibilität benötigen, indem Sie einen oder mehrere benutzerdefinierte Protokollkanäle zur Laufzeit verwenden, können Sie customBinding verwenden, mit dem Sie entscheiden können, welche Bindungselemente Ihre Bindung bilden.

Hinweis

Bindungen weisen unterschiedliche Merkmale hinsichtlich Antwortzeit und Durchsatz auf. Daher wird allgemein empfohlen, die Leistung zu steigern, wenn möglich die Verwendung von NetTcpBindind und NetNamesPipeBinding.

Verwenden Sie die TCP-Transport- und binäre Nachrichtencodierung, um den WCF-Adapterdurchsatz zu maximieren und die Latenz des WCF-Adapters zu minimieren.

Verwenden Sie nach Möglichkeit den WCF-NetTcp-Adapter, um den Durchsatz zu maximieren. Der WCF-NetTcp-Adapter verwendet TCP/IP-Transportprotokoll und binäre Nachrichtencodierung, die zusammen eine verbesserte Leistung im Vergleich zu anderen WCF-*-Adaptern bieten.

Alternativ können Sie den WCF-Custom (oder WCF-CustomIsolated Adapter für Empfangsspeicherorte) mit einem customBinding-Bindungstyp konfigurieren. Fügen Sie dann die Bindungserweiterung binaryMessageEncoding hinzu, um die binäre Nachrichtencodierung zu implementieren, und die tcpTransport-Bindungserweiterung , um TCP/IP als Nachrichtentransportprotokoll zu implementieren. Dieser Ansatz ist sehr flexibel, da Sie nur die benötigten Bindungselemente auswählen und konfigurieren können und benutzerdefinierte Kanäle erstellen können, um das Standardverhalten der BizTalk Messaging-Engine zu erweitern. Wenn Sie den WCF-Custom-Adapter mit dem Bindungstyp customBinding implementieren, geben Sie diese Werte für die Konfigurationsparameter der Bindungserweiterung an, um den Durchsatz zu maximieren und die Latenz zu minimieren.

Sendeportkonfigurationswerte:

Einstellung Standardwert Empfohlener Wert
TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint : Ruft die maximale Anzahl ausgehender Verbindungen für jeden Endpunkt ab, der im Verbindungspool zwischengespeichert wird, oder legt diese fest. Dies schränkt die Anzahl von Verbindungen ein, die für jeden eindeutigen Remoteendpunkt zwischengespeichert werden. Wenn dieser Wert durch aktivere Clientverbindungen überschritten wird, reagiert der Dienst möglicherweise nicht auf den Client, und dieser Wert sollte angepasst werden, um die maximale Anzahl erwarteter Verbindungen zu berücksichtigen, die für jeden eindeutigen Remoteendpunkt zwischengespeichert werden. Weitere Informationen zu dieser Eigenschaft finden Sie unter TcpConnectionPoolSettings.MaxOutboundConnectionsPerEndpoint-Eigenschaft (https://go.microsoft.com/fwlink/?LinkId=157737) auf MSDN. 10 Ausprobieren >= 20

Empfangen von Portkonfigurationswerten:

Einstellung Standardwert für .NET Framework 4 Empfohlener Wert für .NET Framework 4 Standardwert für .NET Framework 3.5 Empfohlener Wert für .NET Framework 3.5
TcpTransportBindingElement.MaxPendingAccepts : Ruft die maximale Anzahl von ausstehenden asynchronen Annahmevorgängen ab, die für die Verarbeitung eingehender Verbindungen mit dem Dienst verfügbar sind, oder legt diese fest. In Szenarien mit einer hohen Anzahl gleichzeitiger Verbindungsinitiierungen ist dieser Wert möglicherweise unzureichend und sollte zusammen mit der MaxPendingConnections-Eigenschaft angepasst werden, um höhere Ebenen gleichzeitiger Clientverbindungsversuche zu verarbeiten. Diese Eigenschaft muss nicht unbedingt auf einen größeren Wert als die Anzahl der im Rechner, auf dem der Dienst gehostet wird, vorhandenen Prozessoren festgelegt werden. Weitere Informationen zu dieser Eigenschaft finden Sie unter ConnectionOrientedTransportBindingElement.MaxPendingAccepts-Eigenschaft (https://go.microsoft.com/fwlink/?LinkId=157738) auf MSDN. 1 2*ProcessorCount 1 Ausprobieren >= 20
TcpTransportBindingElement.MaxPendingConnections : Ruft die maximale Anzahl von Verbindungen ab, die auf die Verteilung für den Dienst warten, oder legt diese fest. Dies schränkt die Anzahl gleichzeitiger Clientverbindungen ein, die zum Verteilen bereitstehen. Wenn dieser Wert zu niedrig ist, werden die Clientverbindungsversuche womöglich vom Dienst abgelehnt. Wenn er zu hoch ist, arbeitet der Dienst während Zeiten mit hoher Auslastung womöglich langsam oder reagiert nicht auf Clients. Diese Eigenschaft sollte nicht auf einen höheren Wert festgelegt werden als den, mit dem der Dienst bei voller Auslastung ausgeführt werden kann. Wenn eine höhere Ebene im Stapel AcceptDispatch aufruft, wird diese Verbindung aus der Warteschlange der Verbindungen entfernt, die auf die Verteilung warten. Weitere Informationen zu dieser Eigenschaft finden Sie unter ConnectionOrientedTransportBindingElement.MaxPendingConnections-Eigenschaft (https://go.microsoft.com/fwlink/?LinkId=157735) auf MSDN. 10 16*ProcessorCount 10 Ausprobieren >= 20
TcpTransportBindingElement.ListenBacklog : Ruft die maximale Anzahl von Verbindungsanforderungen in der Warteschlange ab, die ausstehend sein können, oder legt diese fest. ListenBacklog ist eine Eigenschaft auf Socketebene, die die Anzahl der "ausstehenden Annehmen"-Anforderungen beschreibt, die in die Warteschlange eingereiht werden sollen. Stellen Sie sicher, dass die Kapazität der zugrunde liegenden Socketwarteschlange nicht von der maximalen Anzahl gleichzeitiger Verbindungen überschritten wird. Weitere Informationen zu dieser Eigenschaft finden Sie unter TcpTransportBindingElement.ListenBacklog Property (https://go.microsoft.com/fwlink/?LinkId=157734) auf MSDN. 10 16*ProcessorCount 10 Ausprobieren >= 20

Fügen Sie das Dienstverhalten ServiceThrottlingBehavior einem WCF-Custom oder WCF-CustomIsolated Empfangsspeicherort hinzu, und verwenden Sie die folgenden Einstellungen:

Hinweis

Bevor Elemente des Dienstverhaltens ServiceThrottlingBehavior geändert werden können, müssen Sie zuerst die ServiceThrottling-Verhaltenserweiterung der Registerkarte Verhalten des DialogfeldsWCF-Custom* Transport Properties (WCF-Custom* Transport Properties ) hinzufügen. Um serviceThrottling zur Liste der Verhaltensweisen hinzuzufügen, wählen Sie die Registerkarte Verhalten des DialogfeldsWCF-Benutzerdefinierte* Transporteigenschaften aus, klicken Sie unter Verhalten mit der rechten Maustaste auf ServiceBehavior, klicken Sie auf Erweiterung hinzufügen, wählen Sie DienstDrosselung aus, und klicken Sie dann auf OK. Klicken Sie dann, um die unter ServiceThrottlingElement verfügbaren Eigenschaften auszuwählen, und ändern Sie den Wert für die Eigenschaften nach Bedarf.

Einstellung Standardwert für .NET Framework 4 Empfohlener Wert für .NET Framework 4 Standardwert für .NET Framework 3.5 Empfohlener Wert für .NET Framework 3.5
ServiceThrottlingBehavior.MaxConcurrentCalls : Ruft einen Wert ab oder legt einen Wert fest, der die maximale Anzahl von Nachrichten angibt, die in einem ServiceHost aktiv verarbeitet werden. Die MaxConcurrentCalls-Eigenschaft gibt die maximale Anzahl von Nachrichten an, die in einem ServiceHost-Objekt aktiv verarbeitet werden. Jeder Kanal kann eine ausstehende Nachricht haben, die nicht mit dem Wert von MaxConcurrentCalls gezählt wird, bis WCF mit der Verarbeitung beginnt. Weitere Informationen zu dieser Eigenschaft finden Sie unter ServiceThrottlingBehavior.MaxConcurrentCalls (https://go.microsoft.com/fwlink/?LinkId=157838) auf MSDN. Der Standardwert für die MaxConcurrentCalls-Eigenschaft WCF-Custom BizTalk und WCF-CustomIsolated Empfangsadapter ist 16 pro CPU. Hinweis: BizTalk Server WCF-Empfangsadapter außer dem WCF-Custom- und WCF-CustomIsolated-Adapter auf der Registerkarte Bindung des Dialogfelds WCF-*-Transporteigenschaften eine Eigenschaft Maximale gleichzeitige Aufrufe verfügbar, um dieses Verhalten zu konfigurieren. Der Standardwert für das Verhalten Maximum Concurrent Calls (Maximale Anzahl gleichzeitiger Aufrufe ) ist 200. 16*ProcessorCount 16*ProcessorCount – 16 für die BizTalk-WCF-Custom und WCF-CustomIsolated-Empfangsadapter.
– 200 für die anderen WCF-Empfangsadapter.		 – Testen Sie >= 200 für die WCF-Custom und WCF-CustomIsolated Empfangsadapter.
– Versuchen Sie > 200 für die Eigenschaft Maximale gleichzeitige Aufrufe auf der Registerkarte Bindung des Dialogfelds WCF-*-Transporteigenschaften für BizTalk Server WCF-Empfangsadapter außer dem WCF-Custom- und WCF-CustomIsolated adapter.
ServiceThrottlingBehavior.maxConcurrentInstances : Ruft einen Wert ab, der die maximale Anzahl von InstanceContext-Objekten im Dienst angibt, die gleichzeitig ausgeführt werden können. Die MaxConcurrentInstances-Eigenschaft gibt die maximale Anzahl von InstanceContext-Objekten im Dienst an. Es ist wichtig, die Beziehung zwischen der MaxConcurrentInstances-Eigenschaft und der InstanceContextMode-Eigenschaft zu berücksichtigen. Wenn InstanceContextMode auf PerSession festgelegt ist, ist der resultierende Wert die Gesamtzahl der Sitzungen. Wenn InstanceContextMode auf PerCall festgelegt ist, ist der resultierende Wert die Anzahl gleichzeitiger Aufrufe. Wenn eine Nachricht eingeht, während die maximale Anzahl von InstanceContext-Objekten bereits vorhanden ist, wird die Nachricht gehalten, bis ein InstanceContext-Objekt geschlossen wird. Weitere Informationen zu dieser Eigenschaft finden Sie unter ServiceThrottlingBehavior.MaxConcurrentInstances-Eigenschaft (https://go.microsoft.com/fwlink/?LinkId=157897) auf MSDN. Der Standardwert für die MaxConcurrentInstances-Eigenschaft WCF-Custom und WCF-CustomIsolated Empfangsadapters ist 116 pro CPU. Hinweis: Da WCF-Empfangsspeicherorte als Instanzen der BizTalkServiceInstance-Klasse implementiert werden, die in der Microsoft.BizTalk.Adapter.Wcf.Runtime.dll Assembly enthalten ist, und da diese Klasse als ServiceBehavior(InstanceContextMode=InstanceContextMode.Single, ConcurrencyMode=ConcurrencyMode.Multiple) gekennzeichnet ist. Alle eingehenden Anforderungen werden vom gleichen Singletonobjekt verwaltet, und dieser Parameter wird ignoriert. Das Festlegen der maxConcurrentInstances-Eigenschaft für bestimmte WCF-Custom Empfangsspeicherorte hat also keine Auswirkung, da die Anzahl der aktiven Instanzen immer gleich 1 ist. 116*ProcessorCount 116*ProcessorCount 26 Ausprobieren >= 200
ServiceThrottlingBehavior.MaxConcurrentSessions : Die MaxConcurrentSessions-Eigenschaft ruft die maximale Anzahl von Sitzungen ab, die ein ServiceHost-Objekt gleichzeitig akzeptieren kann, oder legt diese fest. Es ist wichtig zu verstehen, dass Sitzungen in diesem Fall nicht auf Kanäle beschränkt sind, die zuverlässige Sitzungen unterstützen. Jedes Listenerobjekt kann über eine ausstehende Kanalsitzung verfügen, die nicht auf den Wert von MaxConcurrentSessions angerechnet wird, bis WCF die Kanalsitzung akzeptiert und mit der Verarbeitung der Kanalsitzungsmeldungen beginnt. Diese Eigenschaft ist höchst nützlich in Szenarien, die Sitzungen nutzen. Wenn diese Eigenschaft auf einen Wert festgelegt wird, der unter der Anzahl der Clientthreads liegt, werden die Anforderungen von mehreren Clients möglicherweise in derselben Socketverbindung in eine Warteschlange gestellt. Die Anforderungen des Clients, der keine Sitzung mit dem Dienst erstellt hat, werden blockiert. Sie bleiben blockiert, bis der Dienst seine Sitzung mit den anderen Clients schließt, wenn die Anzahl der geöffneten Sitzungen im Dienst den für MaxConcurrentSessions angegebenen Wert erreicht hat. Für die Clientanforderungen, die nicht bereitgestellt werden, wird dann ein Timeout ausgeführt, und der Dienst schließt die Sitzung. Um diese Situation zu vermeiden, sollten Sie die Clientthreads aus verschiedenen Anwendungsdomänen ausführen, damit die Anforderungsmeldungen von verschiedenen Socketverbindungen akzeptiert werden. Weitere Informationen zu dieser Eigenschaft finden Sie unter ServiceThrottlingBehavior.MaxConcurrentSessions-Eigenschaft (https://go.microsoft.com/fwlink/?LinkId=157864) auf MSDN. 100*ProcessorCount 100*ProcessorCount 10 Ausprobieren >= 200

Wenden Sie beim Ändern der Portkonfigurationseinstellungen Änderungen methodisch an. ändern Sie jeden Parameter einzeln, und testen Sie die Auswirkungen der Änderung auf die Leistung und die Gesamtstabilität. Wie immer hängt der richtige Wert vom jeweiligen Szenario ab: Wenn ein Wert zu niedrig festgelegt ist, kann die Skalierbarkeit verringert werden; Wenn ein Wert zu hoch festgelegt ist, kann die Anwendungsanforderung die Kapazität der physischen Ressourcen auf dem Computer überschreiten. Da diese Eigenschaften in Beziehung stehen, sollten sie außerdem konsistent und kohärent festgelegt werden. Weitere Informationen zur Verwendung von ServiceThrottlingBehavior zum Steuern der WCF-Dienstleistung finden Sie unter Verwenden von ServiceThrottlingBehavior zum Steuern der WCF-Dienstleistung (https://go.microsoft.com/fwlink/?LinkId=157908) auf MSDN.

Weitere Informationen

Optimieren der Leistung von BizTalk Server