Separando conteúdo dinâmico e estático no site de alto tráfego

Question

Estou tentando aumentar a capacidade do meu website, que está crescendo além do que o meu servidor da Web atual é capaz de gerenciar. O site hospeda em um servidor web dedicado (Litespeed), e um servidor de banco de dados dedicado. Ele recebe mais de 180.000 visitantes por dia e 100.000 downloads são feitos diariamente pelo site.

O site, que é baseado em PHP / MySQL, hospeda mais de 200GB de uploads / arquivos gerados por usuários compartilhados publicamente. Para cada upload, armazenamos o arquivo principal / download juntamente com uma visualização. Pode ser um pequeno arquivo MP3, um pequeno vídeo MP4 (convertido para um FLV para pré-visualização) e imagens (jpg) entre alguns outros formatos que geralmente têm uma miniatura e visualizações de imagem maiores. Também temos um fórum com 20 GB de anexos.

Todos os downloads dinâmicos / conteúdo estático são hospedados no servidor web e as cargas são ~ 20 ao longo do dia, sendo o gargalo a espera do disco e a CPU (dual 5410).

Meu host sugeriu espelhar o servidor Web com um balanceador de carga de hardware na frente deles, o que significa manter discos maiores e mais lentos - ou, alternativamente, executar um servidor Web para páginas dinâmicas com discos mais rápidos e mover todo o conteúdo estático, miniaturas / visualizações e faz o download para um servidor estático dedicado executando o nginx. Isso funcionaria bem para a exibição de visualizações de imagens, no entanto, todos os downloads são exibidos dinamicamente por meio de um script PHP no servidor da Web, assim também são os fluxos de visualização de arquivos Mp3 e flv. Não vejo como haveria algum benefício em fazer isso para download / streaming de conteúdo, pois presumo que o servidor da Web ainda estaria sob carga pesada e somente JS, CSS e imagens de visualização seriam exibidas diretamente do servidor estático. Eles também sugeriram a criação de uma nuvem privada; com um servidor da web virtual e balanceador de carga em cada servidor.

Alguém poderia explicar como melhor otimizar neste cenário e torná-lo flexível para ampliar no futuro, se necessário?

Outras informações: nossos arquivos MP3 não são arquivos grandes (350-400KB), os arquivos FLV têm até 10MB, mas alguns dos outros conteúdos, como arquivos rar / zip, podem chegar a 30MB e, em média, 10MB.

Obrigado

    

Answer 1

Desculpe dizer, mas eu gostaria de pegar um profiler se existir alguma para PHP / MySql e otimizar. Independentemente como eu cortar os números, este site é somethign que deve ser capaz de rodar em um processador Atom com núcleos feliz. 180.000 visitantes por dia não é muito para um site bem programado. Para a espera do disco - obtenha um controlador RAID ou ZFS adequado e coloque 1-2 SSD como cache. Além disso, receba hard iscs - fast many. Datbases não são algo que você coloca com desempenho em um servidor final normallow. Só para se ter uma idéia - eu tenho um servidor databas 800GB e eu estou usando 10 discos - 8x Velociraptor ion um Raid 10, 2 SSD no espelho para logs. As esperas de disco acontecerão com subsistemas mal projetados para qualquer banco de dados.

Então, novamente, se eu fosse você, eu faria:

• Comece a otimizar meu código PHP, coloque alguns aceleradores. Lembro-me de lidar com 400.000 visitantes em um site de namoro há um ano em um pentium duplo. Em uma hora durante um programa de TV. Com ASP - não compilado.

• Comece a criar um melhor subsistema de E / S.

Nota: o último pode exigir novo hardware. De qualquer forma. SuperMicro rege aqui, eles têm gabinetes de servidor com até 72 baias de unidade em 4 unidades de rack de altura. 24 discos em 2 unidades de rack, tudo em um backplane SAS. Eu uso um desses (20 discos agora no total) e realmente balança.

    

Answer 2

Você pode otimizar a exibição de conteúdo estático por meio de scripts usando o cabeçalho X-SENDFILE.

você provavelmente deve dividir seu conteúdo estático e banco de dados em diferentes discos / arrays e experimentar um pouco com a configuração da matriz de conteúdo estático. em alguns casos, o raid1 / raid10 pode ser melhor, em outros casos o raid5 pode funcionar melhor (especialmente se você não estiver escrevendo muito) e em alguns casos ter vários drives individuais (ou arrays raid1 se precisar de redundância) com arquivos definidos uniformemente em todos eles pode fazer o truque.

dependendo de quanta memória você tem à sua disposição, tendo todos os arquivos pequenos, ou alguns dos arquivos mais freqüentemente requisitados (você pode obter estatísticas dos logs do servidor web) no disco virtual, facilitando assim os discos. (embora isso realmente dependa do tráfego exato que você está vendo, já que o sistema operacional está tentando fazer isso para você com o cache, o que pode ou não funcionar bem)

e, é claro, dividindo o servidor em dois, cada um servindo metade dos arquivos pode ajudá-lo mesmo sem o balanceador de carga. (isso depende novamente do tráfego)

    

Answer 3

Antes de investir em hardware ou alterar sua arquitetura, sugiro tentar encontrar a causa subjacente dos problemas de desempenho.

Você mencionou o disco IO. O que está causando esse IO? Você tem certeza de que são downloads de arquivos, talvez registros ou outras atividades.

Eu normalmente começo catalogando o que está escrevendo / lendo do disco. Existem programas / funções específicos que tendem a causar mais problemas do que outros. Tente desativar determinadas tarefas, por exemplo envie logs do apache para / dev / null. Pare o email se também estiver sendo executado no servidor.

Este é apenas um exemplo de onde eu iria começar.

Muitos hosts são rápidos em impulsionar mais hardware - há certamente um motivo de negócios aqui, mas normalmente é o único recurso deles para lidar com problemas de desempenho. Eles normalmente não fornecem os serviços para otimizar o desempenho da Web, portanto, a resposta padrão se torna mais hardware.

Mais hardware é caro e tem retornos decrescentes.