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實施的內部很深。