Estudo de caso: VPS passa incólume por um surto de tráfego

Conheça detalhes de um caso de surto de tráfego em um de nossos clientes, e saiba o que fizemos para que o blog aguentasse toda a visitação sem sustos.

No início desse mês fomos procurados pelo dono de um blog com características bastante peculiares. Dentre suas características especiais podemos destacar os surtos de tráfego, oriundos de ações no Twitter principalmente, que sempre levavam seu servidor anterior a cair.

Após uma análise detalhada do site (um blog em WordPress), decidimos que um VPS 2 com cPanel seria a configuração mais adequada, num balanço entre poder de processamento e a disponibilidade financeira do cliente. Pedimos ao cliente que seguisse algumas orientações, e ele as seguiu à risca, o que resultou no caso de sucesso que ora analisamos.

Na madrugada passada, entretanto, o blog passou por uma verdadeira prova de fogo: diversos “tuiteiros famosos” divulgaram um determinado post, e a visitação que era de 50 ou 60 usuários simultâneos chegou a um máximo registrado (pode ter sido maior) de 2.357 visitantes ao mesmo tempo.

Estudo de caso: VPS passa incólume por um surto de tráfego

Registro do momento de pico

Cabe dizer que a carga do servidor sequer aumentou consideravelmente. Na verdade, a carga não aumentou, o que aconteceu foi que o surto de tráfego aconteceu simultâneo ao processo de backup, que sempre exige um pouco mais da máquina, muitas operações de escrita e leitura de disco, o que acaba elevando a carga total.

Estudo de caso: VPS passa incólume por um surto de tráfego

Representação gráfica do pico de acessos

Em resumo, as otimizações feitas e que garantiram o pleno atendimento dessa demanda anormal foram:

  • WordPress com tema limpo (em termos de código) e sem plugins desnecessários
  • Plugin de cache configurado adequadamente
  • Nginx no servidor, na frente do Apache (padrão em todos os VPSs da PortoFácil)
  • Conteúdo estático servido exclusivamente pelo Nginx

Vamos agora detalhar um pouco melhor cada um dos itens de otimização utilizados nesse servidor.

Nginx no servidor

Explicar para leigos por que o Nginx atuando em conjunto com o Apache é uma excelente solução para acelerar um servidor certamente não é tarefa fácil. Já tentamos explicar isso antes (Apache Turbinado com Nginx), e por isso vamos dizer apenas: Nginx na frente do Apache, atuando como cache, faz uma monstruosa diferença, podendo aliviar em até 95% a carga de um webserver.

Todos os VPSs da PortoFácil saem já configurados com o Nginx na frente do Apache, para melhor aproveitamento dos recursos da máquina.

Template limpo no WordPress

Nunca será demais lembrar da necessidade de se manter um template “limpo” no WordPress. Mas aqui não falamos de “visualmente limpo”, e sim de um template limpo em termos de código. Há milhares de artigos Internet afora ensinando a manter um tema limpo para o WordPress, e nosso cliente fez essa parte da lição de casa.

Somente plugins essenciais

Sempre que um novo cliente chega à PortoFácil com problemas de processamento em seus blogs, somos enfáticos: a gente resolve seu problema se você abrir mão dos plugins que não são essenciais. Já tratamos diversas vezes desse assunto aqui (ver categoria WordPress de nosso blog), então não vamos chover no molhado.

Entretanto, é sempre bom relembrar que todos os plugins de estatísticas e contagem de coisas (comentários, posts, “estrelinhas”, etc) são problemáticos e devem ser evitados assim como Cascão evita um banho. Da mesma forma, plugins que “puxam” dados externos são extremamente prejudiciais. Basta imaginar, por exemplo, que se o site que fornece os dados externos cair, o site que usa os dados também cairá.

WP Super Cache em mod_rewrite

Nenhum WordPress será capaz de atender uma boa visitação com qualidade se não contar com um bom sistema de cache. Atualmente (e isso pode mudar com o tempo) o melhor plugin de cache para se usar num servidor com Nginx na frente do Apache é o WP Super Cache.

O Super Cache tem três modo de operação: legacy (legado — o pior de todos), php (que ajuda mas não resolve, pois continua sendo necessário instanciar no mínimo o interpretador PHP a cada página requisitada) e o mod_rewrite (que faz com que as páginas existentes no cache sejam servidas diretamente ao visitante, sem precisar do interpretador do PHP).

A escolha deverá ser sempre, invariavelmente, pelo mod_rewrite. Se algum plugin exigir que se usem PHP ou legacy, deve ser abandonado.

Além de já aliviar o servidor por não ser necessário instanciar o mecanismo de interpretação de scripts a cada página mesmo no cache, o mod_rewrite faculta ao Nginx um melhor funcionamento, bem como permite que se utilize a compressão gzip (no próprio plugin, bem entendido), que faz com que o conteúdo das páginas seja entregue muito mais rapidamente ao navegador do visitante.

Longa validade dos arquivos em cache

Todo plugin de cache precisa, em algum momento, limpar as páginas armazenadas para que seu conteúdo seja refrescado. O sistema de cache perfeito saberia identificar, após cada alteração feita no site, quais páginas exatamente careceriam de atualização, e as refrescaria.

Esse é o modo “que lindo seria” da questão.

Na prática é diferente: os caches têm uma configuração de validade das páginas, em termos de tempo (normalmente segundos), porque é impossível implementar o “que lindo seria”.

A configuração padrão do Super Cache sugere uma cache de 3.600s (1h), que até é suficiente para blogs de baixa visitação (até 500 visitantes por dia). Entretanto, à medida que o blog vai crescendo tanto em visitas quanto em números de posts e comentários, esse valor pode implicar sobrecarga no servidor, pois pelo menos a cada hora o cache será limpo, obrigando o sistema a reprocessar todas as páginas.

A tática utilizada no Manolagem foi configurar um longo período de validade do cache (99999999s ou até mais noves). Com isso, evitamos que uma atualização total do cache aconteça em um momento inesperado. Para garantir que o blog esteja sempre com páginas atualizadas no cache, a sugestão é que numa madrugada qualquer, quando a visitação estiver no seu limite inferior, seja feita uma limpeza manual.

Lockdown mode é seu amigo

Como dissemos acima, o Super Cache vai apagar uma página do cache apenas quando ela expirar. Isso é verdade, mas não é só isso: a expiração de uma página pode ser forçada quando o post correspondente sofrer alteração ou quando ele receber um comentário, mesmo que seja um comentário moderado.

Para esses casos, existe o modo lockdown, ou travado, do Super Cache.

Quando um blog está em modo lockdown nenhum comentário — moderado ou não — vai fazer com que a respectiva página expire. É essencial que o lockdown esteja ativo quando se espera um surto de visitação (um efeito Uêba, por exemplo).

Uma prática muito saudável, que é empregada no Manolagem, é:

  • manter os comentários 100% moderados (tem outros benefícios, como manter o blog faxinado de trolls e spammers);
  • manter o lockdown sempre ativo (nunca se sabe quando virá uma avalanche de visitas);
  • desativar o lockdown antes de moderar comentários e de postar, reativando-o imediatamente após terminar esse trabalho.

Subdomínio para conteúdo estático

A ideia de usar CDNs (Content Delivery Networks, redes para distribuição de conteúdo) tem sido um tanto supervalorizada recentemente, e para blogs menores o custo provavelmente não vai compensar. Entretanto, a essência da ideia é que conteúdo estático, imutável, possa ser servido por uma máquina “qualquer”, sem necessariamente ser a mesma máquina que roda o site.

É possível beneficiar-se da mesma ideia simplesmente redirecionando o tráfego do diretório de uploads do WordPress (por exemplo) para um subdomínio fora do WordPress. Já falamos sobre tratar erros 404 no WP para evitar que a cada arquivo não encontrado seja feita um instanciamento desnecessário do blog inteiro. Com a criação de um subdomínio fora do WP evitamos totalmente que erros 404 (ou qualquer outro) acabem sobrecarregando ainda mais o servidor.

No caso do Manolagem, fizemos algo um pouco mais avançado: criamos o subdomínio i.manolagem.com.br que funciona só no Nginx (o que for chamado dentro desse domínio jamais vai gerar uma requisição no Apache), e por isso mesmo potencializa a capacidade de aliviar o servidor, tirando mais proveito do cache.

Para forçar as imagens dos posts antigos que estão no formato original, basta uma única linha no .htaccess:

redirect 301 /wp-content/uploads http://i.manolagem.com.br

Sem dúvida, essa foi uma das medidas mais importantes para que o surto de tráfego, objeto deste estudo, não derrubasse o servidor.

Considerações finais

Antes que todos fiquem com a impressão errada de que é possível ter um blog de altíssima visitação em um servidor baratinho, cabe fazermos algumas considerações esclarecedoras.

Ao se dimensionar um servidor, é necessário analisar o tipo de tráfego que ele recebe na maior parte do tempo.

Quando um site sofre um efeito Uêba, ou quando há um “ataque” coordenado como o que deu origem à visitação do Manolagem na madrugada passada, ou mesmo quando é uma única página que aparece muito bem posicionada para o hype do momento, podemos dizer que 99% das requisições ocorrem numa única página. Esta página nunca deixa o cache do Nginx (assim como as imagens vinculadas a ela), podendo ser servida instantaneamente.

Blogs de alta visitação, que tenham as visitas distribuídas entre dezenas (ou centenas) de páginas, mesmo seguindo todas as orientações deste post, indiscutivelmente precisarão de hardware melhor para dar conta do processamento adicional.

Se o seu blog está precisando de melhorias em termos de velocidade e estabilidade, entre em contato: se não pudermos ajudar, dificilmente alguém poderá.

 

Quero ser cliente da PortoFácil!Contato

Compartilhe

Publicado por Janio Sarmento – 10 de Janeiro de 2011