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.
- MaxClients (Apache) = maxThreads (Jbossweb)
- Usar a biblioteca native da APR desenvolvida para o jbossweb
- Usar JBoss EAP (JBoss Enterprise Application), dependendo da natureza e criticidade da aplicação
- Utilizar a console JMX para obter informações de utilização de cpu e thread dump (kill -3)
- Setar timetou para a sessão http
- Dar um call invalidate quando terminar de mexer na sessão
- Tune logging
- Remover do jboss serviços que não serão utilizados
- Ter uma rede para as requisições de clientes http, outra para o AJP e outra para o tráfego sendo replicado
- 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.
Comments
Leave a comment Trackback