优化 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 基本配置文件 1.1 的其他服务进行通信的终结点。 配置传输安全性时，BasicHttpBinding 默认不使用任何凭据，就像使用经典 ASMX Web 服务一样。 BasicHttpBinding 允许在 IIS 7.5 或 IIS 7.0 中托管 WCF 服务。
如果 WCF 客户端将通过 Internet 调用 WCF 服务，则应使用 WsHttpBinding。 对于无需支持需要 ASMX Web 服务的旧客户端且 WsHttpBinding 允许在 IIS 7.5 或 IIS 7.0 中托管 WCF 服务的 Internet 方案，WsHttpBinding 是一个不错的选择。 如果确实需要支持旧版客户端，请考虑改用 BasicHttpBinding。 需要公开 WCF 接收位置或采用支持 WS-* 协议（如 WS-Security 或 WS-AtomicTransactions）的发送端口时，应使用 WsHttpBinding。
如果需要支持 Intranet 中的客户端，NetTcpBinding 是一个很好的选择。 如果传输性能对你很重要，并且可以在 Windows 服务而不是 IIS 中托管服务，NetTcpBinding 是 Intranet 方案的不错选择。 如果要为 .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 | 文本 | Message | 已禁用 | WS-AtomicTransactions |
| NetTcpBinding | TCP | 二进制 | 传输 | 已禁用 | OleTransactions |
| NetNamedPipesBinding | 命名管道 | 二进制 | 传输 | 不支持 | OleTransactions |
| NetMsmqBinding | MSMQ | 二进制 | Message | 不支持 | 不支持 |
| CustomBinding | 你决定 | 你决定 | 你决定 | 你决定 | 你决定 |
可以根据通信需求选择特定的绑定。 例如：
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-* 适配器相比，这些协议提供更高的性能。
或者，可以为具有 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* Transport Properties 对话框的“行为”选项卡。 若要将 serviceThrottling 添加到行为列表，请选择“WCF-Custom* Transport Properties”对话框的“行为”选项卡，右键单击“行为”下的“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 | - 16，用于 BizTalk WCF-Custom 和 WCF-CustomIsolated 接收适配器。 - 200（对于其他 WCF 接收适配器）。 |
- 对于 WCF-Custom 和 WCF-CustomIsolated 接收适配器，请尝试 >= 200。 - 对于除 WCF-Custom 和 WCF-CustomIsolated 适配器以外的 WCF 接收适配器，请在 WCF 的“绑定”选项卡上“传输属性”BizTalk Server 对话框的“最大并发调用数”对话框中尝试 > 200。 |
| ServiceThrottlingBehavior.maxConcurrentInstances - 获取或设置一个值，该值指定服务中可同时执行的最大 InstanceContext 对象数。 MaxConcurrentInstances 属性指定服务中 InstanceContext 对象的最大数目。 请务必记住 MaxConcurrentInstances 属性与 InstanceContextMode 属性之间的关系。 如果 InstanceContextMode 为 PerSession，则生成的值为会话总数。 如果 InstanceContextMode 为 PerCall，则生成的值为并发调用数。 如果消息在 实例 对象的最大数目已存在时到达，则消息将一直保留到 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 对象一次可以接受的最大会话数。 请务必了解，在这种情况下，会话并不仅限于支持可靠会话的通道。 每个侦听器对象可以有一个挂起的通道会话，在 WCF 接受通道会话并开始处理通道会话消息之前，该会话不计入 MaxConcurrentSessions 的值。 在使用会话的方案中，此属性是最有用的。 如果将此属性设置为一个小于客户端线程数的值，则来自多个客户端的请求可能会在同一套接字连接中进行排队。 来自尚未与服务创建会话的客户端的请求将被阻止。 如果服务上的打开会话数已达到为 MaxConcurrentSessions 指定的值，则服务将一直被阻止，直到服务关闭与其他客户端的会话。 然后，未提供服务的客户端请求将超时，服务将关闭会话。 若要避免这种情况，请考虑运行来自不同应用程序域的客户端线程，以便请求消息由不同的套接字连接接受。 有关此属性的详细信息，请参阅 MSDN 上的 ServiceThrottlingBehavior.MaxConcurrentSessions 属性 (https://go.microsoft.com/fwlink/?LinkId=157864) 。 | 100*ProcessorCount | 100*ProcessorCount | 10 | Try >= 200 |
修改端口配置设置时，有条不紊地应用更改;单独修改每个参数，并测试更改对性能和整体稳定性的影响。 与往常一样，要应用的正确值取决于特定场景：如果值设置得太低，可伸缩性可能会降低;如果值设置得太高，则应用程序要求可能会超过计算机上物理资源的容量。 此外，由于这些属性是相关的，因此应以一致且一致的方式设置它们。 有关使用 ServiceThrottlingBehavior 控制 WCF 服务性能的详细信息，请参阅 使用 ServiceThrottlingBehavior 控制 WCF 服务性能 (https://go.microsoft.com/fwlink/?LinkId=157908 MSDN 上的) 。