Pular para o conteúdo principal
"Acabamos de atualizar de um T1 (1,544 mbps) para um T3 (44,736 mbps), então por que ainda leva 90 minutos para copiar esse arquivo?"

 

A resposta simples é que mais capacidade não é o mesmo que bytes mais rápidos. Se você aumentar sua capacidade em quase 29 (44.736 / 1.544) vezes, você pode ser capaz de copiar 29 arquivos nos mesmos 90 minutos, mas provavelmente não será capaz de copiar aquele arquivo mais rápido. Tocamos nisto no ano passado no blog intitulado "Application Performance Problems and Latency", mas acho que transferências de arquivos e copy_file requerem um blog mais focado.

 

A chave tem a ver com os tamanhos das janelas, ou seja, quantos bytes o host/candidato que envia sem ter que parar e esperar por um reconhecimento do host/candidato que recebe. Algumas aplicações como FTP não têm um reconhecimento de camada de aplicação e dependem do TCP. Neste caso, o tamanho da janela é baseado no que a camada TCP do host remoto anuncia, até 64K bytes, que é o máximo que o STCP suporta. Algumas aplicações têm uma janela de camada de aplicação, para estas aplicações a janela limitadora é a menor das janelas TCP e de aplicação.
A capacidade máxima de produção é calculada como

 

W / RTT = T
Onde
W é o tamanho da janela em bytes
RTT é o tempo de ida e volta em segundos
T é a produção em bytes por segundo
O tempo de viagem de ida e volta é o tempo necessário para enviar alguns dados e obter o reconhecimento. Para grandes distâncias, ou seja, para atravessar o país, esse tempo se baseia principalmente na distância que os bytes devem percorrer e na velocidade de processamento de todos os equipamentos da rede entre os pontos finais. A velocidade de processamento do host receptor, tamanhos de pacotes (valor TCP MSS, ver "Uma maneira fácil de melhorar a produtividade através de sub-redes") e, é claro, a largura de banda do link mais lento desempenham papéis menores.

 

Por exemplo, se o RTT for 0,050 segundos e a janela for 64K, a produção máxima será de 1.310.720 bytes por segundo (64 * 1024 / 0,050). Enquanto a capacidade não utilizada do link for maior do que a capacidade de transferência, o aumento da capacidade não acelerará o tempo de transferência.
T é a máxima produtividade possível. Nada que você faça (a não ser aumentar a janela ou reduzir o RTT) pode fazer as coisas andarem mais rápido MAS as condições hostis da rede podem fazer as coisas andarem consideravelmente mais lentas.

 

A estimativa do tempo de transferência é apenas a divisão do tamanho do arquivo por rendimento

 

F/ W * RTT = Ti
Onde
F é o tamanho do arquivo em bytes
W é o tamanho da janela em bytes
RTT é o tempo de ida e volta em segundos
Ti é tempo em segundos para transferir o arquivo

 

OSL tem uma janela de aplicação de 4K, o sistema de arquivo OpenVOS reporta tamanhos de arquivo em blocos de 4K bytes, de modo a estimar o tempo para copiar um arquivo entre dois sistemas OpenVOS usando o comando copy_file, é simplesmente

 

F * RTT = Ti
Onde
F é o tamanho do arquivo em blocos
RTT é o tempo de ida e volta em segundos
Ti é tempo em segundos para transferir o arquivo

 

Em um link com um RTT de 0,050 segundo, levará um pouco mais de 41 minutos para copiar um arquivo de 50.000 blocos (50.000 * 0,05). A produção máxima será de 81.920 bytes por segundo (4096 / 0,050). Enquanto a capacidade não utilizada da rede de seu link for maior que 81.920 bytes por segundo, a adição de capacidade não reduzirá o tempo necessário para copiar o arquivo.

 

A maneira mais simples de medir o tempo de ida e volta é com o ping. Infelizmente, o ping não dá um número para RTT, mas vários números e os números podem variar significativamente, por exemplo:

 

ping 172.16.1.80
Pinging host 172.16.1.80 : 172.16.1.80
ICMP Echo Reply:TTL 53 time = 418 ms
ICMP Echo Reply:TTL 53 time = 107 ms
ICMP Echo Reply:TTL 53 time = 91 ms
ICMP Echo Reply:TTL 53 time = 100 ms
Host 172.16.1.80 replied to all 4 of the 4 pings
ready 12:03:15

 

Se você estiver interessado em calcular o melhor rendimento possível, utilize o menor número possível. Se você estiver interessado em uma estimativa razoável do que você deve esperar, use uma contagem de ping de 10, jogue fora os dois números mais altos e 2 mais baixos e faça uma média do restante.

 

ping 172.16.1.80 -count 10
Pinging host 172.16.1.80 : 172.16.1.80
ICMP Echo Reply:TTL 53 time = 89 ms
ICMP Echo Reply:TTL 53 time = 96 ms
ICMP Echo Reply:TTL 53 time = 95 ms
ICMP Echo Reply:TTL 53 time = 105 ms
ICMP Echo Reply:TTL 53 time = 186 ms
ICMP Echo Reply:TTL 53 time = 87 ms
ICMP Echo Reply:TTL 53 time = 90 ms
ICMP Echo Reply:TTL 53 time = 90 ms
ICMP Echo Reply:TTL 53 time = 89 ms
ICMP Echo Reply:TTL 53 time = 96 ms
Host 172.16.1.80 replied to all 10 of the 10 pings
ready 12:12:39
calc 96 + 95 + 90 + 90 + 89 + 96
556
ready 12:12:49
calc 556 / 6
92.6666666666667
ready 12:12:57

 

Como eu disse acima, uma rede hostil pode retardar as coisas significativamente. Os intervalos de ping são uma indicação disso. Portanto, qualquer intervalo de tempo significa que estes cálculos provavelmente são significativamente otimistas. As transferências também podem ser atrasadas por discos ocupados e ou CPUs que impedem o remetente de ler e enviar os dados o mais rápido possível ou fazem com que o receptor leia os dados mais lentamente do que sua taxa de chegada, atrasando o reconhecimento do pedido (aumentando o tempo de ida e volta) e possivelmente enchendo o TCP recebe buffers que fazem com que o host remetente pare de transmitir. A única maneira de saber se alguma destas condições se aplica é com um traço de pacote.

© 2024 Stratus Technologies.