Produção

Depois de muita expectativa, ontem finalmente começou o Apachecon. Assisti um tutorial intitulado Scalabe Internet Architeture, apresentado pelo Theo Schlossnagle que esteve e está envolvido em muitos projetos Open-source. A apresentação iria envolver os seguintes temas:

1. high availability and load balancing
2. caching static and dynamic content
3. distributed logging and troubleshooting.

Pois bem, vamos nós ao que de mais importante foi apresentado. Ele começou definindo o que era escalabilidade e performance. Até aí nada demais… Aliás, minto. Sobre performance foi apresentado um dado bastante interessante. É o seguinte: se o tempo de execução for melhorado em 50% num código que é executado apenas 2% do tempo, o ganho em performance é de apenas 1%!! Já se o tempo de execução for melhorado apenas 10% de um código que é executado 80% do tempo, o ganho em performance será de 8%. Resumindo, devemos analisar qual query, código, página, etc é chamado mais vezes e atuar em cima dele para melhorar a performance. Depois foi destacado a necessidade mundial de alta disponibilidade, ou seja, uma aplicação ou sistema deve está 99,999999% de pé ao longo do ano, o que a grosso modo corresponderia a apenas 5 minutos no ANO de downtime. Realmente é uma tarefa muito difícil, mas necessária para sistemas críticos. Foi aí que ele destacou a importância a necessidade de termos sempre “formal procedures” para tudo, de termos sempre tudo documentado. Cada vez mais os sistemas vão ficando mais complexos e se não houver uma documentação, um procedimento fica difícil de administrá-lo e atuar quando houver algum problema. Um fator importante que impacta na alta disponibilidade é a constante atualização no ambiente de produção de classes, configurações, pacotes e etc, pois cadê vez que isso ocorre, estamos inserindo a possibilidade de que um erro humano ocorra nestas situações. É mais uma variável que se soma. Infelizmente, não é a realidade da Globo.com ter ciclos de atualizações em produção bem definidos e/ou com uma periodicidade maior das que temos atualmente.

Em seguida foram apresentadas as arquiteturas pra termos um alto uptime dos diversos sistemas: parallel Servers, hot spare/stand by, warm spare/stand by, cold spare/stand by. Mais detalhes podem ser vistos no pdf da apresentação.

No tema de cacheamento de estático, foi apresentado de maneira geral como a akamai distribui seu conteúdo e como fazer para ter conteúdos estáticos espalhados ao longo do mundo e entregar para o cliente aquele que se está mais perto. Para isso foi usado duas frameworks: Spread e Wackamole.

O tema mais esperado para mim, era o de dynamic content. Bem, o que foi falado não era bem o que eu esperava ouvir… O que ele apresentou não era nenhuma novidade para quem já está familiarizado com o vignette, o que me surpreendeu foi a maneira simples que o palestrante apresentou de se fazer a única coisa de boa do vignette, o cache de html em disco. Primeiro ele usa uma regra no mod_rewrite para termos uma url mais amigável, sem query string. O exemplo está abaixo. Fazendo uma analogia ao Vignette, a sessão por exemplo, poderia ser reescrita para ser passada como parâmetro para um servlet. Se não estou enganado, no cma é possível montar uma página passando-se a sessão como parâmetro para um ServeltController.

Aí que vem a pegadinha. O php que foi chamado, no caso aqui article.php escreve a página inicialmente chamada no disco, ou seja, será gerado uma entrada em disco com o seguinte caminho: /news/items/12345.html. No próximo acesso, podemos usar um regra condicional do próprio mod_rewrite e verificar se a página está em disco, se tiver a página será entregue e a aplicação não irá ao banco de dados para gerá-la novamente. Um exemplo de como isso é feito é apresentado abaixo.

RewriteCond %{REQUEST_FILENAME} ^/news/items/([^/]*).html
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/news/items/([^/]*).html$ /www/docs/news/article.php?id=$1 [L]

Acho que o principal problema para essa abordagem é o acesso concorrente e o io em disco. O que aconteceria se duas pessoas chamassem a mesma página ao mesmo tempo? Bem, acho que talvez com o oscache consigamos resolver a questão da concorrência, no entanto, essa idéia precisa discutida com outras pessoas e ter a opinião de outras cabeças. O apache não teria que carregar todas metainformações de que o plugin do vignette precisa e nem demoraria tanto tempo para subir. Fica aí, uma proposta para ser pensada.

Por fim, foi apresentado uma alternativa interessante para se logar as informações do apache de uma maneira assíncrona e menos custosa para o web Server. Na verdade, a solução proposta, elimina a necessidade de ter um log em cada servidor. Imagine uma farm com 20 servidores e que se tenha que debugar um problema. Sair olhando no log de 20 maquinas log a log, para identificar em qual máquina se deu à anormalidade não é uma tarefa muito fácil, nem tão rápida de ser feita. Foi utilizado um módulo especial do apache para isso. Mais detalhes no pdf.

Bem é isso, os outros dias vão ser mais corridos não sei se vou ter tempo para escrever mais. Se nao der para fazer um resumo, tentarei colocar pelo menos um link do que foi exposto. O pdf da apresentação pode ser baixado no link abaixo.

http://gustavo.hprio.com.br/apachecon/Scalable200610.pdf

Opa, já ia me esquecendo… foi mencionado duas “tools” interessantes. Uma é um programinha para dar top em processo do apache

- apachetop

A segunda é o wwwstat que mostra estatisticas de requests feitos, bytes enviados e etc…

- wwwstat

That´s all folks!