Como crescer a partir da configuração de servidor único

Estou procurando recursos sobre como aumentar a configuração do servidor.

Atualmente, temos um servidor dedicado com a Rackspace no Reino Unido com as seguintes especificações:

HPDL385_G2_PrevGen
HP Opteron de núcleo único duplo 2214 (2,2 Ghz)
4 GB de RAM
2x 10.000 unidades SCSI em RAID 1

Nosso tráfego é de até 550.000 UVs por mês.

O site executa uma configuração de PHP e MySQL. O banco de dados é totalmente martelado, temos muitas consultas complexas juntando tabelas de vários tipos.

Estamos usando o APC para cache de PHP.

Estou chegando ao estágio em que fiz o máximo de otimização de banco de dados e consultas possível e me pergunto qual deve ser o próximo passo ......

Eu olhei para o memcache, mas tenho a impressão de que ele requer uma grande quantidade de RAM e, idealmente, uma caixa dedicada ....

Então é o próximo passo para ter duas caixas; um para o banco de dados, um para o Apache? Ou há um passo que eu negligenciei.

Nossa carga é geralmente em torno da marca 2, mas agora chega aos 20!

Alguns gráficos de Munin:

Compre algum hardware, mas coloque-o no laboratório de teste e não no data center. Em seguida, enfatize seu aplicativo em várias combinações de hardware / software até encontrar um razoável que faça o que você deseja.

É claro que você precisará criar algo que possa criar tráfego falso em um banco de dados semelhante à produção executando uma cópia de teste do seu aplicativo. Mas quem disse que seria fácil.

Se você não faz isso e simplesmente faz algumas coisas na produção, não tem ideia se vai funcionar ou não, e pode ter gastado MUITO esforço de engenharia implementando coisas como caches (que virão com sua parte justa) de bugs!) em algo que não ajuda.

Teste, teste e teste mais. Não jogue alterações de hardware / software em produção até obter bons dados de desempenho, mostrando que é provável que melhore significativamente os problemas. O esforço de engenharia é caro, o hardware de teste não é (particularmente).

Memcached é apenas uma opção, e você provavelmente não deve considerá-la até que o cache do banco de dados funcione de maneira ideal. Isso significa colocá-lo em uma caixa dedicada (64 bits, é claro) com uma quantidade razoável de RAM (e não 4G - os laptops têm isso hoje em dia; 32G é definitivamente acessível) e ajustá-lo adequadamente.

Você não mencionou o tamanho do seu banco de dados, mas, se for possível, você deve tentar obtê-lo inteiramente em memória ram (ou pelo menos nos bits quentes). Colocar seu banco de dados inteiramente em memória ram fará com que as operações de E / S de leitura desapareçam completamente e, portanto, deixem de ser um gargalo.

Perfile suas consultas ao banco de dados. Existem ferramentas para isso - você deve poder simular a carga de produção em seu ambiente de teste. O truque é evitar consultas lentas e garantir que as executadas com frequência sejam rápidas.

Se seus problemas de desempenho estiverem relacionados às sincronizações de E / S, porque você está realizando muitas transações para o banco de dados, verifique se está usando um controlador de invasão com bateria que está se comportando corretamente (fale com seu fornecedor sobre eles). Eles oferecem muito mais operações de gravação de E / S do que as que não são suportadas por bateria (porque os dados precisam apenas chegar ao cache antes que o sistema operacional obtenha a confirmação). Como alternativa, se seus dados não importam muito, considere relaxar os parâmetros de durabilidade do banco de dados (innodb sync on commit).

Ao analisar as soluções de cache, como muitas outras sugeriram aqui, você pode esperar acabar com cerca de 10% da carga que você tem hoje, talvez menos.

No entanto, isso depende do tipo de serviço que você executa na sua máquina. Você pode fazer muito com o memcached sem muita RAM.

Você deve tentar determinar quais consultas de banco de dados demoram mais, usando o log de consultas lentas do MySQL (ou o equivalente para seu banco de dados) ou usando uma ferramenta como mytop . Além disso, a EXPLAIN SELECTsintaxe do MySQL pode ser útil.

Armazenar em cache os resultados de algumas consultas selecionadas do MySQL (mesmo por apenas um curto período de tempo) pode realmente melhorar muito seu desempenho.

Faço muito desempenho e dimensiono o trabalho e o que descobri é que:

Cada carga de aplicativo é única

Respostas genéricas, como adicionar mais memória ram, obter outro servidor, fazer x, tentar x, geralmente são lições de frustração e deixam as configurações complicadas.

Meça as coisas certas

Um dos maiores desafios é determinar quais referências são importantes. Isso geralmente exige um passo para trás e você deve se colocar no lugar do seu cliente. Às vezes, o design simplista do site muda e significa enormes benefícios para o visitante da web. É por isso que eu gosto de ferramentas como o YSlow! que se concentram mais na experiência do usuário final do que no nível do servidor. Depois de decidir qual é a referência certa para o seu site, você poderá começar a ajustar. Os benchmarks podem ser o tempo total de carregamento da página, tamanho total da página, eficácia do cache, latência do site etc. Você precisa escolher aquele que faz sentido para o seu aplicativo.

Parafusos e porcas

Se você estiver acompanhando os benchmarks certos, comece em um nível muito baixo. Eu gosto de usar o sysstat. Você pode obter muitas informações do sysstat e ajudá-lo a separar qual sistema pode estar limitando o desempenho geral do aplicativo. Geralmente, eu integro problemas de desempenho em:

• pilha de rede
• pilha de memória
• disco io
• camada de aplicação
• camada do sistema operacional

Usando o sysstat e outras ferramentas, você pode começar a dividir os cabelos e encontrar o sistema que está limitando o desempenho.

Por exemplo, vi servidores altamente carregados falharem devido à forma como o aplicativo foi configurado. Armazenamento em cache inadequado, falta de cabeçalhos de validade no conteúdo estático, uso de HTTP x inclusões de arquivos etc. tudo isso contribuiu para o desempenho ruim do aplicativo. A correção desses problemas de aplicativo não exigia alterações de hardware. Em outros casos, eu vi os discos atingirem o máximo, apesar das toneladas de cache. Mover para discos mais rápidos corrigiu o problema.

Enxague e repita

Muitas vezes, durante o ajuste do aplicativo, você abre um gargalo para encontrar apenas outro. É por isso que recomendo tentar monitorar o que você está ajustando.

Por exemplo, digamos que você corrige um problema de E / S de disco, mas seu aplicativo ainda está lento. Você pode pensar que desperdiçou seus esforços, mas o que acontece é que você simplesmente encontra outro gargalo. Ao monitorar cuidadosamente o IO do disco, você pode ter certeza de que está melhorando o IO do disco, mesmo que os importantes monitores de desempenho de aplicativos não estejam mudando.

Obtenha as ferramentas certas

Verifique se você está usando as ferramentas certas para o trabalho. Todas as técnicas de monitoramento, teste, benchmarking, criação de perfil e outras otimizações têm uma variedade de ferramentas. Encontre a ferramenta que melhor corresponde à sua situação.

Regras de ouro

Embora todo aplicativo seja único, encontro alguns pontos de partida padrão:

• bancos de dados de memória amor memória
• disco io qualquer coisa, menos o ataque 10 pode prejudicar o desempenho do banco de dados
• otimizações erradas - grandes valores não se traduzem em grande desempenho
• application - culpando o servidor pelo design inadequado do aplicativo

Seus Próximos Passos

Se você não encontrar seu gargalo, adicionar um servidor pode não ajudar muito. Para resolver as E / S de disco, você pode precisar de outro servidor ou SAN. Se você tiver um gargalo de memória RAM, outro servidor resolverá o problema apenas na medida em que adiciona mais RAM. Movimentação bastante cara em comparação com apenas adicionar mais RAM ao servidor existente.

Conserto rápido

Over deploy. Eu tive que fazer isso quando parece que a pilha de aplicativos é o problema. Carregue basicamente na CPU, RAM e E / S de disco (RAID 10, 15K SCSI ou SSD). Amplie o hardware e comece a ajustar. Isso mantém você à tona até resolver os problemas.

Eu diria que o próximo passo deve ser o cache (cache de dados e / ou cache de páginas, dependendo da sua funcionalidade). Se o memcached parecer muito complexo, você poderá começar com soluções simples de cache de dados, como o PEAR Cache Lite, que requer apenas algumas linhas de código, mas que pode fazer uma enorme diferença. O cache da página (ou partes da página) é suportado pelo mecanismo de modelo do Smarty , por exemplo.

Depois que o cache não for mais necessário, você poderá aumentar a quantidade de servidores, pois não resta mais nada.

Se você tiver RAM livre suficiente, o memcached o ajudará mesmo na mesma caixa. Tente armazenar em cache várias consultas mais pesadas e ver o que acontecerá. Além disso, o Apache é muito pesado, use nginx ou lighttpd (com o aplicativo PHP trabalhando através do FastCGI, consulte php-fpm ).

Comece o cache, mas ignore o MySQL por enquanto. Seriouosly.

A regra deve ser - interromper uma solicitação o mais cedo possível. Portanto, um proxy reverso ou o cache adequado do nível do Apache obterá os melhores resultados, o cache do resultado no nível sql DENTRO do aplicativo e, em seguida, o cache no nível sql;)

Quanto mais cedo você interromper uma solicitação, menor será a sobrecarga. Nível do cache de saída - nem mesmo o PHP precisa ser executado, por assim dizer.