Dimensionando o aplicativo da web em vários serviços

Question

Estamos desenvolvendo nosso aplicativo da web e estamos trabalhando para reduzir nossos tempos de carregamento. Quando começamos a desenvolver o aplicativo, nos inscrevemos em um provedor de hospedagem conhecido que oferecia "soluções dedicadas" na nuvem. Como resultado, temos um servidor dedicado para nossa aplicação web e um servidor dedicado para nosso banco de dados. Ambos os servidores foram configurados com a mesma quantidade de RAM, a mesma CPU e unidades SSD. Mesmo com tempo de investimento & dinheiro em nossa infraestrutura, notamos tempos de carregamento de 8-10 segundos.

Fomos avisados por outra empresa de hospedagem que deveríamos reduzir a escala e colocar tudo em um servidor (em vez de dividi-lo). Eles mencionaram que ter os servidores separados levaria a tempos de carregamento mais altos devido à latência da rede e declarava que o PHP se comunicava mais rapidamente com o SQL via sockets do que pela rede. Isso eu sei ser verdade, mas não esperava os resultados que obtivemos. Imediatamente após mover tudo para nosso servidor de aplicativos original, nossos tempos de carregamento caíram para 3-4 segundos, de 8 a 10!

O problema é que agora estamos analisando um novo provedor de hospedagem e fomos aconselhados a utilizar um cluster com um balanceador de carga, servidor de banco de dados, servidor de aplicativos e dimensionamento a partir dele. A preocupação é que, se separarmos o aplicativo e o servidor de banco de dados novamente, estaremos de volta à estaca zero.

De tudo que eu li, parece que é quase sempre recomendado que esses servidores sejam divididos em vez de agrupados. Existe um aumento de desempenho que vem com isso quando é configurado corretamente, ou é apenas para escalabilidade a longo prazo?

Eu agradeço a ajuda!

    

Answer 1

Sua pergunta é muito ampla, por isso menciono apenas alguns aspectos:

• E / S de soquete local é mais rápido que o TCP, mas para a maioria dos aplicativos isso deve ser minúsculo comparado a todas as outras partes do seu tempo de retorno (balanceador de carga, processamento PHP, processamento de consulta de banco de dados, ...)

• sistemas divididos permitem um melhor armazenamento em cache, por ex. o servidor de banco de dados pode manter mais índices na RAM.

• possivelmente um ponto de escalabilidade: sistemas divididos são mais fáceis de configurar, por exemplo para implantar uma nova versão de software ou atualizar o PHP, basta adicionar um novo servidor de aplicativos, testá-lo e, finalmente, remover o antigo.

• para investigar seus problemas: verifique quantas conexões de banco de dados estão abertas para cada solicitação da web. Uma explicação para suas medições seria um aplicativo que usa muitas consultas SQL sem conexões persistentes, portanto, uma nova conexão TCP é aberta para cada acesso ao banco de dados.

Answer 2

Eu não sei o que você está fazendo para obter tempos de carregamento de 8-10 segundos (assumindo que você define "tempo de carregamento" como "tempo entre a solicitação HTTP chegar e a página é construída e enviada para o navegador").

Você não deve conseguir que suas CPUs usem 100% de uso com um servidor web e um banco de dados, e mesmo se você gerenciar isso de alguma forma, colocar o servidor web e o banco de dados em um servidor não ajudaria.

Além disso, qualquer tipo de sobrecarga no servidor de banco de dados não seria aliviada ao mover os dois servidores no mesmo hardware.

Então, o problema quase tem que ter algo a ver com

• muitas instruções SQL muito pequenas que são enviadas para o banco de dados individualmente, por isso mesmo a pequena latência em uma rede local é acumulada (imagine que você tenha 10000 instruções SQL por página e uma latência de rede de 0,1 ms). 10 segundos de tempo de carregamento).
• enormes blobs armazenados no banco de dados que precisam chegar ao servidor da web por meio da conexão sql, que normalmente é mais lenta que um protocolo projetado para transferência de arquivos, especialmente na rede
• a conexão de rede entre seus hosts é artificialmente limitada de alguma forma

Talvez seja algo que eu não possa imaginar no momento, porque é muito incomum que um aplicativo da Web típico fique mais lento quando você o distribui em mais CPUs, contanto que essas CPUs tenham uma conexão de rede rápida entre elas.

Contanto que você não descubra o que causa / causou o problema em hosts separados, você poderá ter o mesmo problema novamente, ou talvez não.

Eu tive o primeiro tipo de problema no ano passado - um cliente meu contratou um terceiro para desenvolver algum software para eles. Uma operação típica em um laptop de demonstração levou cerca de 4 horas para ser concluída. Quando meu cliente transferiu o software para o ambiente de produção pretendido (servidor de aplicativos BIG, cluster de banco de dados BIG), a mesma coisa levou um pouco mais de 16 horas. Vasculhando os logs e fazendo um rastreamento de rede, descobrimos que o aplicativo tinha feito cerca de 15.000 seleções por segundo no sistema dev e a latência de 0.3 ms entre o servidor de aplicativos e o banco de dados limitava isso a pouco mais de 3.000 seleções por segundo. Os desenvolvedores foram orientados a alterar a maneira como acessaram o banco de dados (fazer uma junção em 2 tabelas em vez de selecionar em uma, em seguida, uma única linha em cada um dos resultados), o que resultou em uma operação menor que 30 minutos.

O ponto é, o tipo de problema que você está tendo é incomum, pode ter a ver com o seu software se comportando de uma maneira incomum, e você realmente deve investigar o que está acontecendo aqui e por que o A configuração de 2 máquinas foi muito mais lenta.

A divisão em duas máquinas deve normalmente melhorar o desempenho, porque você tem mais CPUs para fazer o trabalho. Também aumenta a manutenção. Seu banco de dados pode precisar de um parâmetro de kernel especial ou nível de patch para funcionar bem; seu servidor da web pode ter requisitos conflitantes. E, sempre que você faz uma atualização, é muito mais fácil atualizar um dos dois sistemas sem tocar no outro.