Teste de desempenho e ajuste TCP

Question

Estamos no processo de teste de desempenho de um aplicativo que recebe solicitações tcp para convertê-los em solicitações de sabão (WCF-httpBinding) em que outros serviços trabalham.

O servidor é o Windows Server 2008 R2. As solicitações TCP são recebidas pela instância TcpListener (.NET C #). Existem 3 serviços WCF vinculados a http em execução no mesmo servidor.

Criamos um cliente de teste de desempenho cujo objetivo é simular várias solicitações simultâneas (cada solicitação deve ser diferente e reconhecível pelo aplicativo).

Criamos um teste executando 150 solicitações executadas ao mesmo tempo (por 150 threads diferentes) e percebemos imediatamente que algumas solicitações obtêm a conexão TCP lentamente, mas, uma vez obtidas, elas agem rapidamente.

Uma única solicitação é gravada duas vezes na mesma solicitação de conexão e uma confirmação de aplicativo.

Embora um único pedido + ack possa demorar cerca de 150 ms, o teste de 150 demora cerca de 7 segundos.

O problema

Quando tentamos executar este teste em dois computadores diferentes, perdemos solicitações . algumas solicitações de clientes estão recebendo

no connection was made because the target machine actively refused it

Então eu tenho aqui e ficou convencido que era por causa do backlog. Eu mudei os parâmetros TcpListener e fiz o registro AFD backlog alterações escritas aqui  mas ainda não funcionou, então eu inseri todo o ajuste TCP sugerido mais alguns comandos netsh que foram recomendados, mas ainda sem mudanças, nós ainda conseguimos esse erro.

Há mais alguma coisa que eu precise saber? Existem outras soluções?

    

Answer 1

Este é um aborrecimento do Windows infeliz. Quando um servidor Windows fica sobrecarregado, ele ativamente recusa conexões (respondendo com um RST) em vez de simplesmente não responder a elas (não enviando um SYN). Para evitar que isso seja interpretado como falha, os clientes Windows geralmente tentam novamente conexões (enviando outro SYN) mesmo quando são ativamente recusados (respondem com um RST).

Você deve tentar novamente a conexão, mesmo que ela seja recusada ativamente. Obviamente, se você tentar mais conexões por segundo do que o servidor pode manipular, elas não podem ter sucesso. Como você quer lidar com este caso é com você.

Portanto, a resposta curta é: o que você quer que aconteça se obtiver mais tentativas de conexão do que o servidor pode suportar? Você quer que eles fiquem muito, muito devagar? Ou você quer que eles falhem? Se o primeiro, tente novamente para sempre, esperando mais e mais entre as tentativas. Se este último, então desista.

Aumentar o backlog ajudará a evitar que curtos períodos de carga disparem esse erro. Mas se a taxa de conexão exceder a taxa que o servidor pode manipular, você não poderá fazê-lo funcionar. Nenhum número finito de conexões de backup seria necessário porque a taxa de conexão excede a taxa de conclusão de trabalho. Então, em algum momento, você precisa começar a falhar, a menos que os clientes sejam especificamente codificados para tentar novamente para sempre.