WCF NetNamedPipeBinding延迟通道打开

Question

我目前正在开发一个应用程序与一个SOA架构，作为WCF服务（.Net 4.0）托管在Windows Server 2008 R2数据中心x64虚拟机上的IIS 7.5中的服务（它是在实际上是Amazon EC2上的m1.small实例）。这些服务在机器上以本地方式彼此对话，因此我将它们设置为使用netNamedPipeBinding以获得最佳性能。实例化模式是每个调用，并发设置为多个。

我遇到两个问题，当我打开200毫秒到1秒之间的通道时，间歇性延迟，这是不可接受的，因为正常速度似乎是〜2ms。

我已经启用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信道的尝试可能会在另一方刚被丢弃为空闲的连接上进行。

我还没有自己尝试过，但是如果您更关心定时的一致性而不是绝对时间，则可以尝试调整connection pool settings on the binding's transport binding element，以禁用池化（设置MaxOutboundConnectionsPerEndpoint = 0）或减少空闲连接（更改IdleTimeout值）。

如果您无法完成这项工作，或者如果您认为延迟发生的时间比它们甚至应该考虑连接池引入的固有可变性的时间要长，那么您可能需要Microsoft工程师的帮助，因为这些东西在WCF实施的内部很深。