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

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

Os testes externos do blitz.io com 1k de simultaneidade mostram meus hits / s atingindo o limite de 180, com páginas demorando mais e mais para responder, pois o servidor só pode retornar 180 por segundo.

Eu servi um arquivo em branco do nginx e o coloquei no banco: ele escala 1: 1 com simultaneidade.

Agora, para descartar gargalos de E / Memcached (o nginx normalmente é extraído do memcached), eu ofereço uma versão estática da página em cache do sistema de arquivos.

Os resultados são muito semelhantes ao meu teste original; Estou limitado a cerca de 180 RPS.

Dividir a página HTML ao meio me dá o dobro do RPS, por isso é definitivamente limitado pelo tamanho da página.

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

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

Como sei que não é uma limitação intencional?

Se eu fizer o benchmark de vários servidores externos, todos os resultados ficarão ruins, o que me levará a acreditar que o problema está no tráfego de saída de MEUS servidores, e não na velocidade de download dos meus servidores de benchmarking / blitz.io.

Então, estou de volta à minha conclusão de que meu servidor não pode enviar dados com rapidez suficiente.

Estou certo? Existem outras maneiras de interpretar esses dados? A solução / otimização para configurar vários servidores + balanceamento de carga cada um pode atender 180 ocorrências por segundo?

Eu sou um iniciante na otimização de servidores, por isso gostaria de receber qualquer confirmação para interpretar esses dados.

Tráfego de saída

Aqui estão 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.

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

Como o linode limita meu tráfego, e eu nem estou atingindo, isso significa que meu servidor deve ser capaz de produzir até 100mbps, mas é limitado por algum outro gargalo interno? Eu simplesmente não entendo como as redes dessa escala funcionam; eles podem literalmente enviar dados o mais rápido que podem ler do disco rígido? O canal de rede é tão grande?

Em conclusão

1: Com base no exposto, acho que posso aumentar definitivamente meus 180RPS adicionando um balanceador de carga nginx em cima de uma configuração de servidor multi nginx a 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 do meu servidor único. Se eu posso ler / transmitir dados rápido o suficiente localmente, e o linode ainda incomoda ter um limite de 50mbit / 100mbit, deve haver um gargalo interno que não está me permitindo atingir os limites que não tenho certeza de como detectar. Corrigir?

Sei que a pergunta é enorme e vaga agora, mas não sei como condensá-la. Qualquer contribuição é apreciada em qualquer conclusão que eu tenha feito.

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

Agora que eles aumentaram para 100mbits, 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 aponto para 370 solicitações por segundo, o que está abaixo de 100mbps, momento em que começo a receber um "backlog" de solicitações e os tempos de resposta começam a aumentar.

Agora posso aumentar a simultaneidade máxima diminuindo a página; com o gzip ativado, recebo 600RPS.

Ainda encontro problemas quando repentinamente repico e o acúmulo de solicitações pendentes (limitado pela largura de banda) começa a se acumular, mas isso soa como uma pergunta diferente.

Foi uma ótima lição de otimização / leitura desses dados / redução dos possíveis problemas. Muito obrigado pelo seu contributo!

Um pouco tarde agora que você descobriu ... mas talvez você deva considerar a leitura do blog ServerFault de tempos em tempos.

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

Descobrimos que estávamos descartando pacotes com bastante frequência em interfaces de 1 Gbit / s a ​​taxas de apenas 10 a 30 MBit / s, o que prejudica nosso desempenho. Isso ocorre porque essa taxa de 10 a 30 MBit / s é realmente o número de bits transferidos a cada 5 minutos convertidos em uma taxa de um segundo. Quando nos aproximamos do Wireshark e usamos um gráfico de milissegundos IO, vimos que frequentemente estourávamos a taxa de 1 Mbit por milissegundo das chamadas interfaces de 1 Gbit / s.

Claro que me fez pensar. E sei que sei que estou eliminando uma das outras SAs da minha loja na primeira chance que tiver e parecerá perversamente brilhante e perceptivo quando enfrentarmos esse problema.

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

Pode ser limitado pela rede, mas não necessariamente uma questão de largura de banda. A latência da sua unidade de teste remota afetará o número de conexões pendentes a qualquer momento (aguardar 50 ms por reconhecimentos é muito diferente de 0,5 ms localmente), bem como a negociação e estabilização dos tamanhos das janelas à medida que a conexão avança. Você provavelmente também está exposto a uma certa quantidade de perda de pacotes - em função de congestionamentos ou como mecanismo de limitação de largura de banda por parte de sua operadora (ou por aqueles que estão no upstream).

Sugiro eliminar o máximo possível da equação para desenhar uma linha de base sensata. Meça o pico de largura de banda, latência e perda de pacotes do servidor até alguns pontos na Internet em geral. Por mais improvável que pareça, tente pesquisar por "Teste de tráfego Voip" ou similar. Vários provedores de serviços VOIP possuem aplicativos que podem medir esses tipos de padrões (bidirecionalmente) com um grau razoável de precisão. Depois de ter dados empíricos válidos sobre a velocidade útil real do seu link, seus resultados poderão 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 sub-par para procurar um número excessivo de retransmissões, além de medir o tempo aparente que o servidor está demorando para responder às solicitações (..se isso valor está aumentando substancialmente em função do número de conexões, essa é uma grande pista).