GUJ agora no Jetty

Rafael Nunes wrote:

eduveks wrote:nada contra o Jetty, mas e o Glassfish? alguém já teve más experiências? tenho apostado no GlassFish até um dia levar na cabeça

Pra que um AS como o Glassfish se não há EJB, JMS, WebService, etc?

por exemplo não usa agora mas pode vir a usar, por isso se já tiver um servidor completo bombando fica mais fácil sei lá... é como ter um ferrari quando se precisa de um fusquinha

GlassFish V2 tem se mostrado muito rapido comigo...

Costumo usar ele mesmo sem ter EJB nos projetos... pois a administracao dele é facilitada e carga é modular... se vc nao usar JMS por exemplo... ele nao carrega o MessageQUEUE... e assim por diante...

A integração dele é tão facil quanto Tomcat nas IDE's e se vc usar o feijão com arroz ele tmb é de carga bem rapida

ricardolecheta wrote:Fabio, qual versão do jetty?

A mais nova: jetty-6.1.11. Pensei em usar o jetty7 beta, mas é arriscado d+.

reinaldob wrote:O Glasfish usa o Jetty, assim como o Jboss usa o tomcat.
Então, se o Jetty é rápido, boas chances do Glassfish ser tb.

Glassfish não usa o Jetty. Usa o Grizzly. Os nomes são parecidos mesmo!

Gente, agora a coisa toda deve estabilizar. Resolvemos o último problema que tinhamos, que era o consumo alto de cpu, por causa dos NIO connectors. O GUJ agora tem um proxy reverso na frente do(s) jetty(ies) que serve todo o conteúdo estático e possivelmente faz balanceamento de carga.

O servidor agora dificilmente passa de 10% de uso total do cpu e o jetty tem usado em média apenas 5% da memória do servidor (2Gb).

Para fazer o papel de proxy reverso, estamos usando o fantástico Nginx. É realmente impressionante. Recomendo que dêem uma olhada. É muito rápido e consome poquíssimos recursos do servidor. Senti que o GUJ está bem mais rápido agora com o nginx servindo o conteúdo estático.

Também fizemos uma tentativa de deixar vários jetties em balanceamento de carga de ontem para hoje. Funcionou bem, a não ser pelo fato de que o jforum do jeito que está configurado hoje não consegue compartilhar os caches que faz entre os vários nós (jetty) de um cluster. Com um pouquinho mais de código e configuração daria para balancear carga sem problema, mas com o número de requests/s e o uso dos recursos no servidor atuais, não estamos precisando mesmo de balanceamento de carga para o GUJ.

Agradeço denovo a compreensão de todos!

Muito bom Fabio, parabéns!

Fabio , será que o GlassFish não dá conta do recado ?

E outra... não tinha um papo que o tomcat tinha convertido alguns conectores para nativos do s.o ?

http://weblogs.java.net/blog/opinali/archive/2005/10/tomcat_goes_nat.html

Nada contra o Glassfish, mas não vejo nenhum motivo especial para usá-lo. Precisamos apenas de um servlet container, e a solução que chegamos está melhor do que o que precisariamos.

Quanto ao connector nativo do tomcat, já estávamos até usando. O problema era o consumo alto de memória que o tomcat estava tendo, levando a OutOfMemoryError depois de algum tempo.

Suspeitávamos de algum vazamento de memória no código do guj/jforum2, mas como não se manifestou denovo ainda com tudo rodando no jetty, começo a suspeitar do próprio tomcat, ou de alguma configuração errada que tivessemos.

O problema de memória parece estar solucionado. Mas se voltar a aparecer vamos ter que fazer um profiling mais profundo... (e eu quero fugir o máximo disso).

eduveks wrote:por exemplo não usa agora mas pode vir a usar, por isso se já tiver um servidor completo bombando fica mais fácil sei lá... é como ter um ferrari quando se precisa de um fusquinha

E se não "vier a usar"? Pra quê pagar o preço da ferrari?

Fabio Kung wrote:Gente, agora a coisa toda deve estabilizar. Resolvemos o último problema que tinhamos, que era o consumo alto de cpu, por causa dos NIO connectors. O GUJ agora tem um proxy reverso na frente do(s) jetty(ies) que serve todo o conteúdo estático e possivelmente faz balanceamento de carga.

Fábio, nesse caso os conteúdos estáticos estão relacionados ao Guj e não ao JForum, certo?

Naverdade, conteúdo estático toda aplicação tem, por exemplo figuras, e no caso do JForum isso não é diferente. Algumas empresas, como M$, Google, UOL, enfim, até usam servidores de imagens para centralizar esse conteúdo:
Ex:
http://img0.gmodules.com/ig/modules/youtube_videos_content/ytlogo_51x22.gif
http://img0.gmodules.com/ig/modules/mapsearch/mapsearch_content/spinner.gif
http://img.uol.com.br/logo_shopping.gif
http://img.uol.com.br/logo_link_157.gif

por ae vai....

Vcs dividem a aplicação do JForum entre conteúdo estático e conteúdo dinâmico? Fisicamente dizendo, as figuras do JForum estão fora da aplicação?

Fabio Kung wrote:
Para fazer o papel de proxy reverso, estamos usando o fantástico Nginx. É realmente impressionante. Recomendo que dêem uma olhada. É muito rápido e consome poquíssimos recursos do servidor. Senti que o GUJ está bem mais rápido agora com o nginx servindo o conteúdo estático.

O que vcs usavam antes? Httpd Apache?

Fabio Kung wrote:
Também fizemos uma tentativa de deixar vários jetties em balanceamento de carga de ontem para hoje. Funcionou bem, a não ser pelo fato de que o jforum do jeito que está configurado hoje não consegue compartilhar os caches que faz entre os vários nós (jetty) de um cluster. Com um pouquinho mais de código e configuração daria para balancear carga sem problema, mas com o número de requests/s e o uso dos recursos no servidor atuais, não estamos precisando mesmo de balanceamento de carga para o GUJ.

Acredito que vc deva manter o balanceamento, pois oferece redundância, facilidades na atualização, manutenção dos servidores, enfim.

Parabéns pelo trabalho!

[]'s
Luiz

Luiz Henrique Coura wrote:Fábio, nesse caso os conteúdos estáticos estão relacionados ao Guj e não ao JForum, certo?

Ao JFórum também.

Luiz Henrique Coura wrote:Vcs dividem a aplicação do JForum entre conteúdo estático e conteúdo dinâmico? Fisicamente dizendo, as figuras do JForum estão fora da aplicação?

Isso faria muito sentido sim Luiz, se tivéssemos carga suficiente para precisar de um cluster de verdade. O guj roda hoje em apenas uma máquina, não há porque servir o conteúdo estático de outro servidor.

Luiz Henrique Coura wrote:O que vcs usavam antes? Httpd Apache?

Antes não tinha nenhum proxy reverso. Apache httpd + mod_proxy ou mod_jk era sim uma opção, mas a muito tempo eu queria botar o nginx para funcionar de verdade. Essa foi a grande chance.

Luiz Henrique Coura wrote:Acredito que vc deva manter o balanceamento, pois oferece redundância, facilidades na atualização, manutenção dos servidores, enfim.

Denovo, concordo plenamente com você, se o GUJ precisasse de várias máquinas para atender o número de requisições que temos hoje. Não precisamos de balanceamento de carga hoje, por isso não vale o custo (tempo) para colocar isso no ar.

Obrigado pelos comentários!

Então esta explicado pq, mesmo com meu roteador engasgando as vezes, o GUJ ficou mais rápido.

Fábio, com relação aos servidores de imagens. O que vc acha? Vc acha interessante separar as imagens da aplicação?

Vamos supor que o Guj tivesse um servidor de imagens (images.guj.com.br) vc colocaria as imagens do JForum nesse servidor?

O JForum trabalha com internacionalização, onde existem várias imagens relacionadas aquele idioma, enfim. Resumidamente, caso eu queira adicionar um idioma novo, vou precisar criar as imagens e properties para aquele idioma. Então, no momento do deploy desse idioma vou precisar colocar as imagens em um servidor, nesse caso images.guj.com.br, e as propriedades em outro, vamos supor jforum.guj.com.br? Fica meio trabalhoso isso. É uma dificuldade a mais q vc cria, certo?

Acredito que esses servidores de imagens sejam ideais para armazenar imagens que devam ser acessadas por vários domínios. Suponha que eu tenha uma grande rede de supermercados e queira que todos os sites sigam o mesmo layout de imagens. Esse caso seria interessante criar um servidor de imagens.

Aqui na empresa trabalhamos com httpd+mod_proxy. Estou pensando em usar o mod_cache para trabalhar com as imagens da aplicação. Basicamente:

front-end: httpd+mod_proxy+mod_cache
middle-end: servlet-container
back-end: EJB
database: sgbd

Quero que as imagens existentes no middle-end (aquelas específicas daquela aplicação, como JForum) sejam armazenadas em cache no fron-end.

Ainda estamos acertando algumas coisas, mas acredito que o caminho seja esse. O que vc acha?

[]'s
Luiz

Luiz Henrique Coura wrote:Vamos supor que o Guj tivesse um servidor de imagens (images.guj.com.br) vc colocaria as imagens do JForum nesse servidor?

No caso do guj, mesmo se tivéssemos necessidade de mais servidores, eu acho que não separaria as imagens. Só faria isso se precisasse guardar as imagens em um servidor especial para isso: ou mais próximo (menor latência) dos usuários finais, ou então porque as imagens ficam guardadas em algum tipo de storage. A necessidade de separar as imagens em outro(s) servidor(es) costuma ser bem específica de cada caso. É rara a necessidade para os casos comuns.

Luiz Henrique Coura wrote:Acredito que esses servidores de imagens sejam ideais para armazenar imagens que devam ser acessadas por vários domínios. Suponha que eu tenha uma grande rede de supermercados e queira que todos os sites sigam o mesmo layout de imagens. Esse caso seria interessante criar um servidor de imagens.

Perfeito. Como você mesmo mostrou, uma necessidade específica.

Luiz Henrique Coura wrote:front-end: httpd+mod_proxy+mod_cache
middle-end: servlet-container
back-end: EJB
database: sgbd

Quero que as imagens existentes no middle-end (aquelas específicas daquela aplicação, como JForum) sejam armazenadas em cache no fron-end.

Ainda estamos acertando algumas coisas, mas acredito que o caminho seja esse. O que vc acha?

Não gosto de ficar dando muito pitaco nas arquiteturas dos outros. Vocês tem o próprio motivo para terem feito essa escolha. Mas como vc pediu a minha opinião, não acho que o mod_cache traria muita vantagem para as imagens, já que serve basicamente para cachear conteúdo dinâmico. Geralmente você salva o cache em disco mesmo, para não ter que renderizar (e processar) o conteúdo dinâmico toda vez. Ler o cache do disco, ou ler a imagem do disco daria na mesma; a não ser que você deixe o mod_cache guardar as coisas na memória, sacrificando memória no servidor. Realmente não sei se valeria a pena, já que um bom filesystem deveria eliminar essa necessidade de deixar as imagens na memória e o seu gargalo de performance com certeza não vai estar aí.

Você já tem o mod_proxy, então acredito que fazer o httpd servir as imagens, sem precisar chegar ao middle tier (servlet container) já é mais do que suficiente. Além disso, você pode customizar o mod_proxy para fazê-lo setar os headers da resposta HTTP e mandar os browsers manterem as imagens cacheadas por mais tempo.

ps.: a nova arquitetura tem resistido MUITO bem. Em breve posto algo no blog da Caelum explicando os resultados direitinho; o porquê do GUJ estar "voando" recentemente!

(ansioso pelo guj3)

E o Jetty rodando no Eclipse com WTP?

alguem ja conseguiu usar?

eu tentei uma vez o Jetty WTP adapter
http://yuna.ultimania.org/wiki/2006/11/05/23.56

mas nao consegui, entao o jeito era usar aquele jetty launcher mesmo... mas assim não da de utilizar algumas coisas bacanas que o WTP tem

Notícias, artigos e o maior fórum brasileiro sobre Java