Produção

Na oscon participei de duas palestras que falavam do uso de XMPP para criação de serviços web. O Etevaldo participou da primeira, e juntos organizamos este post.

As palestras foram “Open Source XMPP for Cloud Services” da Jive e “Beyond REST? Building data services with XMPP PubSub” do Flickr.

Ambas as apresentações estão online:
http://www.slideshare.net/mattjive/open-source-xmpp-for-cloud-services
http://www.slideshare.net/kellan/beyond-rest

Em ambas a indicação do uso de XMPP é para subistituir aplicações que façam HTTP Polling. HTTP Polling é o método que se baseia em requests periódicos a uma url para realizar o sincronismo entre duas aplicações, ou entre o cliente e o servidor. Segundo a apresentação do Flickr, isto seria equivalente a uma criança chata que fica perguntando ao pai de cinco em cinco minutos: “falta muito?” durante uma longa viagem de carro, e simplesmente não escala.

Nos casos em que o perído do polling é pequeno, ou seja, novos requests são gerados em poucos minutos ou segundos, é mais fácil enxegar a fonte de dados como um fluxo contínuo e ao invés de ficar abrindo e fechando conexões HTTP manter uma conexão persistente onde sejam trocadas mensagens. É assim que funciona o XMPP.

Bom ainda não estudei muito de XMPP, além de saber que é um protocolo aberto para “instant messaging” dei apenas uma lida no wikipedia . Acho que é o sufuciente por agora.

O problema encarado pelo Flickr era que o Friendster fazia HTTP Polling para sincronizar as fotos de seus usuários. Isso gerou uma grande volume de acesso no Flickr, que precisava de uma melhor alternativa. A solução do Flcikr foi criar um serviço via XMPP no padrão PubSub, ou seja, O Friendster abre uma conexão com o Flickr e a cada nova foto uma mensagem é enviada do Flickr para o Friendster.

Como se fazer um serviço web usando XMPP?
O que vc precisa fazer é criar um componente de acordo com o padrão XEP-0114 . Felizmente já existem APIs que implementam este protocolo em diferentes linguagens como a Whack API em Java e a gloox em C++ (deve existir para outras linguagens, mas não procurei).

Pelo que entendi do exemplo da Jive, vc vai criar um daemon que vai ficar rodando independente do servidor Jabber e que se conectará ao servidor Jabber, publicando algum tipo de serviço, como o que informa as condições do tempo.

Entre os servidores jabbers mais populares são o openfire (citado pela jive), o ejabberd, e o jabberd (citados no Flickr). Neste site tem um market share dos servidores jabbers, mas acho que não é mto confiável.

Acredito que em breve estaremos testando estes servidores jabber para entender melhor o funcionamento e saber como eles escalam aqui nas equipes de infra, pois provavelmente irão surgir aplicações que se utilizam deste protocolo.

Para o caso da Globo.com, precisamos pensar em como gerar clientes web para xmpp. Existe já uma API em javascript que faz a comunicação com Jabbers. Infelizemente, browsers não implementam o protocolo XMPP e este terá que ser encapsulado em HTTP. A técnica utilizada para isso é o BOSH (Bidirectional-streams Over Synchronous HTTP) da especificação XEP-0124 e com um post explicativo neste site.

Desta forma, as conexões persistentes teriam que ser feitas a um web-server que faria o papel de “proxy” com o servidor jabber???? Não necessariamente, o openfire e o ejabberd implementam bosh e saberiam lidar com “HTTP binding”.

Há também outras intefaces “não web”, por exemplo, que poderíamos utilizar, como a possibilidade de externar a funcionalidade de chat via XMPP, como está sendo feito pelo Facebook.

Antes que este post fique longo demais (já está), vou passar só mais uma referência que é este post interessante que discute pontos levantados na palestra do Flickr: http://redmonk.com/sogrady/2008/07/30/xmpp_rest/

Peço que sinalizem nos comentários caso exista interesse, para que eu possa tentar organizar um workshop para discutir idéias e implementações XMPPs.

Tive a oportunidade de participar, juntamente com o Etevaldo, da OSCON neste ano.

Minha idéia agora é organizar as anatoções, fazer posts específicos sobre dois temas e, em seguida, havendo interesse nos posts, organizar alguma apresentação com o pessoal para discutirmos o assunto.

O primeiro tema será sobre “cloud computing”, referenciando duas palestras que assisti, uma da rightscale e outra do nytimes. Ambas mto boas.

O segundo tema será sobre XMPP e como este protoloco está sendo utilizado em aplicações que necessitam de “streaming” de mensagens. Referenciarei as palestras do Flickr e da Jive que assisti.

Outros tutorias e palestras que mereceram destaque na minha opinião:

- Palestra sobre MySQL e memcache, que apesar de nada de muito novo, indicou que a criação de UDF´s do MySQL pode facilitar o uso do memcache. Esta é a forma como o Facebook faz e talvez valesse a pena entender melhor as vantagens.

- Palestra sobre o Dtrace, uma ferramenta muito interessante para debug de aplicação, mas que até o momnento não funciona em Linux, apenas Solaris. A previsão nada oficial é final deste ano.

- Palestra sobre a nova engine do MySQL, Maria, e seu relacionamento com o MyISAM.

- Palestra sobre o Puppet e seu funcionamento para gerencia de configuração

Minha idéia é fazer um só post sobre estas palestras, mas sem aprofundar muito.

Para pegar as apresentações é só acessar a página do evento. Contudo, nem todos os palestrantes colocaram as apresentações no site ainda, mas a do Flickr já está lá “Beyond REST? Building Data Services with XMPP PubSub”

Achei tbm dois posts do cara do Nytimes no seu blog que na verdade correspondem ao que apresentou:
http://open.blogs.nytimes.com/2007/11/01/self-service-prorated-super-computing-fun/
http://open.blogs.nytimes.com/2008/05/21/the-new-york-times-archives-amazon-web-services-timesmachine/
Volto ainda esta semana (espero) com posts mais interessantes.

Sem dúvida nenhuma o melhor Keynote no MySQL Conf, foi o keynote com os representantes de alguns big players da internet, que responderam a várias perguntas relacionadas aos seus ambientes com que diz respeito ao MySQL, entre eles Facebook e Youtube. Só não publiquei antes esse material, pois tive que garimpar essa info por ai até achar o blog do cara que estava digitando em real time todo o debate.

Segue abaixo o resumo dos números, que por sinal são MUITO interessantes:

Moderador do painel: Kaj Arno
Lista dos participantes ordenada pelo Alexa ranking:
1317. Monty Taylor (MySQL)
905. Matt Ingerenthron (Sun)
39. John Allspaw (Flickr)
13. Farhan Mashraqi (Fotolog)
9. Domas Mituzas (Wkipedia)
6. Jeff Rotheschild (Facebook)
2. Paul Tuckfield (YouTube)
p.s.: 3 entre os top 10 do Alexa.

Tabelão com as perguntas e respostas dos participantes:

	How many servers	Number of DBAs	How many web servers	Number of caching servers	Version of MySQL	Language, platform	Operating System
MySQL	1 M, 3 S	1/10	2	2	5.1.23	Perl,php and bash	Linux fedora
Sun	2 clustered, 2 individual	1.5	160+	8	5.0.21	Lots of stuff (java mostly)	Open Solaris
Flickr	166	At present 0	244	14	5.0.51	Php and some Java	Linux
Fotolog	140 databases on 37 instances	10 instances a DBA	70	40 ( 2 on each, 80 total)	4.11 and 4.4	Php, 90% Java	Solaris 10
Wikipedia	20	None, but everybody is kind of a DBA	70+200	40 ( 2 on each, 80 total)	Â	Php, c++, python	Fedora / Ubuntu
Facebook	30000 databases, 1800 db servers	2	1200	805	5.0.44 with relay log corruption patch	Php, python, c++ and erlang	Fedora / RHEL
Youtube	I can not say	3	I can not say	I can not say	5.0.24	Python	SuSE 9

Mais algumas perguntas extras interessantes:

Number of times re-architected ?

• MySQL: 2 - 1 time slave, 1 time memcached
• Sun: site depend (many times over the year)
• Flickr: Ummm…2.5 (various clusters federated)
• Fotolog: many cached replacements (about to do one change now)
• Wiped: Never (Spaghetti)
• Facebook: Every Tuesday, continual
• Youtube: Pretty continual, 2-3 times (replication, sharding, federation)

What happens if server fails ? what actions you will generally take ..

• Flickr: All of our 7 are federated, pairs of servers, we can loose any one side of shard, we can loose boxes.. traffic goes to either side of shard, now it goes to one, and we will get another one (very transparent to user) .. for offline, sites are affected
• Wikipedia: Users shout at them on IRC then they moderate fixed in seconds
• Facebook: one of 1800-1900 will always fail, just operate well, minor impact, with data going away for a while…we restore from binlog and start the server quickly, promote slave to master and number of ways
• Fotolog: we simply mount the snapshots to different servers and get
• Youtube: SAN etc, very important data.. recover the server, mirrored disk …mirrored hard drive is crucial

Any recommendation of scaling technology that you wanted to bring

• Fotolog: UltraSPARC-T1 (excellent master, multi threaded) and UltraSPARC-T2 for slave (single threaded)
• Wikipedia: good n/w switch
• Facebook: cheap switch, we dont use SAN, neatly partitioned, they scale independently and fail independently
• MySQL: cluster very sad

Server virtualization ?

• nobody uses at this time
• ETL cluster, we may run more than one in the future (facebook)

Anything to worry at present ?

• Facebook: app design is the key to use resources, data center power supply and consumption
• Fotolog: Google has to approve it for our power (cut app servers by 1/2 by moving from php to java)
• Youtube: not at all

Any reco, lessons to DBA

• better you know what the systems are, then you can
• performance, scaling taking it serious
• nothing more permanent than temp solutions (if u don’t know when u will fail, then u will )
• architect properly in start, schema, cost of serving data
• 10 mts biggest architectural change
• memory, resource

Essa foi a integra completa do painel, as respostas estão escritas como foram faladas pelos participantes.

Posso dizer que esse foi um belo resumo prático do que pudemos ver na conferência. Isso também nos dá uma visão muito mais real do uso do MySQL em outras empresas ao redor do mundo.

that’s all folks.

Apesar do JBossWorld ter acabado, vou falar de mais um assunto ligado ao que rolou por lá. Assisti uma session intitulada “Introduction to JBoss Application Server 5.0” apresentada pelo Dimitris Andreadis e achei valeria apena eu falar um pouco do que vi nela, sobre as novidades do JBoss 5.

O Dimitris começou a session contando um pouco sobre a história dos realeases do JBoss lá por volta de 2001/02 (começei a trabalhar com JBoss no ano de 2003). Atualmente o JBoss 5 está na versão beta 4 e segundo o apresentador eles não tem mais intenção de lançar mais muito beta, talvez mais um apenas e só. O objetivo da JBoss é lançar um application server certificado com o Java EE5. Vou listar algumas novidades/melhorias mencionadas na session, lembrando é claro, que todas as features do JBoss 5 não se resumem a que vou listar aqui.

Vamos lá…

1. Melhorias no mecanismo de clustering, que teve a sua arquitetura revista para melhor utilização dos recursos do servidor (memória por exemplo). O JBossClustering irá permitir definir a granularidade do que irá ser replicado e o que podemos chamar de BuddyReplication, que resumidamente consiste de que cada nó do cluster tenha um par com quem irá replicar os dados, evitando que uma informação seja replicado para todos os nós do cluster e consequentemente diminuindo o tráfego na rede. Aqui vale uma observação, acredio que essa feature possa ser utilizada no JBoss 4.0.x ou 4.2.x, bastando atualiazar o JGroups e o JbossCache.
2. Melhorias no serviço de mensagens (JBoss Messaging v. 1.4.1) que passará a usar a implementação do JMS 1.1, de performance melhor, permitindo cluster das filas (queues) e tópicos (topics) e redistribuições inteligentes de mensagens.
3. Failover transparente (essa eu quero ver funcionar mesmo! )
4. JBoss Web 2.1.0 como container web, que nada mais é do que um tomcat 6 turbinado, o pessoal da JBoss costumar dizer “Tomcat on stereoids“. Eles pegaram a api APR da apache e portaram para o tomcat, criando o JBoss Web com uma performance superior ao Tomcat.
5. Houveram mudanças na arquitetura de deploy.
6. API de configuração. Essa é a uma feature nova e segundo eu entendi ela irá facilitar a replicação de configurações do JBoss

Bem isso foi tudo que anotei e que me lembro da session.

Ahh! outra coisa que falaram é que eles não pretendem mais lançar mais nenhuma versão da família do JBoss 4.0.x (a versão 4.0.5 é a última) e que a família 4.2.x é uma versão intermediária entre as versões do JBoss 4.0.x e o JBoss 5 que está para ser lançado.

Esse link aqui também tem umas informações adicionais: http://www.theserverside.com/news/thread.tss?thread_id=43175

Hoje de manhã assisti um hands on alucinante sobre o JON, também conhecido como JBoss Operation Network. No hands on foi uma prática sobre os procedimetos básicos para a instalação e operação do JON. Recebemos um DVD com os arquivos a serem instalados durante o laboratório.

Já havia falado do JON, porém não sabia muito bem o que ele podia fazer e se ele realmente iria agregar algum valor na área de Produção. Vamos lá, com o JON podemos…

Inventário

Automatically discover

Cria grupos lógicos de JBoss instalados para facilitar a administração. Ex.: um grupo para o aplicativo A, outro grupo para o aplicativo B e por aí vai

Monitoração (Utilizacao de CPU, FileSystem, utilizacao da rede, metricas especificas para o Jboss AS, tomcat, hibernate, apache, postresql)

Operação (Start/stop/restart e etc)

Configuration (cria/atualiza servicos, i.e, datasources)

Deploy de application archives

Aplica patchs quando necessário

Fica claro na lista que o JON é uma ferramenta de monitoração e adminstração de Jboss, facilitando e muito a vida de quem precisa lida com o JBoss no dia a dia. Além disso, ele pode ser utilizado para relatórios, plano de capacidade/ocupação, uma vez que os dados coletados pelo JON são guardados num banco de dados (Oracle, Mysql ou Postgresql), havendo portanto um histórico. Basicamente o JON é composto de 2 componentes: o jon server que deve ser instalado em um servidor central qualquer e os agentes que ficam espalhados pelo parque de servidores que rodam JBoss. Como já mencionei antes, só é necessário um agente, mesmo que tivemos mais de uma instância de JBoss instalado. Outra feature interessante, é o que o JON permite a geração de alertas baseadas em thresholds pre-definidos, enviado a notificação por email.

Ele também pode exportar traps SNMP para serem coletados por algum outro serviço, o que em tese permitiria uma integração com o cacti apesar de no fim das contas termos 2 ferramentas para fazer a mesma coisa.

Vamos ao HandsOn!!!

Para instalar o JON precisamos instalar o JON (óbvio!!), o agente do JON, ter o jdk 5 (que eu felizmente já tinha no meu macbook) e um banco de dados. No laboratório acabamos usando o postgresql. O postgresql acabou fazendo com que que eu perdesse um pouco tempo, pois tive que instalá-lo (felizmente o macports me ajudou aí ) e configurá-lo. Tive que chamar um dos monitores para dar uma mão, pois eu nao tenho muita experiência com ele e tive que criar um usuário e database para o jon usar na munheca.

Os passos feitos estão na foto acima. Por fim, foi preciso carregar a liçenca fornecida, a qual é válida por 1 mês. Ahhh sim! O JON não é free, e apesar de ser pago, me parece que vale o investimento.

Instalando agente

Na versão 2.0, que ainda é beta, mas que será liberada ainda este ano, não é preciso passar o parâmetro de start. No fim, basta acessar o endereço no qual foi instalado para entrar no JON novamente. Infelizmente, fui nao pude avançar muito no laboratório pois havia perdido um certo tempo no início e quando eu ia começar a brincar com o JON instalado o tempo acabaou!

Minha opinião é que o JON é uma ferramenta que iria agregar muito valor na administração e operação dos Jboss, principalemente quando se fala de dezenas de instâncias rodando.

Assisti uma session intitulada “Using Jboss RedHat and Virtualization Technologies with SOA” apresentada pelo Issac Christiffersen e o Dan Santillo, ambos da Booz Allen. Esperava uma palestra mais técnica sobre virtualização, mas no entanto ela foi caracterizada mais por uma apresentação de conceitos e explicando razões do que por que optar pela virtualização. Uma coisa é certa, um dos principais motivos a favor da virtuazalição é limitação de espaço físico, cada vez mais evidente com a comoditização de hardware e o alto custo com energia para o sistema de refrigeração, afinal 60% da energia gasta em um DataCenter vai para esses dois caras. Além disso, a virtualização permite aproveitar melhor recursos do hardware. É comum vermos alguns servidores em DataCenters com a cpu 100% idle a maior parte do tempo. Esse mesmo servidor, poderia estar sendo melhor aproveitado para outros sistemas e aplicações. Um DataCenter com 100 servidores, poderia ter 20 ou 30 servidores, cada um com 3 máquinas virtuais. Imagine a economia de espaço e energia que isso iria trazer!?! Além é claro, de ser muito mais fácil para administrar 20 servidores do que 100. Quando se houve falar em virtualização, muitos pensam logo no vmware, talvez por muito estarem acostumados a instalá-los nas suas próprias máquinas para instalar um Windows no Linux ou vice-versa, no entanto, um outro player no mercado é o Xen, que além de ser open source, parece ser bem robusto.

…

Distingue-se do VMware por rodar mais próximo do hardware (por vezes, a máquina virtual pode compartilhar o mesmo kernel do sistema base). Ele permite que se rode vários sistemas operacionais em um mesmo hardware ao mesmo tempo. Fonte: Wikipedia

De SOA não vi nada na apresentação.

Cada vez mais, sente-se a necessidade de se implantar virtualização para valer na Globo.com, principalmente nos ambientes de QA’s que são os que estão mais sobrecarregados no momento com o excesso de aplicativos instalados ou instâncias de weblogic. Em produção, a virtualização iria diminuir o número de servidores físicos no DC, juntamente com o consumo de energia, o ganha uma preocupação maior ainda, se formos considerar alguns picos de energia que andamos tendo por lá…

Virtualização já!!!

Orlando, Florida. Hoje começou o JBossWorld. Agora estou no meio de um brake e aproveitei para escrever um pouco desse primeiro dia. Assisti 3 palestras hoje, 1 muito boa, outra boa e outra ruim.

A palestra muito boa foi a primeira que assisti foi apresentada pelo Bela Ban e era sobre JBoss Clustering. Para quem sabe o Bela Ban é o “pai” do jboss cache. Já havia assistido algumas palestras sobre cluster em outros eventos que participei, mas mesmo assim resolvi ir lá conferir. A palestra começou com o Bela Ban falando um pouco do conceito de jboss clustering para sessões http dentro do JBoss.

Algumas coisas que ele falou já são bastantes conhecidas para quem já configurou um tomcat em cluster, ou seja, colocar a cláusula <distributble/> dentro do web.xml. Ao contrário do que algumas pessoas pensam, não precisamos replicar todos os dados da sessão http a torto e a direita e sim apenas algumas partes da sessão, a partir do que chamamos de granularidade da sessão. No Jbossweb isto deve ser feito no arquivo jbossweb.xml. Outro ponto importante é que se temos um cluster com 8 nós por exemplo e um dos nós tem sua sessão alterada, o dado alterado será replicado para todos os nós do cluster. Isto é ruim, a medida que o cluster se torna maior, devido ao grande número de dados sendo gerados na rede. Como exemplo, tome uma sessão com 2,5kb. No cenário sugerido, teremos a geração de 25kb de tráfego a mais rede, num sistema que na maioria das vezes já está “under pression“. Para tenuar o volume de dados na rede, podemos configurar cada nó do cluster para replicar um dado apenas para um par, o que seria seu backup, no que chamamos de “buddy replication“. Voltando ao papo de granularidade da sessão, podemos configurar o cluster para replicar apenas um atributo da sessão e nao todos os dados da sessão. E ainda, podemos e devemos configura o cluster para replicar uma sessão apenas quando o método SET é invocado, indicando que algum atributo foi alterado. A segunda parte da palestra foi marcada pela apresentação de um benchmark que foi feito com diferentes tipos de configurações. Ficou evidente que o attribute replication foi mais perfomático em conjunto com o buddy replication. Uma observação deve ser feita, o buddy replication gera stress no sistema quando um dos nós cai, pois o cluster precisa ser reorganizado, quem vai replicar para quem, quais são os membros do cluster e etc… Na terceira parte da apresentação foi apresentado algumas dicas para melhorar a performance de um cluster jboss que irei procurar resumir aqui.

1. MaxClients (Apache) = maxThreads (Jbossweb)
2. Usar a biblioteca native da APR desenvolvida para o jbossweb
3. Usar JBoss EAP (JBoss Enterprise Application), dependendo da natureza e criticidade da aplicação
4. Utilizar a console JMX para obter informações de utilização de cpu e thread dump (kill -3)
5. Setar timetou para a sessão http
6. Dar um call invalidate quando terminar de mexer na sessão
7. Tune logging
8. Remover do jboss serviços que não serão utilizados
9. Ter uma rede para as requisições de clientes http, outra para o AJP e outra para o tráfego sendo replicado
10. Utilizar a feature de domains do mod_jk para criar sub clusters dentro de um cluster

Ufa! Isso foi tudo sobre a primeira palestra, desculpem por ter me estendido tanto.

 

A segunda palestra que assisti foi sobre EJB3. Não gostei da didática do palestrante e ficou tudo muito confuso. A terceira palestra achei muito boa, sobre um produto chamado JON, ou JBoss Operation Networks. Não sei quão estável está esta ferramenta, mas sei que seria muito útil num ambiente de produção, pois ela permite gerenciar instâncias de JBoss instaladas ao longo do parque de servidores de uma empresa, permitindo verificar versão do jboss (fazer um inventário), se a vm está de pé, atualizar a versão do software, entre outras coisas. Sexta-feira, dia 15/02/2008 , haverá um Hands-On sobre esta ferramenta. Basicamente, ela consiste de um agente que é instalado no servidor, responsável pela monitoração da vm do jboss e uma interface web onde são visualizados os dados gerados e/ou obtidos.

Vale ressaltar, que mesmo que tenhamos mais de um jboss instalado só é necessário um único agente rodando, e em tese, eu disse em tese :), ele iria detectar automaticamente qualquer novo jboss que fosse instalado.

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!