本主題提供選取適當 WCF 配接器或系結類型的建議，以及套用各種 WCF 配接器組態選項的指引。
選擇要使用的 WCF 配接器或要使用的 WCF 自定義/WCF-CustomIsolated 系結類型時的考慮
如果不嚴格要求，請勿使用訊息層級安全性，因為它會增加訊息的大小。 這反過來又可將解決方案的整體輸送量降到最低。
選擇要使用哪個 WCF 配接器或要使用的 WCF-Custom/WCF-CustomIsolated 系 結類型 時，請仔細考慮任何應用程式需求，例如相容性、效能、裝載平臺、安全性和支援的傳輸。 以下所列的指導方針一般適用於 WCF，並不專屬於 BizTalk Server：
如果 WCF 服務需要支援舊版用戶端，例如 WebSphere Web 服務或預期 ASMX Web 服務的 .NET 1.1 應用程式，則應該使用 BasicHttpBinding。 因為 BasicHttpBinding 預設不會實作任何安全性，所以如果您需要訊息或傳輸安全性，您應該在此系結上明確設定它。 使用 BasicHttpBinding 來公開能夠與 ASMX 型 Web 服務和用戶端通訊的端點，以及其他符合基本配置檔 1.1 WS-I 的服務。 設定傳輸安全性時，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-* 通訊協定的傳送埠，例如 WS-Security 或 WS-AtomicTransactions 時，應該使用 WsHttpBinding。
如果您需要支持內部網路內的用戶端，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綁定) | HTTP | 文字 | 沒有 | 不支援 | 不支援 |
| WSHttpBinding | HTTP | 文字 | 訊息 | 已停用 | WS-AtomicTransactions |
| NetTcpBinding | TCP | 二進制 | 運輸 | 已停用 | OleTransactions |
| NetNamedPipesBinding | 命名管道 | 二進制 | 運輸 | 不支援 | OleTransactions |
| NetMsmqBinding | MSMQ | 二進制 | 訊息 | 不支援 | 不支援 |
| 自訂綁定 | 您決定 | 您決定 | 您決定 | 您決定 | 您決定 |
您可以根據您的通訊需求選取特定的系結。 例如：
BasicHttpBinding 是專為與簡單 Web 服務的互作性所設計。 BasicHttpBinding 使用 HTTP 作為傳輸協定，並使用文字作為訊息編碼格式。
WSHttpBinding 是專為與可能利用不同 WS-* 通訊協定的更進階 Web 服務互作性所設計。 WSHttpBinding 使用 HTTP 作為傳輸協定，並使用文字進行訊息編碼。
NetTcpBinding 和 NetNamedPipeBinding 是分別針對在跨機器與同一台機器上與其他 WCF 應用程式進行高效能通訊而設計。
如果您需要在運行時間使用一或多個自定義通訊協定通道的最大彈性，您可以使用 CustomBinding ，讓您能夠決定哪些綁定項組成系結。
備註
系結在回應時間和輸送量方面有不同的特性。 因此，提高效能的一般建議是盡可能使用 NetTcpBindind 和 NetNamesPipeBinding。
使用 TCP 傳輸和二進位訊息編碼將 WCF 配接器輸送量最大化，並將 WCF 配接器延遲降至最低
盡可能使用 WCF-NetTcp 配接器，將輸送量最大化。 WCF-NetTcp 配接器會使用 TCP/IP 傳輸通訊協定和二進位訊息編碼，相較於其他 WCF-* 配接器，這可提供改善的效能。
或者，您可以使用 自訂綁定 類型來設定 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 | 嘗試 >= 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*處理器數量 (if additional context requires explaining the term for clarity) | 1 | 嘗試 >= 20 |
| TcpTransportBindingElement.MaxPendingConnections - 取得或設定等候服務分派的連線數目上限。 這會限制等候分派的同時客戶端連線數目。 如果此值太低，服務可能會拒絕用戶端連線嘗試。 如果太高，服務在負載過重期間可能會對客戶端顯示緩慢或沒有回應。 這個屬性應該設定為值，允許服務以完整容量執行，而且不會更高。 當堆棧中的較高層呼叫 AcceptDispatch 時，該聯機會從等候分派的連線佇列中移除。 如需此屬性的詳細資訊，請參閱 MSDN 上的 ConnectionOrientedTransportBindingElement.MaxPendingConnections 屬性 （https://go.microsoft.com/fwlink/?LinkId=157735）。 | 10 | 16 * ProcessorCount | 10 | 嘗試 >= 20 |
| TcpTransportBindingElement.ListenBacklog - 取得或設定可以擱置的佇列連線要求數目上限。 ListenBacklog 是 socket 層級屬性，描述要排入佇列的等待接受要求的數量。 請確定並行連線數目上限不會超過基礎套接字佇列。 如需此屬性的詳細資訊，請參閱 MSDN 上的 TcpTransportBindingElement.ListenBacklog 屬性 （https://go.microsoft.com/fwlink/?LinkId=157734） 。 | 10 | 16*ProcessorCount | 10 | 嘗試 >= 20 |
將 ServiceThrottlingBehavior 服務行為新增至 WCF-Custom 或 WCF-CustomIsolated 接收位置，並使用下列設定：
備註
在修改 ServiceThrottlingBehavior 服務行為的任何元素之前，您必須先將 serviceThrottling 行為延伸新增至 WCF-Custom* 傳輸屬性對話框的 [行為] 索引標籤。 若要將 serviceThrottling 新增至行為清單，請選取 [WCF-自定義* 傳輸屬性] 對話框的 [行為] 索引卷標，以滑鼠右鍵按兩下 [行為] 底下的 [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。 注意：除了 WCF-Custom 和 WCF-CustomIsolated 配接器以外，BizTalk Server 的 WCF 接收配接器會在 WCF-* 傳輸屬性 對話方塊的 綁定 標籤上公開 最大並行呼叫 屬性，以設定此行為。 最大 並行呼叫 行為的預設值為 200。 | 16*ProcessorCount | 16*ProcessorCount | - BizTalk WCF-Custom 和 WCF-CustomIsolated 接收配接器使用 16。 - 200 用於其他 WCF 接收配接器。 |
- 針對 WCF-Custom 和 WCF-CustomIsolated 接收配接器，請嘗試 >= 200。 - 針對 BizTalk Server WCF 接收配接器中，除了 WCF-Custom 和 WCF-CustomIsolated 配接器以外的配接器，請在 [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*處理器數量 | 116*處理器數量 | 26 | 嘗試 >= 200 |
| ServiceThrottlingBehavior.MaxConcurrentSessions - MaxConcurrentSessions 屬性會取得或設定 ServiceHost 物件一次可接受的會話數目上限。 請務必瞭解，在此情境中，會話不僅限於支持可靠會話的通道。 每個接聽程序物件可以有一個暫止的通道會話，這些會話不會計入 MaxConcurrentSessions 的值，直到WCF 接受通道會話並開始處理通道會話訊息為止。 此屬性在會話應用場景中最為有用。 當此屬性設定為小於用戶端線程數目的值時，來自多個用戶端的要求可能會在同一個套接字聯機中排入佇列。 來自尚未建立服務會話之用戶端的要求將會遭到封鎖。 如果服務上開啟的會話數目已達到 MaxConcurrentSessions 指定的值，其它客戶端與服務的會話還未關閉前，它們將保持封鎖狀態。 對未回應的用戶端要求將會逾時，然後服務會關閉連線。 若要避免這種情況，請考慮從不同的應用程式域執行用戶端線程，讓不同的套接字連線接受要求訊息。 如需此屬性的詳細資訊，請參閱 MSDN 上的 ServiceThrottlingBehavior.MaxConcurrentSessions 屬性 （https://go.microsoft.com/fwlink/?LinkId=157864）。 | 100*處理器數量 | 100*處理器數量 | 10 | 嘗試 >= 200 |
修改埠組態設定時，會以方法方式套用變更;個別修改每個參數，並測試變更對效能和整體穩定性的影響。 一如往常，要套用的適當值取決於特定案例：如果設定值太低，則可以降低延展性;而如果設定值太高，則應用程式需求可能會超過計算機上的實體資源容量。 此外，由於這些屬性是相關的，因此應該以一致且一致的方式設定。 如需使用 ServiceThrottlingBehavior 控制 WCF 服務效能的詳細資訊，請參閱在 MSDN 上使用 ServiceThrottlingBehavior 控制 WCF 服務效能 。https://go.microsoft.com/fwlink/?LinkId=157908。