Isso prova um gargalo de largura de banda da rede?

Question

Eu assumi incorretamente que meu teste AB interno significa que meu servidor pode lidar com 1k simultaneidade @ 3k acessos por segundo.

Minha teoria no momento é que a rede é o gargalo. O servidor não pode enviar dados suficientes com rapidez suficiente.

O teste externo do blitz.io com 1k de simultaneidade mostra meus hits / s em 180, com páginas demorando mais e mais para responder, pois o servidor só pode retornar 180 por segundo.

Euserviumarquivoembrancodonginxeoanotei:eleescala1:1comsimultaneidade.

Agora, para descartar afunilamentos de IO / memcached (o nginx normalmente puxa do memcached), eu sirvo uma versão estática da página em cache do sistema de arquivos.

Osresultadossãomuitosemelhantesaomeutesteoriginal;Estoucomcercade180RPS.

AdivisãodapáginaHTMLaomeiomedáodobrodoRPS,porissoédefinitivamentelimitadopelotamanhodapágina.

Se eu internamente o ApacheBench do servidor local, obtenho resultados consistentes de cerca de 4k RPS na página inteira e na meia página, com altas taxas de transferência. Taxa de transferência: 62586,14 [Kbytes / seg] recebidos

Se eu for AB de um servidor externo, recebo cerca de 180RPS - o mesmo que os resultados de blitz.io.

Como sei que não é o afogamento intencional?

Se eu fizer benchmarks de vários servidores externos, todos os resultados se tornarão insatisfatórios, o que me leva a acreditar que o problema está no tráfego de saída dos meus servidores, não um problema de velocidade de download com meus servidores de benchmarking / blitz.io.

Estou de volta à conclusão de que meu servidor não consegue enviar dados com rapidez suficiente.

Estou certo? Existem outras maneiras de interpretar esses dados? A solução / otimização é usada para configurar vários servidores + balanceamento de carga que podem ter 180 visitas por segundo?

Sou muito novo na otimização de servidores, por isso gostaria de receber qualquer confirmação para interpretar esses dados.

Tráfego de saída

Veja mais informações sobre a largura de banda de saída: O gráfico de rede mostra uma saída máxima de 16 Mb / s: 16 megabits por segundo. Não parece muito em tudo.

Devido a uma sugestão sobre afogamento, eu olhei para isso e descobri que o linode tem um limite de 50mbps (que eu nem estou perto de acertar, aparentemente). Eu tinha aumentado para 100mbps.

Como o linode limita meu tráfego, e eu nem o estou atingindo, isso significa que o meu servidor deve realmente ser capaz de gerar até 100mbps, mas é limitado por algum outro gargalo interno? Eu simplesmente não entendo como as redes desse tamanho funcionam; eles podem literalmente enviar dados tão rápido quanto podem ler do HDD? O pipe de rede é grande?

Em conclusão

1: Com base no acima, eu estou pensando que posso definitivamente aumentar o meu 180RPS, adicionando um balanceador de carga nginx em cima de uma configuração de servidor multi nginx em exatamente 180RPS por servidor atrás do LB.

2: Se o linode tiver um limite de 50 / 100mbit que não estou atingindo, deve haver algo que eu possa fazer para atingir esse limite com a configuração de um único servidor. Se eu puder ler / transmitir dados rápido o suficiente localmente, e o linode se incomodar em ter um limite de 50mbit / 100mbit, deve haver um gargalo interno que não me permita atingir os limites que não tenho certeza de como detectar. Correto?

Eu percebo que a pergunta é enorme e vaga agora, mas não tenho certeza de como condensá-la. Qualquer entrada é apreciada em qualquer conclusão que eu tenha feito.

    

Answer 1

A questão era eu assumir que os picos do gráfico linode.com eram verdadeiros picos. Acontece que o gráfico usa 5 pontos de dados médios de minuto, assim meu pico parecia ser 24mbits quando na verdade eu estava atingindo o limite de 50mbit.

Agora que eles aumentaram para 100 MB, meus benchmarks subiram imediatamente para o novo limite de tráfego de saída.

Se eu tivesse notado isso antes! Muito do meu raciocínio dependia da ideia de que eu não estava atingindo um limite de tráfego de saída devido a esse gráfico.

Agora, eu pico em 370 solicitações por segundo, que está abaixo de 100mbps, quando eu começo a receber um "backlog" de solicitações, e os tempos de resposta começam a subir.

Agora,possoaumentarasimultaneidademáximaencolhendoapágina.Comogzipativado,recebo600RPS.

Eu ainda tenho problemas quando de repente pico e o acúmulo de solicitações pendentes (limitado pela largura de banda) começam a se acumular, mas isso parece uma questão diferente.

Tem sido uma ótima lição na otimização / leitura desses dados / redução dos possíveis problemas. Muito obrigado pela sua contribuição!

    

Answer 2

Um pouco atrasado agora que você percebeu ... mas talvez deva considerar ler o blog do ServerFault de tempos em tempos.

Estou pensando em particular neste post , onde eles discutem por que ter um intervalo de pesquisa um segundo não o corta de tempos em tempos, relacionado a um problema muito parecido com o que você teve.

We discovered that we were discarding packets pretty frequently on 1 Gbit/s interfaces at rates of only 10-30 MBit/s which hurts our performance. This is because that 10-30 MBit/s rate is really the number of bits transfered per 5 minutes converted to a one second rate. When we dug in closer with Wireshark and used one millisecond IO graphing, we saw we would frequently burst the 1 Mbit per millisecond rate of the so called 1 Gbit/s interfaces.

Claro que me fez pensar. E eu sei que sei que estou eliminando essa das outras SAs na minha loja na primeira chance que eu tiver, e parecerão perversamente brilhante e perceptivo quando resolvermos esse problema.

Quem sabe, eu posso até deixar alguns deles no segredo. :)

    

Answer 3

Pode ser limitado pela rede, mas não necessariamente simplesmente uma questão de largura de banda. A latência da sua unidade de teste remoto terá um efeito no número de conexões pendentes a qualquer momento (espera de 50ms para confirmações é muito diferente de .5ms localmente), bem como na negociação e estabilização de tamanhos de janelas à medida que a conexão progride. Também é provável que você esteja exposto a uma certa quantidade de perda de pacotes - seja como uma função de congestionamento ou como o mecanismo de limitação de largura de banda por parte de sua operadora (ou daquelas de upstream).

Sugiro eliminar o máximo possível da equação para desenhar uma linha de base sensata. Medir a largura de banda de pico, latência e perda de pacotes do seu servidor para alguns pontos na Internet geral. Por mais improvável que possa parecer, tente procurar por "teste de tráfego Voip" ou similar. Vários provedores de serviços de VOIP têm aplicativos que podem medir esses tipos de padrões (bidirecionalmente) com um grau razoável de precisão. Depois de ter alguns dados empíricos válidos sobre a velocidade útil real do seu link, seus resultados podem ser validados.

Além dos testes de largura de banda, também pode ser útil observar uma captura de pacotes do tráfego da Web abaixo da média para procurar números excessivos de retransmissões, além de medir o tempo aparente que seu servidor está tomando para responder a solicitações (. Se este valor está aumentando substancialmente em função do número de conexões, isso é uma grande dica.