Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Dieses Thema enthält Empfehlungen zum Auswählen des geeigneten WCF-Adapters oder Bindungstyps und Anleitungen zum Anwenden verschiedener KONFIGURATIONsoptionen für WCF-Adapter.
Überlegungen bei der Auswahl des zu verwendenden WCF-Adapters oder des zu verwendenden WCF-Custom/WCF-CustomIsolated Bindungstyps
Verwenden Sie keine Sicherheit auf Nachrichtenebene, wenn sie nicht unbedingt erforderlich ist, da sie die Größe von Nachrichten erhöht. Dies wiederum kann den Gesamtdurchsatz der Lösung minimieren.
Berücksichtigen Sie bei der Auswahl des zu verwendenden WCF-Adapters oder des zu verwendenden WCF-Custom/WCF-CustomIsolated Bindungstyps alle Anwendungsanforderungen wie Kompatibilität, Leistung, Hostingplattform, Sicherheit und unterstützte Transporte. Die unten aufgeführten Richtlinien gelten im Allgemeinen für WCF und gelten nicht für BizTalk Server:
BasicHttpBinding sollte verwendet werden, wenn der WCF-Dienst ältere Clients 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 den WS-I Basic Profile 1.1 entsprechen. Beim Konfigurieren der Transportsicherheit verwendet BasicHttpBinding standardmäßig keine Anmeldeinformationen wie ein klassischer ASMX-Webdienst. BasicHttpBinding ermöglicht Ihnen das Hosten des WCF-Diensts in IIS 7.5 oder IIS 7.0.
WsHttpBinding sollte verwendet werden, wenn der WCF-Dienst von WCF-Clients über das Internet aufgerufen wird. WsHttpBinding ist eine gute Wahl für Internetszenarien, bei denen keine Unterstützung für veraltete Clients erforderlich ist, die einen ASMX-Webdienst erwarten. Zudem ermöglicht WsHttpBinding, den WCF-Dienst in IIS 7.5 oder IIS 7.0 zu hosten. Falls Sie tatsächlich Legacy-Clients 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 innerhalb Ihres Intranets 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 die computerübergreifende Kommunikation von .NET-to-.NET bereitstellen möchten. Beachten Sie, dass das 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 die prozessübergreifende Kommunikation mit demselben Computer. Verwenden Sie diese Bindung, wenn Sie das NamedPipe-Protokoll verwenden möchten. Beachten Sie, dass das 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. Die Warteschlangenverwaltung wird mithilfe von Message Queuing (auch als MSMQ bezeichnet) als Transport bereitgestellt, was die Unterstützung von getrennten Vorgängen, Fehlerisolation und Lastverteilung ermöglicht. Sie können NetMsmqBinding verwenden, wenn der Client und der Dienst nicht gleichzeitig online sein müssen. Sie können auch eine beliebige Anzahl eingehender Nachrichten verwalten, indem Sie den Kapazitätsausgleich verwenden. Message Queuing unterstützt Fehlerisolation, bei der Nachrichten fehlschlagen können, ohne die Verarbeitung anderer Nachrichten zu beeinträchtigen. Beachten Sie, dass die 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. Bei einem Duplexdienst handelt es sich um einen Dienst, der Duplexnachrichtenmuster verwendet, sodass ein Dienst über einen Rückruf mit dem Client kommunizieren kann. Beachten Sie, dass die WsDualHttpBinding in einem Windows-Dienst oder in IIS 7.5/7.0 gehostet werden muss.
WCF-Bindungsvergleich
Bindungen stellen einen Mechanismus zum Konfigurieren von Kanalstapeln bereit. Eine Bindung erstellt einen Prozess zum Erstellen eines Kanalstapels mithilfe eines Transportkanals, eines Nachrichten-Encoders und einer Reihe von Protokollkanälen. Windows Communication Foundation wird mit zahlreichen integrierten Bindungen ausgeliefert, die vorkonfiguriert sind, um die häufigsten Kommunikationsszenarien zu behandeln.
| Name der Bindungsklasse | Transport | Nachrichtencodierung | Sicherheitsmodus | Zuverlässiges Messaging | Transaktionsfluss (standardmäßig deaktiviert) |
|---|---|---|---|---|---|
| BasicHttpBinding | HTTP | Text | Nichts | Nicht unterstützt | Nicht unterstützt |
| WSHttpBinding | HTTP | Text | Nachricht | Arbeitsunfähig | WS-AtomicTransactions |
| NetTcpBinding | TCP | Binär | Transport | Arbeitsunfähig | OleTransaktionen |
| NetNamedPipesBinding | Benannte Rohre | Binär | Transport | Nicht unterstützt | OleTransactions |
| NetMsmqBinding | MSMQ | Binär | Nachricht | Nicht unterstützt | Nicht unterstützt |
| Benutzerdefinierte Bindung | Sie entscheiden | Sie entscheiden | Sie entscheiden | Sie entscheiden | Sie entscheiden |
Sie können eine bestimmte Bindung basierend auf Ihren Kommunikationsanforderungen auswählen. Beispiel:
BasicHttpBinding wurde für die Interoperabilität mit einfachen Webdiensten entwickelt. BasicHttpBinding verwendet HTTP für den Transport und Text für die Nachrichtencodierung.
WSHttpBinding wurde für die Interoperabilität mit erweiterten Webdiensten entwickelt, die von verschiedenen WS-*-Protokollen profitieren können. WSHttpBinding verwendet auch HTTP für den Transport und Text für die Nachrichtencodierung.
NetTcpBinding und NetNamedPipeBinding sind jeweils für eine effiziente und schnelle Kommunikation mit anderen WCF-Anwendungen auf anderen Computern oder auf demselben Computer ausgelegt.
Wenn Sie maximale Flexibilität benötigen, indem Sie einen oder mehrere benutzerdefinierte Protokollkanäle während der Ausführung verwenden, können Sie das CustomBinding verwenden, mit dem Sie entscheiden können, welche Bindungselemente Ihre Bindung zusammenstellen.
Hinweis
Bindungen weisen unterschiedliche Merkmale in Bezug auf Antwortzeit und Durchsatz auf. Der allgemeine Rat zur Leistungssteigerung ist also die Verwendung von NetTcpBindind und NetNamesPipeBinding, wenn möglich.
Verwenden sie die TCP-Transport- und binäre Nachrichtencodierung, um den WCF-Adapterdurchsatz zu maximieren und die WCF-Adapterlatenz zu minimieren.
Verwenden Sie den WCF-NetTcp Adapter, wenn möglich, um den Durchsatz zu maximieren. Der WCF-NetTcp Adapter verwendet TCP/IP-Transportprotokoll und binäre Nachrichtencodierung, die im Vergleich zu anderen WCF-*-Adaptern eine verbesserte Leistung bieten.
Alternativ können Sie den WCF-Custom (oder den WCF-CustomIsolated-Adapter für Empfangsorte) mit einem Bindungstyp customBinding konfigurieren. Fügen Sie dann die binaryMessageEncoding-Bindungserweiterung hinzu, um die binäre Nachrichtencodierung und die tcpTransport-Bindungserweiterung zu implementieren, um TCP/IP als Nachrichtentransportprotokoll zu implementieren. Dieser Ansatz ist sehr flexibel, da es Ihnen ermöglicht, nur die benötigten Bindungselemente auszuwählen und zu konfigurieren und benutzerdefinierte Kanäle zu erstellen, um das Standardverhalten des BizTalk Messaging-Moduls zu erweitern. Wenn Sie den WCF-Custom Adapter mit dem benutzerdefinierten Bindungstyp implementieren, geben Sie diese Werte für die Parameter für die Bindungserweiterungskonfiguration an, um den Durchsatz zu maximieren und die Latenz zu minimieren.
Portkonfigurationswerte senden:
| Konfiguration | Standardwert | Empfohlener Wert |
|---|---|---|
| TcpTransportBindingElement.ConnectionPoolSettings.maxOutboundConnectionsPerEndpoint – Ruft die maximale Anzahl an ausgehenden Verbindungen für jeden im Verbindungspool zwischengespeicherten Endpunkt ab oder legt sie fest. Dadurch wird die Anzahl der Verbindungen begrenzt, die für jeden eindeutigen Remoteendpunkt zwischengespeichert werden. Wenn dieser Wert durch aktivere Clientverbindungen überschritten wird, reagiert der Dienst möglicherweise nicht mehr auf den Client, und dieser Wert sollte angepasst werden, um die maximale Anzahl der erwarteten 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 | Probieren >= 20 |
Empfangen von Portkonfigurationswerten:
| Konfiguration | 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 an ausstehenden asynchronen Annahmevorgängen ab, die für die Verarbeitung eingehender Verbindungen mit dem Dienst verfügbar sind, oder legt diese fest. Für Szenarien mit hohen Ebenen 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. Es sollte nicht erforderlich sein, diese Eigenschaft auf einen Wert festzulegen, der größer als die Anzahl der Prozessoren ist, die auf dem Computer vorhanden sind, auf dem der Dienst gehostet wird. Weitere Informationen zu dieser Eigenschaft finden Sie unter ConnectionOrientedTransportBindingElement.MaxPendingAccepts Property (https://go.microsoft.com/fwlink/?LinkId=157738) auf MSDN. | 1 | 2*Prozessoranzahl | 1 | Probieren Sie >= 20 |
| TcpTransportBindingElement.MaxPendingConnections – Ruft die maximale Anzahl von Verbindungen ab oder legt diese fest, die auf den Versand im Dienst warten. Dadurch wird die Anzahl der gleichzeitigen Clientverbindungen begrenzt, die auf die Weiterleitung warten. Wenn dieser Wert zu niedrig ist, können Clientverbindungsversuche vom Dienst abgelehnt werden. Wenn die Belastung zu hoch ist, kann es während starker Auslastungsperioden zu einem langsamen oder nicht mehr reagierenden Dienst kommen. Diese Eigenschaft sollte auf einen Wert festgelegt werden, der es dem Dienst ermöglicht, in voller Kapazität und nicht höher ausgeführt zu werden. Wenn eine höhere Ebene im Stapel AcceptDispatch aufruft, wird diese Verbindung aus der Warteschlange der Verbindungen entfernt, die auf den Versand warten. Weitere Informationen zu dieser Eigenschaft finden Sie unter ConnectionOrientedTransportBindingElement.MaxPendingConnections Property (https://go.microsoft.com/fwlink/?LinkId=157735) auf MSDN. | 10 | 16*Prozessoranzahl | 10 | Versuchen >= 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 anstehenden Annehmen-Anforderungen beschreibt, die in die Warteschlange gestellt werden sollen. Stellen Sie sicher, dass die zugrunde liegende Socketwarteschlange nicht um die maximale 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*AnzahlDerProzessoren | 10 | Probieren >= 20 |
Fügen Sie das Dienstverhalten ServiceThrottlingBehavior zu einem Empfangsort WCF-Custom oder WCF-CustomIsolated hinzu und verwenden Sie die folgenden Einstellungen:
Hinweis
Bevor Sie Elemente des Dienstverhaltens "ServiceThrottlingBehavior" ändern können, müssen Sie zuerst die Verhaltenserweiterung serviceThrottling zur Registerkarte Verhalten im Dialogfeld WCF-Custom*-Transporteigenschaften hinzufügen. Wenn Sie "serviceThrottling" zur Liste der Verhaltensweisen hinzufügen möchten, wählen Sie die Registerkarte "Verhalten" des Dialogfelds"WCF-Custom* Transport Properties" aus, klicken Sie mit der rechten Maustaste unter "Verhalten" auf "ServiceBehavior", klicken Sie auf "Erweiterung hinzufügen", wählen Sie "ServiceThrottling" aus, und klicken Sie dann auf "OK". Klicken Sie dann, um die unter ServiceThrottlingElement verfügbaren Eigenschaften auszuwählen und den Wert für die Eigenschaften nach Bedarf zu ändern.
| Konfiguration | 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, der die maximale Anzahl von Nachrichten angibt, die aktiv in einem ServiceHost verarbeitet werden. Die MaxConcurrentCalls-Eigenschaft gibt die maximale Anzahl von Nachrichten an, die aktiv in einem ServiceHost-Objekt verarbeitet werden. Jeder Kanal kann eine ausstehende Nachricht haben, die nicht für den 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 Eigenschaft MaxConcurrentCalls der BizTalk-Empfangsadaptern WCF-Custom und WCF-CustomIsolated beträgt 16 pro CPU. Anmerkung: BizTalk Server WCF-Empfängeradapter, mit Ausnahme des WCF-Custom und WCF-CustomIsolated Adapters, bieten eine Eigenschaft "Maximale gleichzeitige Aufrufe" auf der Registerkarte "Bindung" im Dialogfeld "WCF-* Transporteigenschaften" an, um dieses Verhalten zu konfigurieren. Der Standardwert des Verhaltens für maximal gleichzeitige Anrufe ist 200. | 16*Prozessoranzahl | 16 * ProcessorCount | - 16 für die BizTalk-WCF-Custom- und WCF-CustomIsolated-Empfangsadapter. - 200 für die anderen WCF-Empfangsadapter. |
- Versuchen Sie >= 200 für die WCF-Custom- und WCF-CustomIsolated-Empfangsadapter. - Probieren Sie > 200 für die Eigenschaft "Maximale gleichzeitige Aufrufe " auf der Registerkarte " Bindung " des Dialogfelds "WCF-* Transporteigenschaften " für BizTalk Server WCF Adapter außer dem WCF-Custom und WCF-CustomIsolated Adapter aus. |
| ServiceThrottlingBehavior.maxConcurrentInstances – Dient zum Abrufen oder Festlegen eines Werts, 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 PerSession ist, ist der resultierende Wert die Gesamtanzahl der Sitzungen. Wenn InstanceContextMode PerCall ist, ist der resultierende Wert die Anzahl der gleichzeitigen 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 Eigenschaft MaxConcurrentInstances des Empfangsadapters WCF-Custom und WCF-CustomIsolated beträgt 116 pro CPU. Anmerkung: 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 mit demselben Singleton-Objekt 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*Prozessoranzahl | 116*ProcessorCount | 26 | Versuchen Sie >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions – Die MaxConcurrentSessions-Eigenschaft ruft die maximale Anzahl von Sitzungen ab, die ein ServiceHost-Objekt gleichzeitig annehmen kann. Es ist wichtig zu verstehen, dass Sitzungen in diesem Fall nicht nur auf Kanäle beschränkt sind, die zuverlässige Sitzungen unterstützen. Jedes Listenerobjekt kann eine ausstehende Kanalsitzung aufweisen, die nicht für den Wert von MaxConcurrentSessions gezählt wird, bis WCF die Kanalsitzung akzeptiert und mit der Verarbeitung der Kanalsitzungsnachrichten beginnt. Diese Eigenschaft ist in Szenarien nützlich, in denen Sitzungen verwendet werden. Wenn diese Eigenschaft auf einen Wert festgelegt ist, der kleiner als die Anzahl der Clientthreads ist, werden die Anforderungen von mehreren Clients möglicherweise in die Warteschlange in derselben Socketverbindung eingereiht. Anfragen des Clients, die keine Sitzung mit dem Service 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 für den Dienst den für MaxConcurrentSessions angegebenen Wert erreicht hat. Die Kundenanforderungen, die nicht bedient werden, laufen dann ab, und der Dienst schließt die Sitzung. Um diese Situation zu vermeiden, sollten Sie die Clientthreads aus verschiedenen Anwendungsdomänen ausführen, damit die Anforderungsnachrichten 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 | Versuchen >= 200 |
Beim Ändern der Portkonfigurationseinstellungen werden Änderungen methodisch angewendet; ä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 reduziert werden; wenn ein Wert zu hoch festgelegt ist, kann die Anwendungsanforderung die Kapazität der physischen Ressourcen auf dem Computer überschreiten. Da diese Eigenschaften miteinander verbunden sind, sollten sie auf konsistente und kohärente Weise festgelegt werden. Weitere Informationen zur Verwendung von ServiceThrottlingBehavior zum Steuern der WCF-Dienstleistung finden Sie unter Using ServiceThrottlingBehavior to Control WCF Service Performance (https://go.microsoft.com/fwlink/?LinkId=157908) auf MSDN.