Dimensionando uma pilha LAMP

Question

Depois de ultrapassar os 100 mil acessos / mês, o que as pessoas desta comunidade dizem ser o maior obstáculo?

Minha situ: Toneladas de mídia estática (áudio / vídeo / imagens) sendo servidas fora do S3 / CDN, mas sendo armazenadas localmente como backup (não servidas). Tudo o que pode ser armazenado em cache é armazenado em cache, com cerca de 8 GB de memória escalável para 32.

Atualmente, estamos processando cerca de 100 mil acessos sem problemas e gostaríamos de saber quais problemas os outros enfrentaram: balanceamento de carga? problemas de memória? disco i / o?

Obrigado por qualquer dica. Analisei as perguntas relacionadas e elas foram bem respondidas, mas só queria receber mais feedback.

    

Answer 1

O hardware é tão barato hoje em dia que cada vez menos pessoas chegam ao ponto em que precisam de mais de uma máquina. US $ 10.000 comprarão você:

• 16 a 32 GB de RAM;
• 2 quad core Xeons;
• matriz de discos RAID5.

Esse tipo de máquina pode atender a mais de 10.000 usuários simultâneos em um site otimizado para aplicativos que exigem muitos recursos.

Basicamente, existem duas abordagens para a escalabilidade:

• Vertical: basicamente comprando a maior máquina possível para que você não precise de mais de uma;
• Horizontal: fazendo as coisas de uma forma que se presta ao paralelismo. Necessário apenas nas aplicações mais intensivas.

Veja o StackOverflow: ele basicamente é executado em um servidor Web mais um servidor de banco de dados e faz mais de 6 milhões de acessos por mês.

Dito isto, a escalabilidade consiste em encontrar e resolver o seu afunilamento.

• Se o seu banco de dados estiver atrasando as coisas, forneça mais recursos ou use alguma forma de armazenamento em cache na memória para remover a carga;
• Se a E / S do disco for problema seu, o mesmo se aplica;
• Se você estiver ficando sem memória a ponto de causar muitas falhas de página e causar um problema de E / S de disco, adicione mais memória;
• Seu aplicativo e seus dados se prestam a particionamento entre servidores? Se assim for, essa é uma maneira de dimensionar horizontalmente;
• Se a largura de banda é um problema e você está entregando arquivos grandes, talvez um CDN seja a resposta;
• E assim por diante.

Por fim, 100 mil acessos / mês não são tão grandes. Eu suspeito que nestes dias em um site típico você precisaria ir além de 10 milhões / mês antes de você ter problemas reais, assumindo que você não faz coisas mal (por exemplo, se você não indexar suas pesquisas de banco de dados, é claro que você vai ter problemas com isso, mas eles não têm nada a ver com hits / mês).

Eu diria que a redundância é uma dor de cabeça muito maior do que a escalabilidade. As questões envolvidas em ter links redundantes, monitorar processos para falhas do sistema, ter e manter um site de DR (recuperação de desastres), lidar com as questões que envolvem (como clustering de cérebro dividido), etc. são muito mais difíceis e tediosas.

    

Answer 2

Use Verniz ou Lula . Ambos são aceleradores da web e ambos são excelentes para arquivos de mídia estáticos.

Se você dimensionar, você pode até ter 1 máquina para cache da web e 1 máquina para o conteúdo dinâmico

Como alternativa, você pode tentar ajustar o apache usando os mods: mod_expires , mod_headers , mod_cache , mod_file_cache , mod_mem_cache .

    

Answer 3

Depende um pouco do tipo de banco de dados que você está lidando - se você está servindo conteúdo estático ou próximo de conteúdo estático; você vai escalar bem além de 100K / mês com hardware muito modesto.

Sites complexos baseados em banco de dados, como fóruns, podem ser um problema maior; você precisará examinar a replicação de banco de dados, reverter proxies no site principal para atuar como caches adicionais e servidores da Web com balanceamento de carga adicionais. A maioria dos softwares 'pesados' de uso de banco de dados também suporta coisas como o memcached, que pode ser usado para reduzir a carga no banco de dados em solicitações comuns.

Francamente, eu acho que você provavelmente está superestimando a demanda agora - 100K está dentro do domínio de lidar com uma única máquina muito bem. Depois de quebrar o 10M, você precisa procurar soluções mais complexas, como as que descrevi acima.

Meu conselho pessoal é sempre favorecer as máquinas paralelas sobre as mais complexas - não só elas acabam sendo mais baratas, mas dão muito mais espaço para você crescer quando chegar a hora. A expansão de hardware já dispendioso coloca você no mundo dos servidores de US $ 25.000 - onde o 'bang for buck' se desintegra.

    

Answer 4

Once you move beyond 100k hits/month

é NADA !!! Se você tiver problemas para atender 100k visitas por mês, você está com problemas. Geralmente, você não deve ter problemas com os sistemas mais idiotas que atendem a 100K por dia.

Trata-se de sistemas LAMP ... e CMS

My situ: Tons of static media (audio/video/images) being served off of S3/CDN

Existem servidores da Web muito bons para essas finalidades: lighttpd - ele serve mídia YouTuble streaming, o nginx também é bom.

Estes são servidores Web leves que escalam extremamente bem com cargas elevadas.

Até mesmo trocar o módulo do Apache de mod-prefork para mod-worker ajudaria (mesmo o lighttpd ainda é muito melhor).

Conclusão: essas cargas estão longe de serem altas.

    

Answer 5

Outros apontaram que os acessos de 100K não são um problema, embora eu suspeite que eles não entenderam que você já estava atendendo a muitos hits sem problema ...

Como seu conteúdo inclui vídeo, sugiro que a largura de banda da rede seja seu primeiro problema, seguida de solicitações de E / S, quando houver solicitações simultâneas suficientes para objetos grandes. Se você tiver mais RAM que os dados, a E / S será um problema menor, uma vez que tudo fica no cache (embora demore um pouco para preparar o cache após o desligamento do servidor).

Uma coisa que você deve especificar ao tentar dimensionar requisitos como esse é a distribuição dos seus hits. Eles são distribuídos uniformemente durante o mês ou mais em rajadas? Por exemplo, um site que hospeda informações sobre uma loteria nacional pode ver 80% ou mais de seu tráfego semanal em uma janela de duas horas após o tempo de empate - 80% de 100 mil solicitações em duas horas é de 2,7 por segundo (supondo um mês de quatro semanas) ainda não é massivo, mas chega lá dependendo do tamanho / complexidade ou das respostas. Outras explosões menos previsíveis também são possíveis, como o que acontece quando um vídeo no seu site atinge a primeira página do Digg ou semelhante.

    

Answer 6

Os maiores obstáculos são provavelmente

• Preparando seu aplicativo para uma arquitetura fracamente acoplada que reduz o ACID e outras restrições strongs para permitir operações assíncronas e inconsistências de curto prazo. Veja o Teorema do CAP de Brewer para uma visão geral ampla deste tópico.

• Lidar com o gerenciamento adequado de muitos nós. Isso inclui tarefas básicas de administração do sistema, como o gerenciamento de pacotes, além de testar e implantar solicitações de mudança. Quando você tem 50 servidores web, você não pode simplesmente "reiniciar todos os servidores apache"; algum pensamento tem que ser trazido para essas tarefas

• que me leva ao meu último ponto - entenda os efeitos que podem ser vistos em grandes sistemas. Rebanho Trovejante é uma das coisas que você vai ver. Este artigo na Audiogalaxy também descreve um poucos problemas de grandes sistemas.

Arquiteturas escalonáveis na Internet e A arte do planejamento de capacidade são dois livros sobre esse assunto que eu recomendo vivamente.

    

Answer 7

Sou um escalonador, tenho uma regra: sempre deixe a opção de se livrar de um problema de desempenho.

Qualquer coisa que não possa ser consertada por gastar dinheiro não tem 'tempo para resolver' fixo, então sempre tente codificar / confinar seu caminho para sair de um problema, mas sempre deixe a opção de jogar núcleos / ciclos / memória / armazenamento / largura de banda / qualquer que seja a questão - eles sempre podem ser FedEx'ed:)

    

Answer 8

Once you move beyond 100k hits/month, what would people in this community say is the biggest hurdle?

Pensando no problema, na engenharia da plataforma e na complexidade do sistema.

100k / mês é nada . Todo o seu objetivo nesse ponto deve estar gastando o mínimo de tempo possível humanamente com foco nele.