Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Certas técnicas de programação esbarram em problemas de desempenho que estão ligados à implementação do TCP/IP. Tais problemas de desempenho não sugerem que o TCP/IP seja ineficiente ou um gargalo de desempenho; em vez disso, esses problemas são vistos quando as operações TCP/IP não são compreendidas.
Os problemas a seguir identificam cenários comuns nos quais a combinação de operação TCP/IP e opções de desenvolvimento de aplicativos de rede resulta em baixo desempenho.
Conecte aplicativos pesados.
Alguns aplicativos instanciam uma nova conexão TCP para cada transação. O estabelecimento da conexão TCP leva tempo, contribui com RTTs extras e está sujeito a inicialização lenta. Além disso, as conexões fechadas estão sujeitas a TIME-WAIT, que consome recursos do sistema.
Aplicativos pesados de conexão são comuns em grande parte porque são fáceis de criar; Os testes e o tratamento de erros são muito simples. Detetar falhas em uma conexão persistente pode exigir código e esforço consideráveis e, portanto, às vezes não é concluído.
Corrija essa situação reutilizando a conexão TCP. Isso pode causar serialização na conexão TCP, a menos que as transações sejam multiplexadas em várias conexões. Se essa abordagem for adotada, o número de conexões deve ser limitado a duas, e o enquadramento da camada de aplicativo e o tratamento avançado de erros são necessários.
Buffers de envio de comprimento zero e envios de bloqueio.
Desativar o buffer usando a função setsockopt para definir o buffer de envio (SO_SNDBUF) como zero é semelhante a desativar o cache de disco. Ao definir o buffer de envio como zero e emitir envios de bloqueio, um aplicativo tem cinquenta por cento de chance de atingir uma confirmação atrasada de 200 milissegundos.
Não desative o buffer de envio a menos que tenha considerado o impacto em todos os ambientes de rede. Uma exceção: o streaming de dados usando E/S sobreposta deve definir o buffer de envio como zero.
Modelo de programação deSend-Receive de envio.
Estruturar um aplicativo para executar send-send-gets aumenta suas chances de encontrar o algoritmo Nagle, o que causa um atraso de RTT+200 ms. O algoritmo Nagle pode ser encontrado se o último envio for menor que o tamanho máximo de segmento TCP (MSS, os dados máximos em um único datagrama). MSS pode ser um valor muito grande (64K em IPv4, e ainda maior em IPv6), por isso não conte com um MSS tipicamente pequeno. Uma opção melhor é combinar os dois envios em um único envio usando o WSASend ou função memcpy.
Grande número de conexões simultâneas.
As ligações simultâneas não devem exceder duas, exceto em aplicações para fins especiais. Exceder duas conexões simultâneas resulta em desperdício de recursos. Uma boa regra é ter até quatro conexões de curta duração, ou duas conexões persistentes por destino.
Tópicos relacionados