Como otimizei /dev/Kico com php, httpd e mysql

Hoje finalmente fiz um upgrade em /dev/Kico que melhorou significativamente sua performance (mais de 300%): conto aqui como obtive estes ganhos.

A aplicação que mantém este site é o WordPress, possívelmente um dos motores de blog mais populares da atualidade, o que não é para menos: é um software maravilhosamente bem escrito. Ele é feito em PHP e normalmente é executado no Apache HTTPD usando o banco de dados MySQL: é a famosa plataforma LAMP.

Primeiro passo: trocar a hospedagem

Desde 1999 tenho uma conta em um servidor compartilhado PHP aonde mantenho o site da itexto, este blog e diversos outros projetos em paralelo que são escritos em PHP. Apenas por curiosidade, a primeira versão do Grails Brasil era em phpBB. Não vou negar: gosto muito da plataforma LAMP: por mais que muitos imbecis torçam o nariz, é inegável que trata-se de algo que simplesmente funciona. :)

Ter uma conta em um servidor compartilhado não é problema para a maior parte dos usuários: é uma solução excelente. Prova disto é que tenho esta conta a nada mais nada menos que QUATORZE anos (e ei, este papo todo de PaaS nada mais é do que uma evolução disto). O problema é quando você quer ter maior controle sobre o seu ambiente de execução tal como no meu caso. Eu não tinha como tunar o MySQL, HTTPD, PHP, etc. Foi apenas por esta razão que rompi este relacionamento tão bem sucedido com a Hostnet (recomendo muito seus serviços).

A opção que mais chamou minha atenção foi o AWS, aonde o Grails Brasil já encontrava-se hospedado. Optei por uma micro instância que irá me custar aproximadamente US$ 17,00. Mantive assim um custo bem próximo (práticamente idêntico) ao que tinha no meu servidor anterior porém com a possibilidade de poder controlar todo o ambiente de execução.

Segundo passo: turbinando o PHP

Finalizada a instalação do HTTPD, PHP e MySQL observei que meus ganhos de performance eram mínimos. O carregamento da minha página inicial era de, em média, 500 a 600 ms, o que simplesmente não justificava ainda a migração de serviço de hospedagem. A solução foi simples: instalei um serviço chamado APC.

O APC é um cache de opcodes PHP. Quando um script PHP é executado, este primeiro é transformado em formato intermediário e logo em seguida executado. O que o APC faz é cachear este formato intermediário, o que aumenta significativamente a perforamnce do site. Após sua instalação o tempo de carregamento da página inicial pulou para algo em torno de 300 a 200 ms. Pronto: começou a ser justificada a migração de hospedagem.

Usei este tutorial para instalá-lo em minha distro Linux e funcionou de primeira o negócio.

Terceiro passo: otimização de imagens

O momento em que vi o quão desleixado estava com este blog :). Analisando o site com as ferramentas para webmasters do Google sempre um dos pontos de atenção eram as imagens carregadas pelo site. Sabe estas imagens que aparecem no cabeçalho? Pois é: cada uma tinha algo em torno de 200kb. Depois que as comprimi ganhei mais alguns milisegundos no carregamento do site para vocês.

Dica: verifique todas as imagens que inclui em seu blog, especialmente as que aparecem em todas as páginas, como fundos, cabeçalhos, rodapés, etc.

Quarto passo: habilitação da instrução expires no HTTPD

Um passo importante na otimização de um site é minimizar o número de requsições que o browser faz a este. Podemos obter este resultado enviando o cabeçalho Expires para o browser. Uma maneira bem prática de se fazer isto é modificando a configuração do servidor Apache para que faça isto de forma transparente para nós.

Este cabeçalho instrui o browser a cachear o resultado de uma requisição por um tempo determinado. Pense em imagens ou arquivos CSS por exemplo: se você vive acessando o mesmo site e estes arquivos não mudam com frequência, por que pedir sempre os mesmos arquivos?

(para saber mais a respeito, recomendo que leia este post)

É fácil: primeiro verifique se o módulo expires_module está ativado. Em seguida, inclua no seu arquivo httpd.conf dentro da tag <Directory> referente ao seu conteúdo instruções como as abaixo:

ExpiresActive On #ativa o modulo expires
 ExpiresByType image/gif "access plus 1 month"
 ExpiresByType image/jpeg "access plus 1 month"
 ExpiresByType text/css "access plus 1 month"
 ExpiresByTYpe image/png "access plus 1 month"

Repare: coloquei para cachear apenas o que é estático e não o conteúdo HTML que realmente muda com bastante frequência (especialmente na página inicial). O resultado foi excelente: se você é um visitante assíduo deste site, repare daqui pra frente como as coisas ficaram mais rápidas. ;)

Mais sobre o mod_expires neste link: http://httpd.apache.org/docs/2.2/mod/mod_expires.html

E o MySQL?

Este é um ponto que muitos irão achar controverso: dado que meu banco de dados é relativamente pequeno, optei por hospedá-lo na mesma instância em que o HTTPD. Com isto evito latência de rede e garanto uma performance melhor, bem melhor. Óbvio, há uma tarefa que de tempos em tempos faz o backup do banco e me envia por e-mail, o que me fornece alguma segurança em caso de “acidentes”.

Um ponto que pediu minha atenção foi a tabela usada pelo plugin Statpress para coletar estatísticas de acesso. O acesso a esta era sempre muito lento. Melhorei bastante a situação criando índices para as colunas os, spider, urlrequested, agent, browser, feed e date.

Ferramentas úteis para benchmark

Todo o processo de otimização foi feito usando duas ferramenas muito importantes. A primeira foi o analisador do Google presente nas ferramentas para webmasters.http://www.google.com/webmasters/

A segunda foi um plugin para o Chrome chamado YSlow que fornece uma série de métricas muito úteis na avaliação de desempenho do sistema.

E por mais incrível que pareça, o Bing também oferece ferramentas interessantes para webmasters. Vale muito à pena dar uma conferida: http://www.bing.com/webmaster

Conclusões

Este blog tem crescido em número de acessos considerávelmente nos últimos meses o que tornava a tarefa de escalar o site em um serviço de hospedagem compartilhada muito difícil. Foi um destes momentos em que me encontrava em uma encruzilhada: será que eu deveria abrir mão das facilidades oferecidas por um serviço tão como o da Hostnet? Será que realmente valeria à pena? Acredito que no meu caso sim, e muito.

Apenas para finalizar, o tempo médio de carregamento da página inicial do /dev/Kico era de 800 a 1200 ms. Hoje fica entre 200 e 300ms. 300% de ganho.

Sim: quando você sabe o que está fazendo, ter controle total sobre o seu ambiente de execução vale muito à pena.

PS: caso encontrem problemas no site nos próximos dias, por favor, entrem em contato comigo ok?