Metodologias para testar o desempenho de um link WAN

11

Temos um par de novos links Ethernet de 1 Gbps com roteamento diversificado entre locais a cerca de 200 milhas de distância. O 'cliente' é uma nova máquina razoavelmente poderosa (HP DL380 G6, dois E56xx Xeons, DDR3 de 48GB, par R1 de discos SAS de 300GB 10krpm, W2K8R2-x64) e o 'servidor' também é uma máquina decente o suficiente (HP BL460c G6 , duplos E55xx Xeons, 72GB, R1 de discos SAS de 146GB 10krpm, Emulex 4Gbps FC HBA de duas portas vinculados a Cisco MDS9509s duplo e, em seguida, no HP EVA 8400 dedicado, com discos FC de 128 x 450GB 15krpm FC, RHEL 5.3-x64).

Usando o SFTP do cliente, estamos vendo apenas 40Kbps de taxa de transferência usando arquivos grandes (> 2GB). Realizamos testes de servidor para 'outro servidor local' e veremos cerca de 500 Mbps através dos comutadores locais (Cat 6509s); faremos o mesmo no lado do cliente, mas daqui a um dia ou mais.

Quais outros métodos de teste você usaria para provar aos provedores de link que o problema é deles?

networking performance sftp

— Chopper3
fonte

Eu também gostaria de saber uma resposta para esta. Nós começamos o nosso 100Mbit arrendado linha instalada na próxima semana em algum momento :)

— Tom O'Connor

como user37899 diz - os resultados seriam apreciados.

— PQD

Alguma atualização? Estou curioso para saber como isso acontece.

— Kyle Brandt

Eu bati muito mal nos provedores de links (ironicamente, eles fazem parte da mesma organização em que trabalho!) - eles ainda não voltaram para nós.

— usar o seguinte código

1

Ah bem, e, a propósito, se você pode descobrir por que eu recebo 7 votos para serverfault.com/questions/134467/... e 1 para isso, eu gostaria de saber ;-)

— Kyle Brandt

10

Ajustando um elefante:
Isso pode exigir ajuste, provavelmente não é o problema aqui, como diz o pQd. Esse tipo de link é conhecido como "Long, Fat Pipe" ou elefante (consulte a RFC 1072 ). Como se trata de um tubo de gigabit gordo que percorre uma certa distância (neste caso, a distância é realmente tempo / latência), a janela de recebimento tcp precisa ser grande (consulte o volume ilustrado de TCP / IP 1, seção de extensões TCP para fotos).

Para descobrir o que a janela de recebimento precisa ser, você calcula o produto de atraso da largura de banda:

Bandwidth * Delay = Product

Se houver latência de 10MS, esta calculadora estima que você deseja uma janela de recebimento de cerca de 1,2 MBytes. Podemos fazer o cálculo com a fórmula acima:

echo $(( (1000000.00/.01)/8  )) 
12500000

Portanto, convém executar um despejo de pacotes para verificar se o dimensionamento da janela TCP (a extensão TCP que permite janelas maiores) está acontecendo corretamente para ajustar isso quando você descobrir qual é o grande problema.

Limite da janela:
se esse for o problema, você tem o tamanho da janela vinculado sem escala, esperaria os seguintes resultados se nenhuma escala da janela estiver no lugar e houver latência de cerca de 200 ms, independentemente do tamanho do tubo:

Throughput = Recieve Window/Round Trip Time

Então:

echo $(( 65536/.2 ))
327680 #Bytes/second

Para obter os resultados que você está vendo, você só precisa resolver a latência, que seria:

RTT = RWIN/Throughput

Então (para 40 kBytes / s):

echo $(( 65536.0/40000.0 )) 
1.63 #Seconds of Latency

(Por favor, verifique meu Math, e estes obviamente não incluem todo o protocolo / cabeçalho)

— Kyle Brandt
fonte

Você sabe que me senti um pouco culpado por 'ultrapassar' temporariamente você no representante na outra semana, e o motivo é por causa de quão boas são suas respostas - e BOOM! você ainda usa um shell para fazer suas contas, não o Mac Calculator.app de 1,5 MB que eu faço! :) Obrigado.

— usar o seguinte código

1

Você também tem boas respostas e eu gosto de ter alguém próximo ao representante, aprimora um pouco o jogo :-) A consulta rápida do Google me lembra que você também respondeu às minhas perguntas: serverfault.com/questions/107263/ ... . Eu realmente aprecio os usuários ativos que tentam fazer essa comunidade 'acontecer'. Mas obrigado pelo complemento!

— Kyle Brandt

Eu também não gosto de nada além de saber que ajudamos alguém que sentiu que estava sozinho com um problema frustrante - além do queijo, é claro. Dito isto, eu também odeio quando recebemos perguntas mal formadas, você ouviu minha pergunta no podcast 82 do SO? também recebi uma camiseta grátis do SF!

— precisa saber é o seguinte

Eu escuto a maioria dos podcasts, mas perdi aquele, vou voltar e conferir (provavelmente neste fim de semana).

— Kyle Brandt

Desculpe por isso PQD, eu realmente sempre ler o seu nick como PDQ como em PDQ Bach: en.wikipedia.org/wiki/P._D._Q._Bach :-)

— Kyle Brandt

6

40kbps é muito baixo [até o ponto em que eu suspeitaria de incompatibilidade de conversores de mídia / duplex [mas você tem gigabit, portanto não há lugar para half duplex!] Etc]. deve haver perdas de pacotes ou instabilidade muito alta envolvida.

O iperf é a primeira ferramenta que me vem à cabeça para medir a taxa de transferência disponível. correr de um lado

iperf -s

e por outro:

iperf -t 60 -c 10.11.12.13

então você pode trocar as funções de cliente / servidor, usar -d para duplex etc. executar mtr entre as duas máquinas antes do início do teste e ver quais perdas de latência / pacote você tem no link não utilizado e como elas mudam durante a transferência de dados.

você gostaria de ver: jitter muito pequeno e nenhuma perda de pacote até que o link seja saturado em 90% da capacidade.

iperf para * nix e win , leia aqui e aqui sobre isso.

mtr para * nix e ganhe .

— pQd
fonte

Sabemos que o link é composto por 6 links 1000-base-zx, então é provável que a latência seja introduzida por toda essa repetição, mas mesmo assim estou surpreso que você seja o quão baixo é, uma ótima dica sobre o iperf pelo maneira, eu tinha esquecido totalmente que existia!

— Chopper3

poste seus resultados!

— The Janix Unix

1

O tracepath pode mostrar problemas de roteamento entre os dois sites.

iperf, ttcp e bwping podem fornecer informações úteis.

você sabe como esse link de 1 GB está sendo provisionado? você está fazendo uma ponte ou roteando sobre este link? Qual é o seu SLA para o link? você poderia ser moldado pelo seu provedor de links?

se você está recebendo apenas 40kbs, existe um problema sério. Tem certeza de que não é um link de 1 MB e sim um link de 1 GB / s. Você provavelmente descobrirá que a velocidade do link não é o que você pensa :-)

— O zelador do Unix
fonte

Obrigado pela sua resposta, é um link de fibra monomodo de ponte de vários segmentos dedicado, não há nenhuma forma envolvida, pois é apenas L2 o tempo todo - oh, e espero que não seja um link de 1 Mbps, nem com o dinheiro que está custando :)

— Chopper3

1

se você faz a ponte para a sua LAN, ou seja, não há roteamento em lugar algum, as transmissões de rede desperdiçarão a capacidade do link, o que é verdade para 1 GB, será uma pequena fração, mas um serviço de rede que se comporte mal pode achatar o link. Presumo que essas pontes estão fora de seu controle. Esses comutadores podem estar sobrecarregados ou incorrendo em latência muito alta. Alta latência significa baixa largura de banda.

— The Janix Unix

@ user37899 - alta latência não precisa significar baixa largura de banda, mas exige sintonia ... de qualquer maneira - quanta latência você pode percorrer a 200 milhas - se tudo estiver bem - não mais do que 3-10ms. A transmissão arp [ou outra] no link de gigabit é provavelmente uma fração muito pequena de toda a capacidade disponível.

— PQD

1

Se você tiver transmissões de rede em um nível que afete o desempenho do link, desconfio que você tenha tido problemas de desempenho interno muito antes da chegada dessa nova linha e teria notado isso.

— joeqwerty

@pQd Na verdade, eu estava falando sobre uma tempestade de transmissão.

— The Janix Unix

0

RFC 2544 ou Y.156sam

Estes são testes de rede que são feitos para provar o SLA pela operadora. IPERF e similares não são métodos de teste de rede verificáveis.

— Ansel Gaddy
fonte