信道开放上的WCF NetNamedPipeBinding延迟

Question

我目前正在开发一个具有SOA体系结构的应用程序，它的服务公开为.Net服务(WCF4.0)，托管在Windows 2008 R2数据中心x64 VM上的IIS7.5中(实际上它是R2 EC2上的一个m1小实例)。这些服务在机器上本地通信，因此，我已经将它们设置为使用netNamedPipeBinding以获得最佳性能。实例模式是每次调用，并发设置为多个。

我现在碰到了两个问题，当我打开200毫秒到1秒之间的通道时，我会有间歇性的延迟，这是不能接受的，因为正常的速度似乎是2毫秒。

我已经启用了WCF跟踪，并且我看到延迟本身显示为以下两个错误：

System.IO.PipeException:写入管道时出错:管道正在关闭。(232，0xe8)。

在此之后，它将出现WCF重试并成功连接(因此延迟)。第二个症状是在执行活动时延迟了半秒：

进程动作“http://tempuri.org/IConnectionRegister/ValidateUriRoute”

我能找到的唯一一件事是，有些人认为它可能与TCP端口共享有关，但我使用的是命名管道。我试着禁用TCP端口共享服务，但这并没有什么区别。

出于兴趣，我还尝试更改所有端点，以使用侦听同一随机端口上的本地主机的net.tcp，ValidateUriRoute活动中的半秒延迟仍在间歇性地发生。

我的WCF配置看起来类似于以下内容：

<system.serviceModel>

    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
                               multipleSiteBindingsEnabled="false">

      <serviceActivations>

        <add relativeAddress="ConfigurationHost.svc" service="Core.ConfigurationHost" factory="Core.ConfigurationHostFactory" />
        <add relativeAddress="RoutingHost.svc" service="Core.RoutingHost" factory="Core.RoutingHostFactory" />
        <add relativeAddress="AuthenticationHost.svc" service="Core.AuthenticationHost" factory="Core.AuthenticationHostFactory" />

      </serviceActivations>

    </serviceHostingEnvironment>

    <services>

      <service name="Core.ConfigurationHost"
               behaviorConfiguration="Unthrottled">

        <endpoint address="net.pipe://localhost/ConfigurationHost.svc"
                  binding="netNamedPipeBinding"
                  bindingConfiguration="customNetNamedPipeBinding"
                  contract="Core.IConfiguration" />

      </service>

      <service name="Core.RoutingHost"
               behaviorConfiguration="Unthrottled" >

        <endpoint address="net.pipe://localhost/RoutingHost.svc"
                  binding="netNamedPipeBinding"
                  bindingConfiguration="customNetNamedPipeBinding"
                  contract="Core.IRouting" />

      </service>

      <service name="Core.AuthenticationHost"
               behaviorConfiguration="Unthrottled">

        <endpoint address="net.pipe://localhost/AuthenticationHost.svc"
                  binding="netNamedPipeBinding"
                  bindingConfiguration="CustomNetNamedPipeBinding"
                  contract="Core.IAuthentication" />

      </service>

    </services>

    <behaviors>

      <serviceBehaviors>

        <behavior  name="Unthrottled">

          <serviceThrottling maxConcurrentCalls="100"
                             maxConcurrentSessions="100"
                             maxConcurrentInstances="100" />

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <client>

      <endpoint address="net.pipe://localhost/ConfigurationHost.svc"
                binding="netNamedPipeBinding"
                bindingConfiguration="customNetNamedPipeBinding"
                contract="Core.IConfiguration"
                name="Configuration" />

      <endpoint address="net.pipe://localhost/RoutingHost.svc"
                binding="netNamedPipeBinding"
                bindingConfiguration="customNetNamedPipeBinding"
                contract="Core.IRouting"
                name="Routing" />

      <endpoint address="net.pipe://localhost/AuthenticationHost.svc"
                binding="netNamedPipeBinding"
                bindingConfiguration="customNetNamedPipeBinding"
                contract="Core.IAuthentication"
                name="Authentication" />

    </client>

    <bindings>

      <netNamedPipeBinding>

        <binding name="customNetNamedPipeBinding"
                 maxReceivedMessageSize="2147483647"
                 sendTimeout="00:00:30"
                 receiveTimeout="infinite"
                 closeTimeout="00:00:30"
                 openTimeout="00:00:30"
                 maxConnections="500">

          <security mode="None"/>

          <readerQuotas maxDepth="200"
                        maxStringContentLength="2147483647"
                        maxArrayLength="2147483647"
                        maxBytesPerRead="2147483647"
                        maxNameTableCharCount="2147483647" />

        </binding>

      </netNamedPipeBinding>

    </bindings>

  </system.serviceModel>

Answer 1

我认为，操作定时的这两个间歇点很可能都是命名管道和TCP绑定使用的连接池机制的副产品。连接池具有最大空闲时间，之后从池中移除空闲连接。这就产生了一个固有的争用条件:偶尔可能会在另一方已丢弃为空闲的连接上尝试建立WCF通道。

我自己还没有尝试过，但是如果您更关心时间的一致性而不是绝对时间，您可以尝试调整绑定传输绑定元素上的连接池设置，或者禁用池(设置为MaxOutboundConnectionsPerEndpoint = 0)，或者减少空闲连接的发生率(更改IdleTimeout值)。

如果您不能让这种工作正常进行，或者如果您认为延迟发生的时间超过了连接池所带来的固有的可变性，那么您可能需要Microsoft工程师的帮助，因为WCF实现的内部很深。