Como posso distribuir 1 aplicativo entre 2 servidores?

2

HI

Eu tenho um aplicativo Email Marketing Rails rodando em um servidor de memória RAM CentOS QuadCore de 16GB. Mas atualmente o nosso servidor web está demorando muito para responder a pedidos em horários de pico (Mongrel Cluster + Apache). Nós monitoramos usando o ScoutApp (www.scoutapp.com).

Alertas de escoteiros Tempo Máximo (3 seg) excedido em 668 solicitações Tempo Máximo (3 seg) excedido em 120 solicitações

contratei outro servidor Dual Xeon 4GB RAM.

Qual é a melhor configuração para distribuir este aplicativo entre dois servidores? Estou pensando em usar o SERVER-1 (16GB de RAM) com o MySQL e o Exim e migrar o aplicativo para o SERVER-2 (4GB de RAM) e usá-lo apenas como o WEB SERVER (Mongrel cluster + Apache).

Alguém pode me sugerir uma configuração, dicas ou ideias melhores?

    
por Newtonx 20.09.2010 / 16:48

3 respostas

3

... você deve restringir o escopo do tópico para "trilhos" em particular. (o assunto é um pouco enganador) Eu sugiro olhar para os logs & tentando identificar de onde o atraso está vindo.

Existem várias razões pelas quais um aplicativo Rails rodaria devagar ... e na maioria das vezes não tem nada a ver com o banco de dados ou com o próprio servidor web. Eu gostaria de ter certeza de que o cache não está desabilitado. (em cache de modo de desenvolvimento está desabilitado por padrão) Rails obtém um grande aumento de desempenho dos muitos algoritmos de cache que ele possui ... Além disso, vários bits de depuração que são ativados no desenvolvimento também consomem um pouco de desempenho.

Se tudo for feito, isso pode ser feito ... há várias etapas para avançar em direção a um "ambiente de trilhos agrupados". A depuração sugerida anteriormente também pode dizer o que você precisa ampliar. Se você está constantemente esperando no banco de dados para responder ... então, movendo o servidor de banco de dados para fora dessa caixa & em seu próprio ... ou agrupar o banco de dados sozinho pode ser tudo que você precisa. Se você achar que o servidor www é o que está ficando para trás ... aumente o tamanho do servidor web.

    
por 20.09.2010 / 17:11
1

A divisão da hospedagem web / http e da hospedagem de banco de dados em servidores separados é um bom primeiro passo. Um bom segundo passo é obter um servidor da Web duplicado e configurá-lo com o primeiro com algum tipo de balanceador de carga. Qualquer hardware que fica na frente de ambos os servidores ou um baseado em software.

edit: Isso pressupõe que você está certo de que o banco de dados não é seu fator limitante (o que pode muito bem ser). Mover o servidor da web para fora do servidor de banco de dados ajudará nessa situação, mas o segundo servidor da web que estou sugerindo só ajudará se o processamento de cada solicitação estiver atrasando você e não o banco de dados.

    
por 20.09.2010 / 17:05
-1

Não é o banco de dados que está chamando o problema. Quando as respostas começam a ficar lentas, eu verifiquei processos mysql e o mysql não tinha processos em espera. Eu acho que há muitos pedidos chegando ao servidor web (cluster apache + mestiço). Mesmo sites em execução no PHP não podem ser alcançados durante a hora do rush. Eu só tenho o ScoutApp monitorando meu servidor.

IO

E / S aguarde 11,9 ms Ler kBps 422,8 kB / s Lê / seg 61 Utilização 82% Escreva kBps 2,435.9 kB / s Escreve / seg 196

Monitoramento de aplicações de trilhos

Tempo médio de db 0,00 seg
Comprimento médio da solicitação 10,10 seg
Tempo médio de visualização de 9,81 seg
Pedidos 13.93 req / min
Solicitações Lentas 7.47 req / min
Pedidos lentos percentuais 54%

Apache Load

Solicitações por segundo 1,80 req / s
Acessos totais: 19169 - Tráfego total: 461.9 MB
Uso da CPU: u4 s.11 cu1.31 cs0 - .0648% da carga da CPU
2,29 solicitações por segundo - 56,5 kB / segundo - 24,7 kB / request
12 pedidos atualmente sendo processados, 9 trabalhadores ociosos -

Exim Queue (exim -bpc)

10475

    
por 20.09.2010 / 18:58