Problemas de desempenho e latência de aplicações

O impacto da latência da camada de comunicação é tipicamente subestimado quando se tenta corrigir problemas de desempenho da aplicação, mas a compreensão correta é crítica se você quiser direcionar seus esforços para soluções práticas.

Primeiro, por latência da camada de comunicação quero dizer o tempo que leva um pacote para ir do sistema local para o sistema remoto e voltar novamente. O maior fator na latência da camada de comunicação é a distância - pelo menos para hosts geograficamente separados. O outro componente principal é o número de dispositivos entre os hosts local e remoto que processam os pacotes; isto inclui coisas como roteadores e firewalls. A largura de banda dos links desempenha um papel, mas não tão grande quanto a maioria das pessoas pensa. A largura de banda afeta o atraso de inserção - quanto tempo leva para colocar um pacote no fio, mas o sinal no fio viaja a uma velocidade baseada no meio e não na largura de banda. Para o resto desta discussão, vou apenas usar a latência quando me refiro à latência da camada de comunicação.

Para demonstrar como a latência afeta sua aplicação, digamos que você introduza alguns dados em uma aplicação do cliente e acerte o retorno. A aplicação cliente envia uma mensagem para uma aplicação servidor, espera por uma resposta e depois envia outra mensagem, espera por uma resposta, etc.; para algum número N de "voltas". Ao final de N voltas, a aplicação cliente apresenta os resultados de volta para você.

Assumir que 10 voltas são necessárias e o aplicativo servidor leva 1ms para processar a mensagem do cliente e enviar de volta uma resposta. Com uma latência de 1ms você recebe um tempo de resposta de 10 * (1ms + 1ms) ou 20ms. Agora entre em um avião e viaje para Chicago, o servidor fica em Boston para que você tenha agora uma latência de, digamos, 50ms e um tempo de resposta de 10 * (50ms + 1ms) ou 550ms. Isto é suficiente para ser perceptível, mas não doloroso. Aumente o número de voltas para 100 e agora você tem um doloroso tempo de resposta de 5,5 segundos. Você pode pensar que 100 voltas é excessivo, mas algumas consultas complexas de banco de dados ou pedidos que preenchem formulários complexos podem fazer exatamente isso. Você sabe quantas voltas suas aplicações requerem?
Fazer um copy_file via OSL também exibe este comportamento. A OSL enviará um arquivo em transações de 4K. Cada transação requer uma resposta, portanto um arquivo de 1.000.000 bytes exigirá 1.000.000 / 4.096 = 245 transações ou turnos para usar a nomenclatura do parágrafo anterior. Novamente, assumindo 1ms para processar a transação e uma latência de 1ms o arquivo_cópia levará 490ms. Se aumentarmos a latência para 50ms, levará 12.495 segundos. Se aumentarmos o arquivo para 1.000.000.000 de bytes, serão necessárias 244.141 transações; com tempos correspondentes de 488.282 segundos para uma latência de 1ms e 12.451.191 segundos ou quase 3,5 horas para uma latência de 50ms.

A maneira mais simples de medir a latência é com ping.

Você também pode usar um programa que eu escrevi que vezes as conexões sem necessidade de usar o packet_monitor. Veja http://members.cox.net/ndav1/self_published/stcp_tping.doc. O comando stcp_tping requer que você se conecte a uma porta ativa no host remoto. Neste caso, estou usando a porta 23 (telnet), mas qualquer porta ativa funcionará. O número 1 no final do comando indica que um pedido será enviado uma vez por segundo.