Latência de rede: 100Mbit vs. 1Gbit


11

Eu tenho um servidor web com uma conexão atual de 100Mbit e meu provedor oferece uma atualização para 1Gbit. Entendo que isso se refere à taxa de transferência, mas quanto maiores os pacotes, mais rapidamente eles podem ser transmitidos, portanto, esperaria uma ligeira diminuição no tempo de resposta (por exemplo, ping). Alguém já comparou isso?

Exemplo (servidor de 100mbit a 100mbit) com carga de 30 bytes:

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

Exemplo (servidor de 100mbit a 100mbit) com carga de 300 bytes (abaixo da MTU):

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

Então, de 30 a 300 a média. aumento da latência de 0,164 a 0,395 - eu esperaria que esse aumento fosse mais lento para uma conexão de 1gibt a 1gbit. Eu até esperaria que 100mbit a 1gbit fosse mais rápido, se a conexão fosse através de um switch que primeiro espere até receber todo o pacote.

Atualização: Por favor, leia os comentários das respostas com cuidado! A conexão não está saturada e eu não acho que esse aumento de velocidade seja importante para os humanos para uma solicitação, mas trata-se de muitas solicitações que se somam (Redis, Banco de Dados etc.).

Em relação à resposta de @LatinSuD :

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms

Também há codificação diferente (10b / 12b?) Com novas placas e cabos Ethernet de gbit, para que ele possa ter% 25 mais desempenho além de 10x (quando saturado) vs 100Mbit, talvez?
huseyin tugrul buyukisik

Respostas:


15

A única maneira de diminuir consideravelmente a latência é se o link atual de 100Mbit estiver saturado. Se não estiver saturado, você provavelmente não notará nenhuma alteração.

Além disso, sua suposição de que o link de 1 Gbit será capaz de suportar pacotes maiores está incorreta. O tamanho máximo do pacote é determinado pela MTU dos vários dispositivos ao longo do caminho que o pacote segue - começando pela NIC do servidor, até a MTU do computador do cliente. Em aplicativos de LAN internos (quando você tem controle sobre todos os dispositivos ao longo do caminho), às vezes é possível aumentar a MTU, mas nessa situação, você está praticamente preso à MTU padrão de 1500. Se você enviar pacotes maiores que isso acabará ficando fragmentado, diminuindo o desempenho.


2
"Apreciável" é a palavra-chave aqui. Acabei de verificar dois servidores com hardware idêntico e baixa carga de rede, mas com velocidades ethernet diferentes. O tempo médio de ping (local, com a fonte de ping na mesma sub-rede) caiu de 0,21 milissegundos para 0,17 milissegundos. Fazendo o ping dos mesmos servidores em casa, cada um tinha um tempo de 53 milissegundos. Há muitos fatores além do controle do seu provedor para fazer com que essa atualização valha a pena.
precisa

1
+1 Tecnicamente, há uma diferença, no entanto, é totalmente inaceitável, a menos que o aplicativo em particular seja incrivelmente sensível à latência.
Chris S

Obrigado pelo teste! De 0,21 a 0,17 é uma melhoria de 20%, o que é ótimo. Não estou preocupado com o ping em casa (50ms), mas o tempo que a solicitação permanece no provedor. Ajustamos ao máximo todo o processamento (CPU) e não IO da unidade (RAM / Cache / etc.), Então agora eu questiono quanto a velocidade da rede entre os servidores aumenta a latência total. Por exemplo, fazemos ~ 20 solicitações de redis para uma solicitação de servidor da web. @ MikeRenfro: você pode fazer o mesmo teste com um tamanho de carga maior? Ping normal é 30byte, avg. Redis em torno de 250. Eu esperaria que a diferença cresça.
Andreas Richter,

2
@Andreas; Eu acho que você perdeu totalmente o objetivo desses comentários. Isso é uma melhoria de 40 nanossegundos. Uma quantia que é completamente imperceptível para os seres humanos . E esse não é um número cumulativo, não é como se cada solicitação levasse 40 nanossegundos a mais; é apenas o primeiro a ser muito mais rápido, portanto o segundo será alinhado logo atrás, de qualquer maneira.
Chris S

1
@ Chris: a questão não era sobre a perceptibilidade - era uma pergunta se alguém já o testou e Mike o fez. Também não são 40 nanossegundos, são microssegundos , então você está perdendo o ponto pelo fator 1000 ... parabéns. Acredite, eu sei o que estou fazendo ... 20% seria suficiente para justificar os custos adicionais.
Andreas Richter

12

SIM gbit tem uma latência mais baixa, pois:

  • o mesmo número de bytes pode ser transferido em menor tempo

MAS a melhoria é apreciável se os pacotes tiverem um determinado tamanho:

  • Pacote de 56 bytes => praticamente nenhuma transferência mais rápida
  • Pacote de 1000 bytes = transferência> 20% mais rápida
  • Pacote (s) de 20000 bytes = transferência> 80% mais rápida

Portanto, se você tiver um aplicativo muito sensível à latência (4ms vs. 0,8ms, ida e volta para 20kb) e exigir a transferência de pacotes maiores, alternar entre 100mbit e gbit poderá reduzir a latência, mesmo que você use muito menos que os 100mbit / s em média (= o link não está saturado permanentemente).

Servidor (100mbit) -> Switch (gbit) -> Servidor (100mbit):

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

Servidor (gbit) -> Alternar (gbit) -> Servidor (gbit):

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= em média, em vários servidores, redução de 80% na latência para ping de 20kb

(Se apenas um dos links for gbit, você ainda terá uma redução de latência de 5% para ping de 20kb.)


1
Com a maioria dos equipamentos de rede sendo armazenados e encaminhados, um pacote deve ser totalmente recebido por um switch / roteador antes de ser transmitido. Conexões mais rápidas reduzem esse tempo, o que também reduz a latência (desde que a conexão não obtenha a velocidade de vários links paralelos).
19712 Brian

1
Devido à explicação, esta resposta é de longe a melhor da página. Os outros parecem querer explicar esse fato assumindo um caso especial - o desempenho da rede em uma longa distância / muitos switches. É importante considerar isso, especialmente considerando a preocupação do OP (servidor da web), mas essa resposta também mostra quanta diferença a velocidade da chave pode gerar em um único salto.
5133 Tyler

3

Eu acho que você tem um equívoco fundamental sobre a latência da banda e a "velocidade". A velocidade é uma função da largura de banda e latência. Por exemplo, considere uma remessa de dados em DVDs enviados para o país levando 3 dias para chegar. Compare isso com o envio de dados pela Internet. A internet possui uma conexão de latência muito menor, mas para corresponder à "velocidade" da conexão com a remessa, você teria que receber 9,6 MB por segundo ( exemplo de referência desta fonte ).

No seu caso, a atualização para uma largura de banda maior permitiria atender a usuários simultâneos, mas não melhoraria a latência para nenhum usuário individual.


Isso está incorreto - basta comparar o ping com a carga útil diferente que está abaixo da MTU atual: servidor de ping -i0.05 -c200 -s30 vs. servidor de ping -i0.05 -c200 -s300 ... Ou falando no seu exemplo: o um caminhão com DVDs de 1 milhão seria mais lento, porque é mais pesado que o caminhão com 1 DVD.
Andreas Richter,

2
O tempo de ping do @andreas não é a história toda - portanto, vamos argumentar que pacotes abaixo do MTU chegam mais rapidamente do que pacotes no MTU completo. a diferença é que você não possui todos os dados que o pacote 1 possui no mtu completo na mesma quantidade de tempo que os dois pacotes levam para chegar. A latência é o tempo necessário para a chegada de todos os dados. para voltar à analogia do caminhão, mesmo que seja necessário um caminhão com 1 Cd para chegar na metade do tempo em que o caminhão carrega 500 cds, ainda leva esse caminhão 500 viagens para entregar os dados (750 dias vs 3).
Jim B

@ JimB: sim, como mencionado, minha pergunta não era sobre tamanho de carga, mas sobre a velocidade: o caminhão cheio precisa de 10 horas para ser verificado pela alfândega, o pequeno, apenas 1 hora. 100mbit / s também significa que um pacote de 100 bits precisa de um mínimo teórico de 0,000954ms e um pacote de 1000 bits um mínimo teórico de 0,00954ms. Claro que processando o tempo / etc. na placa de rede / switch / etc. faça um pedaço maior de toda a latência, mas eu também esperaria que eles fossem mais rápidos em um switch de 1 gbit etc. Por favor, veja o comentário de @MikeRenfro, ele realmente testou e chegou a um aumento de 20%.
Andreas Richter

@andreas - 20% na mesma sub-rede que é irrlevant à sua pergunta
Jim B

1
@andreas 20% de um ping de milissegundos ainda é um ping de milissegundos. Mesmo 150% de um ping abaixo de milissegundo, como em seus testes, não será importante no mundo real. Você realmente tem um aplicativo em que importa se seus dados chegaram lá em 0,0003 segundos em vez de 0,0002 segundos ?
Shane Madden

2

Você está olhando o mundo através de um buraco de alfinete. Um teste válido de diferenças de latência em velocidades diferentes seria entre duas NICs idênticas conectadas com um cabo de conexão cruzada. Defina as velocidades de matemática das placas de rede de 10mb, 100mb e 1000mb. Isso mostrará que praticamente não há diferença de latência nas diferentes velocidades. Todos os pacotes viajam na mesma velocidade do fio, independentemente da largura de banda máxima usada. Depois de adicionar switches com armazenamento e encaminhamento, tudo muda. O teste de latência através de um switch deve ser feito com apenas duas conexões com o switch. Qualquer outro tráfego pode afetar a latência do seu teste. Mesmo assim, o comutador pode rolar os logs, ajustar os contadores de tipo de pacote, atualizar o relógio interno, etc. Tudo pode afetar a latência.

Sim, mudar de 100mb para 1gb pode ser mais rápido (menor latência) devido a alterações de hardware, NIC diferente, switch diferente, driver diferente. Vi mudanças maiores na latência do ping devido a diferenças de driver do que quaisquer outras alterações; largura de banda, comutadores, NICs de descarregamento, etc.

O comutador seria a próxima maior mudança com corte significativamente mais rápido que armazenar e encaminhar para testes de transmissão única. No entanto, uma chave de armazenamento e encaminhamento bem projetada pode ultrapassar a chave de corte no desempenho geral sob alta carga. Nos primeiros dias do gigabit, vi switches de backplane de 10mb de alto desempenho com latência menor do que os switches baratos de gigabit.

Os testes de ping são praticamente irrelevantes para a análise de desempenho ao usar a Internet. São testes rápidos para ter uma idéia aproximada do que está acontecendo no transporte no momento do teste. O teste de desempenho da produção é muito mais complicado do que apenas um ping. Switches de alto desempenho são computadores e sob alta carga se comportam de maneira diferente - altere a latência.

Ter uma NIC mais lenta, ou uma NIC configurada para uma velocidade mais lenta, poderia realmente ajudar um servidor com rajadas simultâneas, limitando a entrada para o servidor usando o cache dos switches. Uma única retransmissão pode negar qualquer diminuição na latência. Normalmente, os níveis de tráfego de média a alta carga são importantes, e não testes de ping únicos. por exemplo, o antigo e lento Sun Ultrasparc (latência mais alta para um único ping) supera a nova área de trabalho de gigabit barata usada como servidor de desenvolvimento quando menos de 70% da carga de largura de banda de 100mb. A área de trabalho possui NIC de gb mais rápida, conexão gb-gb mais rápida, memória mais rápida, mais memória, disco mais rápido e processador mais rápido, mas não apresenta um desempenho tão bom quanto o hardware / software ajustado da classe de servidor. Isso não quer dizer que um servidor sintonizado atual executando gb-gb não seja mais rápido que o hardware antigo, capaz de lidar com cargas de rendimento maiores. Há apenas mais complexidade na questão de "

Descubra se o seu provedor está usando comutadores diferentes para as conexões 100mb vs. 1gb. Se eles usassem o mesmo backplane do switch, eu pagaria pelo aumento apenas se os níveis de tráfego excederem a largura de banda mais baixa. Caso contrário, você poderá descobrir que, em pouco tempo, muitos outros usuários passarão para o gigabit e os poucos usuários restantes no comutador antigo agora terão um desempenho mais alto - menor latência, durante altas cargas no comutador (carga geral do comutador, não apenas nos servidores) )

Exemplo de maçãs e laranjas: O provedor de serviços de Internet local forneceu um novo switch para serviços agrupados, DSL e telefone. Inicialmente, os usuários viram um aumento no desempenho. O sistema foi vendido em excesso. Agora, os usuários que permanecem no comutador antigo têm desempenho consistente mais alto. Durante a madrugada, os usuários do novo sistema são mais rápidos. À noite, sob alta carga, os antigos clientes do switch superam claramente o novo sistema sobrecarregado.

Latência mais baixa nem sempre se correlaciona com entrega mais rápida. Você mencionou o MySQl nas 20 solicitações para servir uma única página. Esse tráfego não deve estar na mesma NIC que a página solicita. Mover todo o tráfego interno para uma rede interna reduzirá colisões e contagens totais de pacotes na NIC de saída e proporcionará ganhos maiores que o ganho de latência 0,04 ms de um único pacote. Reduza o número de solicitações por página para reduzir a latência de carregamento da página. Comprima as páginas, html, css, javascript, imagens para diminuir o tempo de carregamento da página. Essas três alterações fornecerão ganhos gerais maiores do que pagar pela largura de banda que não está sendo usada para obter uma redução de latência de 0,04 ms. O ping precisa ser executado 24 horas e ter uma média para ver a mudança real da latência. Agora, os comutadores inteligentes fazem a otimização do tipo RTSP adaptável, com pequenos aumentos de largura de banda inicial e grandes transferências otimizadas. Dependendo do tamanho da página (gráficos, html / css / javascript grande), você poderá ver as latências / largura de banda da conexão inicial muito mais baixas / mais altas que uma página grande ou transferências de página inteira. Se parte da sua página estiver transmitindo, você poderá ver um desempenho drasticamente diferente entre a página e o fluxo.


Obrigado por toda a excelente entrada: 1.) É a mesma opção, 2.) Uma segunda NIC para sons internos / externos é razoável e vale a pena tentar - mesmo que, por exemplo, MySQL / etc. são todas bidirecionais, portanto as colisões "apenas" seriam reduzidas à metade, 3.) Um teste do mundo real é preferível a apenas Nic-Nic, Mike o fez com uma sub-rede e conseguiu o que você esperava reg. hardware: "56 bytes = melhoria de 19%, 200 bytes = 27%, 1000 bytes = 59%! Portanto, quanto maior o pacote, mais importa. E o Gigabit aumentou apenas de 0,17 ms (56 bytes) para 0,23 ms (1000 bytes). ) => 35%, enquanto 100 Mbit aumentaram de 0,21 para 0,56 => 166% ".
Andreas Richter

1

Vamos assumir pacotes de 300 bytes (se você usá- -s 300lo, seria realmente maior por causa dos cabeçalhos).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0.024ms é aproximadamente o tempo real necessário para enviar o quadro (sem contar o tempo médio de acesso nem os cabeçalhos).

Em uma sequência de ping-pong, levaria o dobro do tempo (0,048 ms), mais o tempo para o sistema operacional processar a consulta.

Isso significa para mim que sua latência é causada por 90% de vários fatores de sobrecarga. Não tenho certeza se você verá muita diferença com o Gb. Uma diferença provavelmente inferior a 1 ms não será perceptível em um servidor da web.

Enfim, você poderia tentar com um pacote realmente grande como 1400 bytes?


Alguém já executou os números para um servidor específico e a diferença voltou em 40 nanossegundos. Sua estimativa de estimativa está desativada por um fator 25 vezes maior.
Chris S

@LatinSuD: obrigado pela abordagem construtiva e por não culpar o fato de eu não saber o que estou fazendo. Vou postar os resultados na pergunta real, pois posso fazer a formatação lá. Mas btw. Eu também esperaria que a sobrecarga de 90% aumentasse a velocidade , já que os processadores nas placas de rede etc. são mais rápidos para o GBit (espero). @ChrisS: micro-segundos e eu não entendo o que você quer dizer com a 25.
Andreas Richter

Minhas desculpas por misturar micro e nano; de qualquer forma, é imperceptível. O LatinSuD calculou uma diferença de 1 milissegundo inteiro, 25 vezes mais do que os 40 microssegundos encontrados por Mike.
Chris S

@ Chris: não se preocupe. O valor de 0,04ms era para um ping de 38 bytes, se nosso pacote servidor-servidor médio fosse de cerca de 300 bytes, a diferença poderia ser de 0,4ms. Se agora fizermos 20 solicitações para um servidor da web requerido (Redis, MySQL, etc.), isso levaria a um aumento de velocidade de 8ms, o que aumentaria em 10% a velocidade das solicitações atuais da Web e justificaria totalmente os custos adicionais. Simplesmente não tenho os recursos aqui para executar os testes, mas acredito que mesmo que não seja perceptível pelos seres humanos, ainda pode ser relevante. Como eletricidade ou deus.
Andreas Richter

1
@ Andreas, eu duvido que ele seja dimensionado assim; um pacote 10x maior é 10 vezes menos latente e 20x mais pacotes 20x mais rápidos. Se ocorrer, é uma redução de 10% na sobrecarga da rede, você ainda precisará contabilizar o tempo gasto no aplicativo, que provavelmente será de uma a várias ordens de magnitude mais longo que o componente de latência da rede. Espero que funcione bem para você em qualquer caso.
Chris S

1

Isso depende do tipo de switch ao qual você está se conectando. Em alguns fornecedores (como Crisco ... quero dizer Cisco), os pacotes ICMP retornam à CPU ( gag ).

Você pode achar que um teste melhor seria realizar um teste host-a-host usando um link de 100 Mbps e 1 Gbps (ou seja, não um teste de host para switch ou host para roteador).

No final do dia, a latência diminuirá para a taxa de encaminhamento no switch e para os detalhes da arquitetura do switch (onde os ASICs são colocados na placa, como o bloqueio é tratado entre as placas de linha, etc.). Boa sorte com seu teste.


Obrigado, refiro-me apenas aos testes Host-Switch-Host e não entendo todo o switch interno. Eu adoraria ver, se alguém alguma vez comparou: Host- (100mbit) -Switch- (100mbit) -Host, Host- (100mbit) -Switch- (1gbit) -Host and Host- (1gbit) -Switch- (1gbit ) - Latência de host para diferentes tamanhos de pacote. Se ninguém o fez, eu o farei e postarei a resposta aqui.
Andreas Richter

1
Eu costumava revender equipamentos de mudança. Basta dizer que suas descobertas sugerem que você está conectado a um switch Cisco. Existem outras alternativas que fornecem latências mais baixas. Como você apontou corretamente, mais largura de banda não se traduz em latências mais baixas (a Comcast é o principal culpado por tornar as pessoas burras nesse sentido). Como você está em um ambiente hospedado, provavelmente está preso ao hardware (e, como em um ambiente hospedado, os poucos microsecs extras não são terrivelmente cruciais). Mostre-me milhões de pps no estado estacionário e ficarei interessado em fornecer mais detalhes. :) #
21311 Sean
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.