WCF NetNamedPipeBinding 지연 채널 열기

Question

현재 SOA 아키텍처로 응용 프로그램을 개발 중입니다. 서비스는 Windows Server 2008 R2 Datacenter x64 VM의 IIS 7.5에서 호스팅되는 WCF 서비스 (.Net 4.0)로 공개됩니다 (사실 Amazon EC2의 m1.small 인스턴스). 이러한 서비스는 머신에서 로컬로 서로 이야기하며 최적의 성능을 위해 netNamedPipeBinding을 사용하도록 설정했습니다. 인스턴스화 모드는 호출 당이며 동시성은 다중으로 설정됩니다.

순간적으로 두 가지 문제가 발생하여 200ms에서 1s 사이의 채널을 열 때 간헐적 인 지연이 발생합니다. 보통 속도는 ~ 2ms 인 것처럼 받아 들일 수 없습니다.

나는 WCF 추적을 사용하도록 설정하고 나는 지연의 오류 중 하나로서 자신을 나타낼 것으로보고있다 :

System.IO.PipeException : 파이프에 쓰는 중 오류가 발생했습니다 파이프 닫히고 있습니다. (232, 0xe8).

그 후 WCF 재 시도가 성공적으로 연결되므로 (따라서 지연이 발생 함) 두 번째 증상은 활동을 수행하는 0.5 초 지연입니다 :

프로세스 액션 'http://tempuri.org/IConnectionRegister/ValidateUriRoute을'

나는이 문제를 찾을 수있는 유일한 방법은이다 어떤 사람들은 TCP 포트 공유와 관련이 있다고 생각하지만 명명 된 파이프를 사용하고 있습니다. 나는 TCP Port Sharing 서비스를 사용하지 못하게 시도했지만 아무런 차이가 없었다. 관심의 아웃

는 또한 모든 엔드 포인트가 같은 임의의 포트에 로컬 호스트에서 수신 net.tcp 사용하도록 변경 시도하고 ValidateUriRoute 활동 내에서 0.5 초 지연은 여전히 ​​간헐적으로 발생했습니다.

내 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) 또는 발생률을 줄이기 위해 connection pool settings on the binding's transport binding element을 조정 해 볼 수 있습니다. 유휴 연결 (변경 IdleTimeout 값).

당신이 그 일을 할 수 없거나 지연이 발생했을 때 연결 풀링이 내재하는 고유 한 가변성을 고려해야 할 때보 다 더 길다면 Microsoft 엔지니어의 도움이 필요할 것입니다 이 물건은 WCF 구현의 내부 깊숙한 곳에 있기 때문에.