最佳化 BizTalk Server WCF 配接器效能

發行項
10/14/2023

本主題提供選取適當 WCF 配接器或系結類型的建議，以及套用各種 WCF 配接器組態選項的指引。

選擇要使用的 WCF 配接器或要使用的 WCF-Custom/WCF-CustomIsolated 系結類型時的考慮

如果並非絕對必要，請勿使用訊息層級安全性，因為它會增加訊息的大小。這可讓解決方案的整體輸送量降到最低。
選擇要使用的 WCF 配接器或要使用的 WCF-Custom/WCF-CustomIsolated 系 結類型 時，請仔細考慮任何應用程式需求，例如相容性、效能、裝載平臺、安全性和支援的傳輸。以下所列的指導方針適用于 WCF 一般，而且並非專屬於BizTalk Server：
- 如果 WCF 服務需要支援舊版用戶端，例如 WebSphere Web 服務或預期 ASMX Web 服務的 .NET 1.1 應用程式，則應該使用BasicHttpBinding。由於 BasicHttpBinding 預設不會實作任何安全性，因此如果您需要訊息或傳輸安全性，您應該在此系結上明確設定它。使用 BasicHttpBinding 公開能夠與 ASMX 型 Web 服務和用戶端通訊的端點，以及符合 WS-I 基本設定檔 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。當您需要公開 WCF 接收位置或採用支援 WS-* 通訊協定的傳送埠時，應該使用 WsHttpBinding，例如 WS-Security 或 WS-AtomicTransactions。
- 如果您需要支援內部網路內的用戶端，NetTcpBinding是絕佳的選擇。如果傳輸效能對您很重要，而且在 Windows 服務中裝載服務而不是 IIS，NetTcpBinding 是內部網路案例的絕佳選擇。當您想要為 .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	Text	無	不支援	不支援
WSHttpBinding	HTTP	Text	訊息	已停用	WS-AtomicTransactions
NetTcpBinding	TCP	二進位	傳輸	已停用	OleTransactions
NetNamedPipesBinding	具名管道	二進位	傳輸	不支援	OleTransactions
NetMsmqBinding	MSMQ	二進位	訊息	不支援	不支援
CustomBinding	您決定	您決定	您決定	您決定	您決定

您可以根據您的通訊需求選取特定的系結。例如：

BasicHttpBinding 是專為與簡單 Web 服務的互通性所設計。 BasicHttpBinding 會針對傳輸使用 HTTP，並使用文字進行訊息編碼。
WSHttpBinding 是專為與可能利用不同 WS-* 通訊協定之更進階 Web 服務的互通性所設計。 WSHttpBinding 也會使用 HTTP 進行傳輸，並使用文字進行訊息編碼。
NetTcpBinding 和 NetNamedPipeBinding 是針對跨電腦或相同電腦上與其他 WCF 應用程式進行有效且執行 ant 通訊而設計的。
如果您需要在執行時間使用一或多個自訂通訊協定通道的最大彈性，您可以使用 CustomBinding ，讓您能夠決定哪些繫結項目組成系結。

注意

系結在回應時間和輸送量方面有不同的特性。因此，提高效能的一般建議是盡可能使用 NetTcpBindind 和 NetNamesPipeBinding。

使用 TCP 傳輸和二進位訊息編碼，將 WCF 配接器輸送量最大化，並將 WCF 配接器延遲降到最低

盡可能使用 WCF-NetTcp 配接器將輸送量最大化。 WCF-NetTcp 配接器會使用 TCP/IP 傳輸通訊協定和二進位訊息編碼，相較于其他 WCF-* 配接器，可提供改善的效能。

或者，您可以使用 customBinding 系結類型來設定接收位置) WCF-Custom (或 WCF-CustomIsolated 配接器。然後，新增 binaryMessageEncoding 系結延伸模組，以實作二進位訊息編碼和 tcpTransport 系結延伸模組，以實作 TCP/IP 作為訊息傳輸通訊協定。這種方法非常有彈性，因為它可讓您只選取和設定所需的繫結項目，以及建立自訂通道來擴充 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 接收位置，並使用下列設定：

注意

在可以修改 ServiceThrottlingBehavior 服務行為的任何元素之前，您必須先將serviceThrottling行為延伸新增至WCF-Custom* 傳輸屬性對話方塊的 [行為] 索引標籤。若要將 serviceThrottling 新增至行為清單，請選取WCF-Custom* 傳輸屬性對話方塊的 [行為] 索引標籤，以滑鼠右鍵按一下 [行為] 下的[ServiceBehavior]，按一下 [新增延伸模組]，選取[serviceThrottling]，然後按一下 [確定]。然後按一下以選取 ServiceThrottlingElement 下可用的屬性，並視需要變更屬性的值。

設定	.NET Framework 4 的預設值	.NET Framework 4 的建議值	.NET Framework 3.5 的預設值	.Net Framework 3.5 的建議值
ServiceThrottlingBehavior.MaxConcurrentCalls - 取得或設定值，指定在 ServiceHost中主動處理的訊息數目上限。 MaxConcurrentCalls屬性會指定在 ServiceHost物件間主動處理的訊息數目上限。每個通道都可以有一個擱置的訊息，在 WCF 開始處理之前，不會計入 MaxConcurrentCalls 的值。如需此屬性的詳細資訊，請參閱 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*ProcessorCount	16*ProcessorCount	- BizTalk WCF-Custom 和 WCF-CustomIsolated 接收介面卡的 16 個。 - 200 適用于其他 WCF 接收配接器。	- 針對 WCF-Custom 和 WCF-CustomIsolated 接收配接器，請嘗試 > = 200。 - 在*WCF- 傳輸屬性**對話方塊的 [系結] 索引標籤上，針對 WCF-Custom 和 WCF-CustomIsolated 配接器以外的BIZTALK SERVER WCF 接收配接器，嘗試 > 使用 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 和 WCF-CustomIsolated 接收配接器 MaxConcurrentInstances 屬性的預設值為每個 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 物件一次可接受的最大會話數目。請務必瞭解此案例中的會話不限於僅支援可靠會話的通道。每個接聽程式物件可以有一個擱置的通道會話，其不會計入 MaxConcurrentSessions 的值，直到 WCF 接受通道會話並開始處理通道會話訊息為止。這個屬性在運用工作階段的案例中最為有用。當這個屬性設定為小於用戶端執行緒數目的值時，來自多個用戶端的要求可能會在相同通訊端連線中形成佇列。不會使用服務建立會話的用戶端要求將會遭到封鎖。如果服務上開啟的會話數目已達到 MaxConcurrentSessions指定的值，它們會保持封鎖狀態，直到服務與其他用戶端關閉其會話為止。然後，未提供服務的用戶端要求會逾時，而服務會關閉會話。若要避免這種情況，請考慮從不同的應用程式域執行用戶端執行緒，以便由不同的通訊端連線接受要求訊息。如需此屬性的詳細資訊，請參閱 MSDN 上的 ServiceThrottlingBehavior.MaxConcurrentSessions 屬性 (https://go.microsoft.com/fwlink/?LinkId=157864) 。	100*ProcessorCount	100*ProcessorCount	10	Try > = 200

修改埠組態設定時，會以方法方式套用變更;個別修改每個參數，並測試變更對效能和整體穩定性的影響。一如往常，套用的適當值取決於特定案例：如果設定值太低，可減少延展性;而如果設定的值太高，應用程式需求可能會超過電腦上的實體資源容量。此外，由於這些屬性相關，因此應該以一致且一致的方式設定它們。如需使用 ServiceThrottlingBehavior 控制 WCF 服務效能的詳細資訊，請參閱使用 ServiceThrottlingBehavior 控制 MSDN 上的 WCF 服務效能 (https://go.microsoft.com/fwlink/?LinkId=157908) 。

另請參閱

最佳化 BizTalk Server 效能

共用方式為