Investigação detalhada da exceção de tempo limite do WCF

Temos um aplicativo que possui um serviço WCF (* .svc) em execução no IIS7 e vários clientes que consultam o serviço. O servidor está executando o Win 2008 Server. Os clientes estão executando o Windows 2008 Server ou o Windows 2003 Server. Estou recebendo a seguinte exceção, que percebi que pode, na verdade, estar relacionada a um grande número de possíveis problemas do WCF.

System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9320000. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. ---> System.TimeoutException: The HTTP request to 'http://www.domain.com/WebServices/myservice.svc/gzip' has exceeded the allotted timeout of 00:01:00. The time allotted to this operation may have been a portion of a longer timeout. 

Aumentei o tempo limite para 30 minutos e o erro ainda ocorreu. Isso me diz que algo mais está em jogo, porque a quantidade de dados nunca levaria 30 minutos para ser carregada ou baixada.

O erro vem e vai. No momento, é mais frequente. Não parece importar se eu tenho 3 clientes rodando simultaneamente ou 100, ainda ocorre de vez em quando. Na maioria das vezes, não há limites de tempo, mas ainda consigo alguns por hora. O erro vem de qualquer um dos métodos invocados. Um desses métodos não possui parâmetros e retorna alguns dados. Outro recebe muitos dados como parâmetro, mas executa de forma assíncrona. Os erros sempre se originam do cliente e nunca fazem referência a nenhum código no servidor no rastreamento da pilha. Sempre termina com:

 at System.Net.HttpWebRequest.GetResponse()
  at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)

No servidor: Tentei (e atualmente tenho) as seguintes configurações de ligação:

maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647"

Não parece ter impacto.

Eu tentei (e atualmente tenho) as seguintes configurações de limitação:

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

Não parece ter impacto.

Atualmente, tenho as seguintes configurações para o serviço WCF.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)]

Eu corri com ConcurrencyMode.Multiple um pouco e o erro ainda ocorreu.

Tentei reiniciar o IIS, reiniciar meu SQL Server subjacente, reiniciar a máquina. Tudo isso parece não ter impacto.

Tentei desativar o firewall do Windows. Não parece ter impacto.

No cliente, tenho estas configurações:

maxReceivedMessageSize="2147483647"

<system.net>
    <connectionManagement>
    <add address="*" maxconnection="16"/>
</connectionManagement> 
</system.net>

Meu cliente fecha suas conexões:

var client = new MyClient();

try
{
    return client.GetConfigurationOptions();
}
finally
{
    client.Close();
}

Mudei as configurações do registro para permitir mais conexões de saída:

MaxConnectionsPerServer=24, MaxConnectionsPer1_0Server=32.

Tentei recentemente o SvcTraceViewer.exe. Consegui pegar uma exceção no lado do cliente. Vejo que sua duração é de 1 minuto. Olhando para o rastreamento do lado do servidor, posso ver que o servidor não está ciente dessa exceção. A duração máxima que consigo ver é de 10 segundos.

Eu olhei para conexões de banco de dados ativas usando exec sp_who no servidor. Eu só tenho alguns (2-3). Eu olhei para conexões TCP de um cliente usando TCPview. Geralmente é cerca de 2-3 e eu vi até 5 ou 6.

Simplificando, estou perplexo. Tentei tudo o que pude encontrar e deve estar faltando algo muito simples que um especialista WCF seria capaz de ver. Tenho a sensação de que algo está bloqueando meus clientes no baixo nível (TCP), antes que o servidor realmente receba a mensagem e / ou que algo está enfileirando as mensagens no nível do servidor e nunca permitindo que sejam processadas.

Se você tiver quaisquer contadores de desempenho que eu deva examinar, entre em contato. (indique quais valores são ruins, pois alguns desses contadores são difíceis de decifrar). Além disso, como posso registrar o tamanho da mensagem WCF? Finalmente, existem ferramentas disponíveis que me permitiriam testar quantas conexões posso estabelecer entre meu cliente e servidor (independentemente de meu aplicativo)

Obrigado pelo seu tempo!

Informações extras adicionadas em 20 de junho:

Meu aplicativo WCF faz algo semelhante ao seguinte.

while (true)
{
   Step1GetConfigurationSettingsFromServerViaWCF(); // can change between calls
   Step2GetWorkUnitFromServerViaWCF();
   DoWorkLocally(); // takes 5-15minutes. 
   Step3SendBackResultsToServerViaWCF();
}

Usando o WireShark, vi que, quando o erro ocorre, tenho cinco retransmissões de TCP seguidas por uma redefinição de TCP posteriormente. Meu palpite é que o RST está vindo do WCF interrompendo a conexão. O relatório de exceção que recebo é do tempo limite da Etapa 3.

Eu descobri isso olhando para o fluxo tcp "tcp.stream eq 192". Em seguida, expandi meu filtro para "tcp.stream eq 192 e http e http.request.method eq POST" e vi 6 POSTs durante esse fluxo. Isso parecia estranho, então verifiquei com outro stream, como tcp.stream eq 100. Tive três POSTs, o que parece um pouco mais normal porque estou fazendo três chamadas. No entanto, eu fecho minha conexão após cada chamada do WCF, então eu esperava uma chamada por fluxo (mas não sei muito sobre TCP).

Investigando um pouco mais, eu despejei a carga do pacote http no disco para ver o que essas seis chamadas eram.

1) Step3
2) Step1
3) Step2
4) Step3 - corrupted
5) Step1
6) Step2

Meu palpite é que dois clientes simultâneos estão usando a mesma conexão, por isso vi duplicatas. No entanto, ainda tenho mais alguns problemas que não consigo compreender:

a) Por que o pacote está corrompido? Acaso aleatório da rede - talvez? A carga é compactada usando este código de amostra: http://msdn.microsoft.com/en-us/library/ms751458.aspx - O código pode apresentar erros de vez em quando quando usado simultaneamente? Devo testar sem a biblioteca gzip.

b) Por que eu veria as etapas 1 e 2 em execução APÓS o tempo limite da operação corrompida expirar? Parece-me que essas operações não deveriam ter ocorrido. Talvez eu não esteja olhando para o fluxo certo porque minha compreensão do TCP é falha. Tenho outros streams que ocorrem ao mesmo tempo. Devo investigar outros fluxos - uma rápida olhada nos fluxos 190-194 mostra que o POST do Step3 tem dados de carga útil adequados (não corrompidos). Me empurrando para olhar para a biblioteca gzip novamente.

Se você estiver usando um cliente .Net, você pode não ter definido

//This says how many outgoing connection you can make to a single endpoint. Default Value is 2
System.Net.ServicePointManager.DefaultConnectionLimit = 200;

aqui está a pergunta original e a resposta Limitação de serviço WCF

Atualizar :

Esta configuração vai para o aplicativo cliente .Net pode estar na inicialização ou a qualquer hora, mas antes de iniciar seus testes.

Além disso, você pode tê-lo no arquivo app.config, bem como seguir

<system.net>
    <connectionManagement>
      <add maxconnection = "200" address ="*" />
    </connectionManagement>
  </system.net>

Se você ainda não tentou, encapsule suas operações WCF do lado do servidor em blocos try / finally e adicione o log para garantir que eles estejam realmente retornando.

Se eles mostrarem que as operações estão sendo concluídas, minha próxima etapa seria ir para um nível inferior e examinar a camada de transporte real.

O Wireshark ou outra ferramenta de captura de pacote semelhante pode ser bastante útil neste ponto. Presumo que seja executado em HTTP na porta 80 padrão.

Execute o Wireshark no cliente. Em Opções ao iniciar a captura, defina o filtro de captura paratcp http and host service.example.com - isso reduzirá a quantidade de tráfego irrelevante.

Se possível, modifique seu cliente para notificá-lo da hora exata de início da chamada e a hora em que o tempo limite ocorreu. Ou apenas monitore de perto.

Ao obter um erro, você pode vasculhar os registros do Wireshark para encontrar o início da chamada. Clique com o botão direito no primeiro pacote que tem seu cliente chamando-o (deve ser algo como GET /service.svc ou POST /service.svc) e selecione Seguir fluxo TCP.

O Wireshark decodificará toda a conversação HTTP, para que você possa garantir que o WCF está realmente enviando respostas.

de: http://www.codeproject.com/KB/WCF/WCF_Operation_Timeout_.aspx

Para evitar esse erro de tempo limite, precisamos configurar a propriedade OperationTimeout para Proxy no código do cliente WCF. Essa configuração é algo novo, ao contrário de outras configurações, como Tempo limite de envio, Tempo limite de recebimento etc., que discuti no início do artigo. Para definir essa configuração de propriedade de tempo limite de operação, temos que lançar nosso proxy para IContextChannel no aplicativo cliente WCF antes de chamar os métodos de contrato de operação.

Estou tendo um problema muito parecido. No passado, isso estava relacionado a problemas de serialização. Se você ainda estiver tendo esse problema, verifique se consegue serializar corretamente os objetos que está retornando. Especificamente, se você estiver usando objetos Linq-To-Sql que têm relacionamentos, haverá problemas de serialização conhecidos se você colocar uma referência anterior em um objeto filho para o objeto pai e marcar essa referência anterior como um DataMember.

Você pode verificar a serialização escrevendo um aplicativo de console que serializa e desserializa seus objetos usando o DataContractSerializer no lado do servidor e quaisquer métodos de serialização que seu cliente use. Por exemplo, em nosso aplicativo atual, temos clientes WPF e Compact Framework. Eu escrevi um aplicativo de console para verificar se posso serializar usando um DataContractSerializer e desserializar usando um XmlDesserializer. Você pode tentar isso.

Além disso, se você estiver retornando objetos Linq-To-Sql que possuem coleções filho, você pode tentar garantir que os carregou antecipadamente no lado do servidor. Às vezes, devido ao carregamento lento, os objetos retornados não são preenchidos e podem causar o comportamento que você está vendo, quando a solicitação é enviada ao método de serviço várias vezes.

Se você já resolveu esse problema, adoraria saber como, porque também estou preso a ele. Eu verifiquei que meu problema não é a serialização, então estou perdido.

ATUALIZAÇÃO: Não tenho certeza se isso irá ajudá-lo, mas a ferramenta Service Trace Viewer apenas resolveu meu problema após 5 dias de experiência muito semelhante à sua. Configurando o rastreamento e examinando o XML bruto, encontrei as exceções que estavam causando meus problemas de serialização. Ele estava relacionado a objetos Linq para SQL que ocasionalmente tinham mais objetos filho do que poderiam ser serializados com êxito. Adicionar o seguinte ao seu arquivo web.config deve permitir o rastreamento:

<sharedListeners>
    <add name="sharedListener"
         type="System.Diagnostics.XmlWriterTraceListener"
         initializeData="c:\Temp\servicetrace.svclog" />
  </sharedListeners>
  <sources>
    <source name="System.ServiceModel" switchValue="Verbose, ActivityTracing" >
      <listeners>
        <add name="sharedListener" />
      </listeners>
    </source>
    <source name="System.ServiceModel.MessageLogging" switchValue="Verbose">
      <listeners>
        <add name="sharedListener" />
      </listeners>
    </source>
  </sources>

O arquivo resultante pode ser aberto com a ferramenta Service Trace Viewer ou apenas no IE para examinar os resultados.

Você está fechando a conexão com o serviço WCF entre as solicitações? Caso contrário, você verá esse tempo limite exato (eventualmente).

Acabei de resolver o problema. Descobri que os nós no arquivo App.config foram configurados incorretamente.

<client>
<endpoint name="WCF_QtrwiseSalesService" binding="wsHttpBinding" bindingConfiguration="ws" address="http://cntgbs1131:9005/MyService/TGE.ISupplierClientManager" contract="*">
</endpoint>
</client>

<bindings>
    <wsHttpBinding>
        <binding name="ws" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" messageEncoding="Text">
            <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647"/>
            <**security mode="None">**
                <transport clientCredentialType="None"></transport>
            </security>
        </binding>
    </wsHttpBinding>
</bindings>

Confirme sua configuração no nó <security>, o valor do atributo "modo" é "Nenhum". Se o seu valor for "Transporte", o erro ocorre.

Você tentou usar clientVia para ver a mensagem enviada, usando o kit de ferramentas SOAP ou algo parecido? Isso pode ajudar a ver se o erro está vindo do próprio cliente ou de outro lugar.

Você verificou os traços do WCF? O WCF tem a tendência de engolir exceções e retornar apenas a última exceção, que é o tempo limite que você está obtendo, uma vez que o ponto final não retornou nada significativo.

Você também receberá esse erro se estiver passando um objeto de volta para o cliente que contém uma propriedade do tipo enum que não é definida por padrão e que enum não tem um valor que mapeia para 0. ie enum MyEnum{ a=1, b=2};

Parece que esta mensagem de exceção é bastante genérica e pode ser recebida por vários motivos. Corremos para isso durante a implantação do cliente em máquinas Windows 8.1. Nosso cliente WCF é executado dentro de um serviço do Windows e pesquisa continuamente o serviço WCF. O serviço do Windows é executado em um usuário não administrador. O problema foi corrigido definindo o clientCredentialType como "Windows" na configuração do WCF para permitir a passagem de autenticação, como a seguir:

      <security mode="None">
        <transport clientCredentialType="Windows" proxyCredentialType="None"
          realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>

Não sou um especialista em WCF, mas gostaria de saber se você não está executando uma proteção DDOS no IIS. Sei por experiência própria que se você executar várias conexões simultâneas de um único cliente para um servidor em algum ponto, o servidor para de responder às chamadas, pois suspeita de um ataque DDOS. Ele também manterá as conexões abertas até que o tempo limite seja atingido, a fim de diminuir a velocidade do cliente em seus ataques.

No entanto, várias conexões provenientes de máquinas / IPs diferentes não devem ser um problema.

Há mais informações nesta postagem do MSDN:

http://msdn.microsoft.com/en-us/library/bb463275.aspx

Verifique a sproperty MaxConcurrentSession.