É 2-5 ms entre web e servidor de banco de dados apropriado? (Diferentes Datacenters)

Question

Atualmente, tenho um servidor web e de banco de dados dedicado em execução no datacenter (DC) 1. Estou prestes a expandir com outro servidor da Web no datacenter 2 que conversará com o db no DC 1.

A latência entre os dois datacenters é de cerca de 2-5 ms. Isso é apropriado para um site de tráfego intenso (mais de 400.000 visitantes por dia)?

    

Answer 1

Talvez (TM). Certamente não estará ajudando o seu desempenho, e eu ficaria desconfiado de ter minhas máquinas espalhadas assim dos possíveis modos de falha introduzidos, mas provavelmente não é o seu maior problema de desempenho.

Por outro lado, é incrível o que os provedores de hospedagem são capazes, se for pressionado, então eu diria ao seu provedor que a solução proposta é inaceitável para as suas necessidades e se eles não puderem provisionar outro servidor na mesma rede suas máquinas existentes, então você levará o seu negócio para outro lugar. As chances são de que eles milagrosamente encontrarão algum espaço por perto.

    

Answer 2

2-5ms não é muito ruim. Então, novamente, também depende de como seu aplicativo lida com chamadas de banco de dados.

Mais interessante, porém, pode ser a tolerância a falhas , você pode querer configurar uma solução idêntica no DC2, então você tem um servidor de banco de dados em ambos, assim você pode se recuperar rapidamente qualquer desastre em um datacenter. Um atraso de 2-5 ms seria muito apropriado para replicação de banco de dados, e se você usar mySQL, você pode até mesmo ser capaz de configurar a replicação multimaster e obter um melhor desempenho entre os servidores da web e o servidor de BD mais próximo

Embora não haja nada de errado em forçar seu provedor de serviços a comprometer-se com um nível aceitável de desempenho, você também precisa "encarar os fatos". Se os Datacenters estão separados por 300 km, os primeiros 2ms são simplesmente devido ao fato de que nem mesmo as linhas WAN de fibra ótica excedem a velocidade da luz (aproximadamente 300.000km / s). O tempo de ping é um tempo de ida e volta, portanto, 300 km significariam, na verdade, o tempo necessário para percorrer 600 km (300 km em cada sentido). Isso leva 2ms na velocidade da luz, e nenhum provedor de hospedagem pode adulterar uma constante física como a velocidade da luz

    

Answer 3

Não é realmente possível responder à sua pergunta. Você não forneceu nenhuma medida do impacto em seu site e também não definiu quais são suas metas de desempenho.

Mas um ponteiro importante: muitas estruturas de webapp usam uma estratégia de leituras de bloqueio , ou seja, enquanto a estrutura do webapp faz consultas SQL, o thread de solicitação da Web em perguntas é sinalizado como ocupado pelo sistema operacional. Assim, você pode ver o uso da CPU em seus servidores frontend aumentar significativamente devido à latência da consulta SQL adicionada.

Algumas estruturas de webapp, como a ASP.NET MVC, fornecem uma interface de E / S assíncrona , que poderia aliviar o problema acima. Mas a E / S assíncrona não é usada por padrão, e quase certamente seria muito caro reformular seu código de site para usar isso.

Por que não apenas migrar seus servidores antigos para o novo DC e configurar uma VLAN privada agradável para todos os seus servidores no novo DC?

    

Answer 4

Isso parece bastante importante para mim e, embora eu tenha bancos de dados em redes diferentes, eles sempre estiveram no mesmo local físico, por isso a latência não era um problema. Dependendo de quantas consultas por solicitação você está atendendo em média (e de quão pequeno cachê você está fazendo na camada Web / aplicativo), isso pode realmente começar a somar. Eu gostaria de testá-lo minuciosamente enquanto simulava a carga que é apropriada para seus padrões de uso.

Existe uma razão pela qual você está configurando um servidor da Web em um datacenter diferente? Se for para redundância, talvez seja mais apropriado configurar um esquema de replicação para outro banco de dados local no Data Center 2.