GUJ agora no Jetty

Legal Fábio!

Qual é a quantidade de memória que o Tomcat utilizava e que o Jetty utiliza?

cedo para dizer!

Deixa um pouco mais de tempo e eu te digo.

:arrow: :arrow:

Legal! Tomara que a experiência traga melhoras.

Também digo que senti uma melhora de velocidade, acredito que não seja só impressão não…

Pois existe um estudo que diz que melhora de performance visual só é sentida se for mais que 20%, então acredito que deva ter melhorado muito !

Opa legal fabião, GUJ sempre melhorando =)

Não seria esse o princípio da migração para o Ruby(conforme você disse no Falando em Java, que usavam o Jetty)? heheheheh

Legal, e depois que li isso também acho que está mais rápido… hauhauhuauha 8)

Muito legal escolherem o Jetty para substituir o Tomcat.

Acredito muito no potencial do Jetty mas nunca o utilizei em um ambiente do porte do GUJ.

Abraços.

Fabio, que tal se ao término de todo o processo de migração pro o guj 3, fosse feito um artigo mostrando as dificuldades, pontos fortes da nova estrutura, como ficou o funcionamento de tudo e tal, aquele resumão da arquitetura do guj?
acho que seria bacana

Boa Luiz!

Esse é o objetivo. Com certeza sai algo no blog da Caelum e/ou na MundoJava. Veremos…

Fabio, qual versão do jetty?

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

GlassFish vs Jetty… alguém sabe dizer qual seria a melhor escolha? Até para projetos simples mesmo…

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

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.

Estamos torcendo !

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

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

reinaldob:

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.

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).

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

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

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:

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:

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

Ao JFórum também.

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.

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.

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. :lol:

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

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.

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

Luiz Henrique Coura:

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?

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

não querendo ser chato, e nada contra o jetty.
mas eu acredito que o glassfish seja melhor para o GUJ, pelo fato de você poder clusterizar ele com diversos servidores, balanceamento de cargas, facil configuração, ejb, webservices, JMS, tera suporte a JavaEE6, blablabla e etc…

agora o jetty eu nunca usei, poderia dizer quais são as vantagens.

abraço.

No tópico sobre o eclipse 3.4 ganymede, me parece que tem um post sobre alguem usando o jetty no novo WTP.

Olá

Fábio, este tópico ficou muito bom e bastante esclarecedor. Vou colocar uma resposta só para poder receber emails sobre a discussão.

Gosto do Glassfish e justamente no momento estou trabalhando com o Grizzly.

Pelo que foi escrito nos posts anteriores, acho que isto aqui ficou completamente Off Topic.

[]s
Luca

leandrokjava wrote:agora o jetty eu nunca usei, poderia dizer quais são as vantagens.

graças a este tópico, resolvi apostar no jetty e andei fazendo uns testes de performance…

muito simples, me surpreendeu muito em relação ao glassfish…

e também ando vendo o Nginx…

Fabio, não dava para fazer um post ou nesta thread mesmo colocar um exemplo da configuração do Nginx com o Jetty, precisa suar o AJP?

e para as pools usou o bitronix?

meu querido.
acho que tu não me entendeste, conheço muitos outros containers, e do meu ponto de vista o glassfish seria uma opção legal, como muitos outros integrantes do Guj comentaram.

mas esqueça isso.

a minha real pergunta, é quais são as vantagens do jetty, sem comparam com o glassfish, esquece ele.

quero saber o que o jetty tem, ele é realmente igual ao tomcat? tem algo a mais? etc…

compreende?

eduveks:

graças a este tópico, resolvi apostar no jetty e andei fazendo uns testes de performance…

muito simples, me surpreendeu muito em relação ao glassfish… :P

Tem muita gente pedindo. O próximo post dessa “série” no blog da Caelum vai ser sobre load-balancing, daí eu posto alguns exemplos de configuração sim.

Não usei AJP. O proxy reverso encaminha as requisições via HTTP mesmo, como faria o mod_proxy no Apache Httpd.

Não usei. Estamos usando o C3P0 mesmo. Não tive oportunidade ainda de testar o bitronix, mas parece bem legal sim. Ainda mais se estivéssemos precisando de um TransactionManager (JTA).

Valeu pelas dicas!

Aqui tem bastante coisa sobre as vantagens do jetty, o que ele tem, etc: http://www.mortbay.org/jetty-6/

Ele também é um servlet container, assim como o Tomcat. Do meu ponto de vista, o que mais agrada no Jetty é o fato de ele ser facilmente embutível e de ser relativamente leve, se comparado a outros containers.

Foi um dos pioneiros a usar conectores NIO também, e isso fez o meu interesse despertar a um bom tempo. Hoje em dia isso não conta muito, já que todos os servlet containers possuem conectores NIO.

Mas eu não sou xiita, como ninguém deveria ser. Eu sempre digo que não existe melhor tecnologia. Meio massante repetir isso sempre, mas a melhor escolha sempre vai depender do contexto. Gosto do jetty, mas sei que não é para ser usado sempre.

A resposta curta é: o jetty não da memory leak com o GUJ

Aqui tem bastante coisa sobre as vantagens do jetty, o que ele tem, etc: http://www.mortbay.org/jetty-6/

Ele também é um servlet container, assim como o Tomcat. Do meu ponto de vista, o que mais agrada no Jetty é o fato de ele ser facilmente embutível e de ser relativamente leve, se comparado a outros containers.

Foi um dos pioneiros a usar conectores NIO também, e isso fez o meu interesse despertar a um bom tempo. Hoje em dia isso não conta muito, já que todos os servlet containers possuem conectores NIO.

Mas eu não sou xiita, como ninguém deveria ser. Eu sempre digo que não existe melhor tecnologia. Meio massante repetir isso sempre, mas a melhor escolha sempre vai depender do contexto. Gosto do jetty, mas sei que não é para ser usado sempre.

hum…
Ele tem facil integranção com JOnAS , Geronimo , JBoss.

legal, gostei mesmo.

gostei disso.

muito obrigado pelo esclarecimento fabio.

abraço.

Fabio Kung:

eduveks:

e para as pools usou o bitronix?

Não usei. Estamos usando o C3P0 mesmo. Não tive oportunidade ainda de testar o bitronix, mas parece bem legal sim. Ainda mais se estivéssemos precisando de um TransactionManager (JTA).

Ok, mas eu configurei o jetty com o bitronix, é bem simples... pra variar :P

Vai ai a papinha feita ;)

Download aqui:

[url]http://docs.codehaus.org/display/BTM/Download[/url]

E ai é só copiar o q esta dentro do lib e o btm-1.2.jar para dentro do lib do Jetty.

Depois nos contexts estou usando a configuração assim:

<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">

<Configure class="org.mortbay.jetty.webapp.WebAppContext">
        <Set name="configurationClasses">
            <Array type="java.lang.String">
              <Item>org.mortbay.jetty.webapp.WebInfConfiguration</Item>
              <Item>org.mortbay.jetty.plus.webapp.EnvConfiguration</Item>
              <Item>org.mortbay.jetty.plus.webapp.Configuration</Item>
              <Item>org.mortbay.jetty.webapp.JettyWebXmlConfiguration</Item>
              <Item>org.mortbay.jetty.webapp.TagLibConfiguration</Item>
            </Array>
        </Set>
        <Set name="contextPath">/myapp</Set>
        <Set name="resourceBase"><SystemProperty name="jetty.home" default="."/>/webapps/myapp</Set>
        <New id="myds" class="org.mortbay.jetty.plus.naming.Resource">
            <Arg>jdbc/myds</Arg>
            <Arg>
                        <New class="bitronix.tm.resource.jdbc.PoolingDataSource">
                                <Set name="allowLocalTransactions">true</Set>
                                <Set name="uniqueName">jdbc/myds</Set>
                                <Set name="className">org.h2.jdbcx.JdbcDataSource</Set>
                                <Set name="minPoolSize">10</Set>
                                <Set name="maxPoolSize">50</Set>
                                <Get name="driverProperties">
                                        <Put name="User">sa</Put>
                                        <Put name="Password">sa</Put>
                                        <Put name="URL">jdbc:h2:file:/var/dbs/mydb</Put>
                                </Get>
                                <Call name="init" />
                        </New>
            </Arg>
        </New>
</Configure>

Rubem Azenha:

leandrokjava:

quero saber o que o jetty tem, ele é realmente igual ao tomcat? tem algo a mais? etc…

A resposta curta é: o jetty não da memory leak com o GUJ

glassfish come muita memória… mas memory leak é sempre o problema de praxe…

Fabio Kung,

Teria como você disponibilizar o link para baixarmos o nginx e a rotina de instalação e configuração no jetty?

Desde já agradecido

Aqui: http://nginx.net/

Nao ha o que configurar no Jetty, apenas o nginx. No caso do GUJ, as imagens sao lidadas por ele, e o resto delegado ao Jetty.

Rafael

Seria possível disponibilizar e explicar sobre a configuração que vocês adotaram no nginx para lidar com as imagens do guj? Tenho certeza que várias outras pessoas vão acabar utilizando a solução encontrada por vocês para servir imagens em seus respectivos projetos. Eu mesmo seria um deles.

Aqui tem um exemplo -> http://docs.planetargon.com/Nginx_Configuration/

O que mudaria é que em vez de ser o upstream mongrel seria um upstream “nome_da_sua_aplicacao” e com os ips dos seus servidores.

Mas em quais linhas de código fica explícito que a configuração da página(http://docs.planetargon.com/Nginx_Configuration/) é para servir apenas as imagens do site mongrel? Você saberia explicar para que serve cada linha de código da configuração?

Boa tarde, revivendo um pouco este tópico…

E quando se utiliza o jboss 4.2.2 como servlet conteiner, por causa da utilização de EJB, quais seriam as opções para este cenário? teria alguma opção mais leve equivalente ao jetty? há algum problema na adoção de algum proxy pra servir conteudos estáticos?

Desculpem ressucitar o tópico de forma tão drástica, mas… Passados quase 5 anos, o GUJ ainda está no Jetty ou já há uma nova arquitetura por trás?

Abs []