eu tenho umWPF cliente solicitando dados viaWCF serviço hospedado emIIS 7. O método de serviço faz uma chamada para um procedimento armazenado (SQL 2012) usandoEF para recuperar alguns dados.

Há muitos dados para carregar, de modo que o cliente faça várias chamadas para o método de serviço em um esforço para "interromper" o carregamento de dados e evitar grandes cargas úteis e tempos limites.

Usamos os proxies de serviço gerados que se estendem deSystem.ServiceModel.ClientBase<T>.

Também estamos usando uma ligação http personalizada com codificação bináriaAqui) - implementação real mostrada aqui:

<customBinding>
   <binding name="CustomBinding_IPointDataAccess" closeTimeout="00:01:00"
      openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00">
      <binaryMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16" maxSessionSize="2048">
      <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="16384" />
      </binaryMessageEncoding>
      <httpTransport manualAddressing="false" maxBufferPoolSize="524288"
         maxReceivedMessageSize="2147483647" allowCookies="false" authenticationScheme="Anonymous" bypassProxyOnLocal="false" decompressionEnabled="true" hostNameComparisonMode="StrongWildcard" keepAliveEnabled="true" maxBufferSize="2147483647" proxyAuthenticationScheme="Anonymous" realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="true" />
   </binding>

Além disso, a compactação dinâmica é ativada no IIS. Eu posso ver os pedidos no Fiddler, e o tamanho do corpo da mensagem é bom (~ 50KB) e99% dos pedidos retornam em um segundo ou dois. Perfeito!

No entanto, com quase todas as iterações, há uma chamada no grupo que leva alguns minutos para ser concluída, e eu não sei porque ...sendTimeOut no cliente estava em 1 minuto e, naturalmente, que uma chamada falharia. Eu estendi para 10 minutos, e a ligação parece completar em pouco mais de 2 minutos - embora às vezes levaria ainda mais tempo. O problema parece muito aleatório - pode ser a primeira chamada, pode ser a 30ª chamada. Mas é muito reproduzível.

Eu coloquei alguns logs em torno da chamada de procedimento armazenado no método de serviço WCF e ele executa e recupera os dados em menos de um segundo. Então, não acho que seja um problema de banco de dados.

Usando o Fiddler, a chamada problemática gera uma saída semelhante à seguinte:

ACTUAL PERFORMANCE
--------------
ClientConnected:     14:02:42.959
ClientBeginRequest:  14:03:01.224
GotRequestHeaders:   14:03:01.224
ClientDoneRequest:   14:03:01.574
Determine Gateway:   0ms
DNS Lookup:      0ms
TCP/IP Connect:  46ms
HTTPS Handshake:     0ms
ServerConnected:     14:05:16.021
FiddlerBeginRequest: 14:05:16.021
ServerGotRequest:    14:05:16.021
ServerBeginResponse: 14:03:04.784
GotResponseHeaders:  14:05:16.561
ServerDoneResponse:  14:05:16.611
ClientBeginResponse: 14:05:16.611
ClientDoneResponse:  14:05:16.611

Observe o tempo significativo entreServerBeginResponse eGotResponseHeaders. Isso parece muito semelhante ao problema vistoAqui.

Eu habilitei o WCF Service Tracing e, em um piscar de olhos, não há erros ou avisos, mas não consigo fazer muito mais sentido do que estou vendo além do básico.

Como posso saber o que e onde está o problema? É serialização? É um problema de rede? O servidor não consegue acompanhar o cliente enviando tantas solicitações?

Eu tentei ajustar o estrangulamento do WCF no arquivo de configuração, adicionando o apropriadoserviceBehaviors, mas isso não fez diferença.

Devo mencionar que estou fazendo isso através de uma conexão VPN, mas outras coisas, como transferências de arquivos, conexões de desktop remoto funcionam muito bem. Parece bastante confiável.

Eu posso fornecer mais detalhes, se necessário.

Editar (6.10.2013): Não tenho certeza se isso está relacionado ou apenas um acaso, mas algumas vezes, notei que na chamada problemática, o tamanho do corpo é significativamente menor do que os outros. Este não é o caso de cada vez, mas pode fornecer algumas pistas. Aqui está uma captura de tela do Fiddler para mostrar a você como o tamanho do corpo deve ser consistente com cada chamada. A entrada selecionada (# 21) é muito menor que as outras em tamanho, mas leva mais de 2 minutos para ser concluída.

Curiosamente, desta vez recebi uma exceção. A exceção não acontece todas as vezes.

System.ServiceModel.CommunicationException: The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error.

Server stack trace: 
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)