Aug 17 2008
Como agüentar uma capa do Yahoo! sem sustos
Com o advento do Yahoo!Posts muitos blogs passaram a experimentar picos de visitação até então inéditos para eles, alguns chegando ao extremo de em poucas horas ter mais visitação absoluta do que em toda a vida pregressa do blog. Pior ainda quando estes posts ficam em destaque na capa do portal.
Este efeito está pegando algumas pessoas de surpresa, e causando dissabores principalmente àqueles que hospedam seus sites em servidores partilhados, e é para evitar esse tipo de constrangimento que publicamos o presente texto, que embora seja direcionado aos VIPs da PortoFácil também poderá ser de utilidade para clientes de outras hospedagens. Da mesma forma, o foco principal aqui são blogs movidos pelo WordPress, mas o conceito é o mesmo.
Por que o servidor cai
Para entender por que ocorrem travamentos em momentos de pico, é necessário compreender uns poucos conceitos (ou pelo menos aceitá-los, caso seja muito difícil de compreender).
- cada requisição de página feita ao WordPress gera uma série de consultas ao banco de dados;
- quando um visitante requisita uma página, o fluxo do processo, simplificadamente por razões de didática, é o seguinte:
- o navegador do visitante abre uma conexão no servidor;
- o servidor carrega os scripts do WordPress para interpretar a página;
- o WordPress abre uma conexão com o banco de dados;
- o WordPress executa cada consulta ao banco, em ordem seqüencial;
- o WordPress monta a página a ser entregue ao navegador do visitante;
- o WordPress fecha a conexão com o banco de dados;
- o servidor entrega a página ao navegador do visitante, e encerra a conexão;
- o navegador interpreta a página recebida, e o processo se repete para cada arquivo, imagem, folha de estilos, etc, que esteja referenciado pela página;
- operações de banco de dados são as que mais requerem poder de processamento.
Como uma capa do Yahoo implica um grande número de requisições simultâneas, a carga de processamento num dado instante se multiplica, naturalmente, pela quantidade de visitantes fazendo requisições ao mesmo tempo.
Diminuindo o processamento
Da lista acima é fácil deduzir que, de maneira geral, há duas medidas que se podem tomar para diminuir o consumo de processador:
- diminuir a quantidade de recursos externos ligados a cada página, e
- o mais importante: diminuir ao máximo a utilização de banco de dados.
Sobre o primeiro item, cabe esclarecer que imagens hospedadas fora do servidor, como no Flickr ou no PhotoBucket, não implicam, naturalmente, sobrecarga de processamento. Mas imagens geradas dinamicamente, como as do tema Options para WordPress, são abomináveis, e certamente vão causar problemas, assim como folhas de estilo que são geradas dinamicamente por alguns temas mais cheios de frescura.
Assim, a primeira coisa a fazer para suportar uma capa do Yahoo! é ter um tema simples no seu blog. E por simples estamos falando de estrutura e características de programação, pois um site pode ter um visual “clean” e ainda assim consumir processamento em excesso. Da mesma forma, há plugins WordPress a serem evitados devido ao consumo de CPU que implicam.
Agora, o mais importante de tudo é reduzir ao mínimo as requisições de banco de dados, e isso se obtém simplesmente instalando um plugin de cache, conforme já falamos aqui antes: Faça o WordPress voar com o 1BlogCacher.
O que esse plugin faz é gerar uma cópia estática de cada página acessada, portanto que não requer nenhuma atividade de banco de dados, da primeira vez que um visitante a solicita. Todas as solicitações subseqüentes ao invés de demandarem todo aquele processo acima descrito, com todo aquele processamento, apenas requererão que o servidor entregue a versão estática, previamente processada, o que reduz a algo muito próximo de zero a necessidade de o WordPress realizar consultas no bancos de dados.
Se ainda assim houver problemas
Caso seu blog ainda tenha picos de utilização incompatíveis com um servidor partilhado, existe uma outra solução possível, embora não seja nada elegante (mas de que se você fizer tudo direitinho jamais vai precisar): fazer um redirecionamento temporário da página “sob ataque” para uma página estática hospedada em um servidor do Google.
A idéia é bem simples: faça uma versão de sua página no Blogspot ou no Google Pages, e no .htaccess da raiz do seu site insira o código abaixo:
Redirect 302 /link/do/post/ http://novosite.blogspot.com/nova-pagina.htm
Esta regra está dizendo que quando o post em questão for requisitado o nevagador do visitante deverá ir automaticamente para o novo endereço, desviando assim totalmente qualquer processamento do seu servidor para o do Google.
A razão de usar o 302 ao invés de 301 é que este redirecionamento é temporário, ou seja, assim que passar o surto de visitação você vai remover a regra do .htaccess, devolvendo o funcionamento do seu site ao normal.
Como a PortoFácil lida com sobrecargas em servidores partilhados
Nossa política com relação a uso de processamento dos servidores partilhados é bem simples: não interferimos em nenhuma conta que não esteja causando problemas às demais contas do mesmo servidor.
Caso identifiquemos alguma conta consumindo excessivos recursos de processamento, ela sera imediatamente suspensa, e um ticket será aberto para que o responsável pelo site entre em contato conosco para resolvermos o problema.
Os servidores da PortoFácil têm recursos de sobra e agüentam bem qualquer capa do Yahoo, contanto que as diretrizes acima sejam seguidas. Quem não as seguir, terá a conta suspensa até adequar-se às regras.
Textos relacionados a este:
Deste mal (acho) não sofro.
Mas será que não uma boa você tentar “adivinhar” quem pode ter problemas do gênero? Tipo, algo como a lista negra dos plugins, onde blogs que podem sofrer deste mal serem “intimados” a tomar providencias antes que ocorra.
[Reply]
Janio Sarmento reply on August 18th, 2008 23:15:
@MaxRaven: se você prestar atenção, todas as descobertas que faço a esse respeito vêm para o site da PortoFácil, que já é em forma de blog, ao invés de meramente uma base de conhecimento restrita aos clientes, para que mais gente possa se beneficiar da informação.
Sugiro que assine o feed, se ainda não o fez, e fique atento, pois pelo menos uma vez por semana eu abordo este tipo de assunto por aqui.
Nos artigos relacionados a este há algumas outras indicações de leitura que podem interessar, embora uma “lista negra” de plugins seja algo meio impossível de se manter, haja vista a quantidade de coisas novas que surgem, e o carater dinâmico da programação: um bom desenvolvedor ao perceber que sua criação tem falhas vai tratar de resolvê-las com o máximo de criatividade e competência possíveis, pelo que uma lista negra seria até desrespeitoso com aqueles que não abandonam seus produtos.
[Reply]
Quando digo:
“algo como a lista negra dos plugins”
Entenda-se como:
Plugins WordPress a serem evitados
Mas direcionados aos sites, e apenas para controle pessoal seu e do cliente, que, potencialmente, pode sofrer deste problema.
“Fulano usa plugins X, Y e Z, que podem ser problemáticos, então é bom trocar uma idéia antes com ele.”
É só uma sugestão, pq sei que muitos podem nem ter ideia que podem ser vitimas deste problema, pois, por mais que leiam, não vão entender muito bem o você disse.
Quanto assinar, bem, eu assino, ou melhor, assinava, mas meu leitor de feeds “morreu”, entrei aquela hora justamente para por no meu backup, o Greader.
[Reply]
Janio Sarmento reply on August 19th, 2008 01:26:
@MaxRaven: eu não consigo me ver fazendo um trabalho desses, mas poderíamos bolar um wiki, ou coisa parecida.
Se quiser detalhar melhor o que você imagina a esse respeito, podemos conversar; se quiser ser o mantenedor disto, podems nos acertar também.
Sabe como me achar.
[Reply]