Dimensione PHP em Ec2 para 30.000 usuários / servidor simultâneos

RockThePost.com é uma pilha LAMP hospedada em Ec2. Estamos nos preparando para aparecer em um e-mail que será enviado a cerca de 1 milhão de investidores … tudo ao mesmo tempo. Para nosso departamento de engenharia de 2 pessoas, isso significava que tínhamos que fazer uma verificação rápida de sanidade para ver quantas pessoas podemos apoiar simultaneamente.

Nosso aplicativo usa Zend Framework 2. do PHP. Nossos servidores web são duas máquinas m1.medium Ec2 com um ELB na frente deles configurado para dividir a carga. No back-end, estamos executando uma configuração de banco de dados MySQL mestre / escravo. Muito típico para a maioria dos pequenos data shops em que trabalhei.

Aqui estão minhas opiniões e pensamentos em ordem aleatória.

  • Use o recurso APC do PHP . Não entendo por que isso não está ativado por padrão, mas ter o APC ativado é realmente um requisito para que um site tenha a chance de ter um bom desempenho.

  • Coloque tudo o que não é uma solicitação .php em um CDN. Não há necessidade de sobrecarregar seu servidor de origem com solicitações de arquivos estáticos. Nosso implantador coloca tudo no S3 e nós encaminhamos tudo para o CloudFront. Isenção de responsabilidade: o CloudFront teve alguns problemas recentemente e recentemente definimos o site para servir todos os materiais estáticos diretamente do S3 até que os problemas do CloudFront sejam resolvidos.

  • Não faça conexões com outros servidores em seu código PHP , como o banco de dados e os servidores memcache, a menos que seja obrigatório e não haja realmente nenhuma outra maneira de fazer o que você está tentando fazer. Eu acho que a maioria dos aplicativos da web PHP por aí usa um banco de dados MySQL para o gerenciamento de sessão de back-end e um pool de memcache para cache. Fazer conexões com outros servidores durante o fluxo de execução não é eficiente. Ele bloqueia, ativa a CPU e tende a bloquear a linha, por assim dizer. Em vez disso, use o armazenamento de chave / valor APC para armazenar dados em PHP e Varnish para cache de página inteira.

  • Repito … Use Verniz . Provavelmente, a maioria das páginas do seu site não muda, ou quase nunca muda. Varnish é o Memcache / ModRewrite do armazenamento em cache do servidor da web. Colocar o Varnish no meu servidor da web fez a maior diferença no meu aplicativo da web durante o teste de carga.

  • Use um c1.xlarge . O m1.medium tem apenas 1 CPU para lidar com todas as solicitações. Descobri que atualizar para c1.xlarge, que tem 8 CPUs, realmente valeu a pena. Durante meu teste de carga, fiz um apt-get install nmon e, em seguida, executei o nmon e monitorei a CPU. Você pode literalmente assistir o servidor usar todos os 8 de seus núcleos para produzir páginas.

O Google Analytics nos mostra quantos segundos um usuário médio gasta em uma página média. Usando essas informações, executamos alguns testes de carga com o Siege e pudemos extrapolar que, com as recomendações acima, deveríamos ser capazes de lidar com 30.000 usuários simultaneamente por servidor web no “exterior” do site. Para páginas “interiores” que são movidas por PHP, esperamos ver algo mais ao longo das linhas de 1.000 sessões simultâneas por servidor. Antes da explosão de e-mail, vamos lançar um monte de c1.xlarges e, em seguida, eliminá-los lentamente conforme ficamos mais confortáveis ​​com a carga real que vemos no dia da explosão.

Finalmente, faremos mais trabalho para tornar nosso próprio código mais escalonável … no entanto, o código tem apenas cerca de 4 meses e esta é a primeira vez que fomos desafiados a realmente escaloná-lo.

Sobre RockThePost.com

Ajudamos os empreendedores a arrecadar dinheiro para um novo empreendimento. Se você está pensando em fazer um crowdfunding em seu próximo empreendimento, use o código de cupom “HACKERNEWS” para obter um desconto de 50% em qualquer um de nossos planos.