Para o nosso jogo, hospedamos seus ativos estáticos em uma VM que acabou de instalar o httpd e rodar nela (é claro, junto com algumas coisas nativas do Linux), para servir conteúdo da web. O MPM configurado é trabalhador com MaxClients de 6400, ServerLimit 100 e ThreadsPerChild 64. A memória é de 4 GB. Com a configuração acima, o conteúdo estático veiculado tem um tamanho total de cerca de 20 MB e é veiculado no meu país (Bulgária), bem como em diversos outros países. Verifica-se e confirma-se que as velocidades de largura de banda nacionais e internacionais não diferem. No entanto, em momentos de pico, quando a largura de banda está esgotada, começamos a receber reclamações em massa de usuários distantes (ou seja, da Rússia) de que o jogo é baixado completamente por 2-3 minutos. Sempre que verificamos o carregamento do jogo com cache desabilitado a partir daqui, demorava cerca de 10 segundos, cada vez que tentamos, em qualquer computador. Adicionamos mais 2 VMs da imagem da VM original (mesma configuração e conteúdo) e fizemos o balanceamento de carga mais rápido - round robin de DNS para um total de três IPs. As reclamações diminuíram, mas o tempo de carregamento para usuários russos continuou sendo de mais de 1 minuto. Quando tentamos novamente baixar o jogo daqui várias vezes, ainda faltavam 10 segundos, sem diferença para nós. Quais podem ser as possíveis razões, dado que os servidores de conteúdo estático têm peering nacional e internacional iguais e, quando a carga é baixa, todos os usuários russos também podem fazer download por 10 segundos, mas não nos horários de pico? Não deveria ser igual para todos os usuários?
PS Em todos os momentos, os servidores estáticos tinham bastante memória e os processos httpd gerados nunca ultrapassavam 50, com limite definido de 100
EDIT: Breve resumo da questão - em carga baixa, todos os clientes (locais e distantes) baixam o cliente pelo mesmo tempo (por exemplo, 15 segundos). Quando a carga está alta, os clientes locais carregam-na novamente por 15 segundos, enquanto os clientes distantes fazem isso por 2 a 3 minutos. Quais são as possíveis razões?
Responder1
Conformeo esclarecimento de que isso só estava acontecendo quando a largura de banda estava esgotada, isso pode parecer um comportamento totalmente normal, então - quando você maximiza sua largura de banda disponível (para a taxa de linha), você pode começar a perder pacotes e terJanela TCPpara clientes de longo prazo que nunca foram ampliados para velocidades ideais;Produto de atraso de largura de bandaaumenta, o tempo para baixar o mesmo arquivo pelo mesmo canal aumenta; você teria que fazer alguma coisamodelagem de tráfego(em outras palavras,enfileiramento e priorização de pacotes) se quiser deixar tudo mais equilibrado para todos nos períodos de sobrecarga. – cnst 6 de outubro às 4:56
Responder2
A resposta depende de muitas coisas. Você não pode simplesmente dizer que suas velocidades internacionais são constantes. Usuários distantes sempre terão desempenho inferior, dependendo da rede entre você e eles e do peso da carga.
Aliás, você disse que sua largura de banda está esgotada. Largura de banda da conexão de rede do seu servidor? Então você realmente precisa de um CDN ou de proxies reversos de cache.
Posso oferecer algumas melhorias rápidas:
- Utilize o Nginx; ele pode servir conteúdo estático com muito mais eficiência.
- Use um CDN como o Cloudflare ou, se for muito elaborado, você pode alugar uma VM na Rússia e instalar um proxy reverso de cache nela, reconhecer o IP geográfico do seu DNS e fazer com que os usuários russos redirecionem para lá. Cloudflare pode realmente ser mais fácil :)
Responder3
Não se pode realmente dizer que o peering é o mesmo para o tráfego nacional e internacional.
Pode ter mudado nos últimos anos, mas tradicionalmente na Rússia, a maioria dos fornecedores nunca pagou por qualquer peering local, obtendo-o diretamente do MSK-IX, com o resto do tráfego a ser tratado por fornecedores de trânsito.
Os links em várias direções quase sempre têm capacidades variadas, e muitas vezes certos links ficam saturados de vez em quando (seja através de picos de tráfego inesperados, ou porque alguém tem preguiça de atualizar seus links, ou paga mais por mais tráfego, etc.) , e isso pode acontecer especialmente com mais frequência durante os horários de pico.
Muitas vezes, nos pontos de peering ou de trânsito, os provedores pagam uma taxa fixa por 100 Mbps, 1 Gbps ou 10 Gbps ilimitados. O que acontece quando o tráfego supera o valor pelo qual foi pago? Alguns pacotes são descartados, outros ficam mais lentos, e isso geralmente só acontece durante os horários de pico, e às vezes apenas em uma direção (mas mesmo que isso aconteça em uma direção, o tráfego ainda fica mais lento em ambas, já que a latência aumenta, e alguns ACKpacotes de controle de congestionamento também são perdidos).
Eu resolveria o problema executandomtrpara um dos hosts na Rússia que está enfrentando o problema, bem como de um dos hosts na Rússia para o seu servidor na Bulgária. Acho mais útil executar cada instância por 30 segundos a 15 minutos (mtr agregará as estatísticas durante toda a duração dessa execução) e, em seguida, executá-la novamente por mais 5 a 15 minutos imediatamente após a conclusão da execução anterior. Dessa forma, você poderá ver exatamente em que momento os problemas ocorrem.
Caso contrário, também pode ser um problema com o Apache, talvez relacionado a uma maior latência dos hosts na Rússia - o nginx é geralmente mais eficiente no fornecimento de todos os tipos de conteúdo do que o Apache, então talvez seja uma boa oportunidade para experimentar o nginx. ?
Responder4
Embora a velocidade da luz seja constante e os dados viajem através de cabos de fibra de longa distância na mesma velocidade, quanto mais longe a fonte estiver, mais "saltos" terão que passar.
Se você executar um traceroute para um servidor a 160 quilômetros de distância e, em seguida, comparar esse traceroute a um servidor que está no meio do globo, aquele que está no meio do globo provavelmente passará por muito mais saltos.
Latênciaé a quantidade de tempo que os dados levam para passar por cada roteador (salto) ao longo do caminho antes de chegarem ao seu destino, e a latência é o problema aqui.