JSF e aparente consumo de memória no servidor [resolvido]

This message was edited 1 time. Last update was at 06/08/2008 07:23:18

Olá a todos!

Recentemente a equipe na qual trabalho terminou o nosso primeiro projeto feito em JSF, usando o Visual Web do Netbeans 6.1.

Quando implantamos o WAR no servidor de homologação para testar, percebemos que o consumo de memória do Tomcat 6 salta de 2% para 8%. Após usarmos o sistema durante algum tempo, o consumo de memória já encontra-se em 40%. Passando mais tempo usando o sistema, chega a 70% de memória consumida.

Pesquisamos sobre alguns parâmetros de ajuste do Garbage Collector e configuramos o serviço do Tomcat com algumas melhorias. Melhorou apenas de 1 a 2 % a menos do que antes.

Estou suspeitando que a implementação do JSF que vem no Netbeans não está removendo as referências dos objetos e, assim, o Garbage Collector não está sabendo quais objetos pode remover da memória.

Alguém já passou por isso ou tem alguma sugestão?

Duas coisas que você deve observar...
Quais os escopos dos seus managed-beans?
Você utiliza <redirect/> nos seus navigations-rules?

Oi Lucas,

Os managed-beans que estão associados às páginas são de escopo request. É o padrão do Visual Web Netbeans.

Observei que a IDE não colocou nenhum navigation-rule como redirect.

Então Alexandre, geralmente a sobrecarga de memória em um servidor está relacionada a estes dois itens.
O redirect causa a constante re-instanciação dos beans do UIViewRoot atual e managed-beans com session e application ou none ligados a um desses dois.

Vou dar uma pesquisada aqui e ver se encontro alguma coisa.
Abraços

Oi alexandremlima,

Desculpe tirar uma dúvida com vc justamente quando é você que está querendo obter respostas para um problema seu.

É o seguinte: Estou em dúvida entre utilizar o Eclipse+richfaces (com ajax) + implementar as páginas "na mão" e utilizar o NetBeans + Visual Web (+ ajax se possivel) + implementar as páginas com drag and drop.

Como você disse que utilizou o NetBeans + Visual Web e provavelmente utilizou o drag and drop e completou o projeto eu gostaria de saber de você se realmente vale a pena esta alternativa e quais foram os pontos negativos (se houve algum).

Espero não tirar o foco do seu problema com esta pergunta, mas vc é o primeiro que "ouvi" dizer que completou o projeto com esta alternativa.

Abraços

Se for para ganho de produtividade, realmente o Netbeans + Visual Web te dará isso. Porém, tome cuidado com os tutoriais na Internet sobre essa dupla. Eles ensinam a montar uma aplicação na qual sua interface conecta-se diretamente com o banco. Divida sua aplicação em camadas distintas para ganhar na manutenção e flexibilidade depois. Um ponto negativo é a falta de criar um template para as páginas - cada uma tem que ser montado desde o início.

Andei pesquisando na Internet e sempre que as pessoas usam MyFaces, Richfaces, etc, elas adicionam o Spring no meio. Eu não usei o Spring ainda, mas acho que deve aumentar a sua curva de aprendizado e afetar sua produtividade. No nosso projeto, tínhamos que ser rápidos e não obtivemos liberação para aprender nada mais do que o já tinha sido estudado pela equipe.

Estou com esse problema de consumo de memória usando o Netbeans + Visual Web. Não sei se você passaria por isso também - sendo assim um problema que acontece somente comigo - ou você enfrentaria esse problema também. Ainda não encontrei na Internet ninguém com esse mesmo problema que o meu, mas já encontrei pessoas que tiveram problemas de consumo de memória com a especificação JSF.

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Olá alexandremlima,

O consumo de memória está realmente intenso, e a melhor maneira de descobrir o problema seria com a utilização de alguma ferramenta de profiler, assim você encontraria os gargalos na aplicação.

Pelo visto você não utiliza seus managed beans com o escopo de session, o que é um bom sinal, contudo isso não descarta a possibilidade do uso incorreto da session. Vocês estão utilizando algum componente ou framework para manter algum escopo conversacional entre as páginas?

Como está ocorrendo a paginação dos teus registros? Sob demanda ou os dados estão sendo paginados na session?

Quais os frameworks que vocês estão utilizando na aplicação?

Lucas Lacerda Gertel wrote:O redirect causa a constante re-instanciação dos beans do UIViewRoot atual e managed-beans com session e application ou none ligados a um desses dois.

Olá Lacerda, sinceramente eu não consigo ver o problema na utilização do redirect, poderia explicar?

rponte wrote:

Lucas Lacerda Gertel wrote:O redirect causa a constante re-instanciação dos beans do UIViewRoot atual e managed-beans com session e application ou none ligados a um desses dois.

Olá Lacerda, sinceramente eu não consigo ver o problema na utilização do redirect, poderia explicar?

Com usar redirect eu não conheço problema, o problema é pra quem não usa redirect, pois se você não redireciona o usuário após um post ele pode dar refresh ou back e mandar tudo denovo, o que não é nem um pouco interessante.

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Maurício Linhares wrote:

rponte wrote:

Lucas Lacerda Gertel wrote:O redirect causa a constante re-instanciação dos beans do UIViewRoot atual e managed-beans com session e application ou none ligados a um desses dois.

Olá Lacerda, sinceramente eu não consigo ver o problema na utilização do redirect, poderia explicar?

Com usar redirect eu não conheço problema, o problema é pra quem não usa redirect, pois se você não redireciona o usuário após um post ele pode dar refresh ou back e mandar tudo denovo, o que não é nem um pouco interessante.

Isso é verdade Maurício, você está certo, podemos resolver isso com o pattern PRG. Mas eu ainda não consegui ver qual a relação do redirect com o consumo de memória comentado pelo Lacerda.

Rponte,

rponte wrote:O consumo de memória está realmente intenso, e a melhor maneira de descobrir o problema seria com a utilização de alguma ferramenta de profiler, assim você encontraria os gargalos na aplicação.

A gente monitora a performance de nossa instância do Tomcat com a ferramenta Lambda Probe. Foi ela quem nos mostrou o problema de consumo de memória.

rponte wrote:Pelo visto você não utiliza seus managed beans com o escopo de session, o que é um bom sinal, contudo isso não descarta a possibilidade do uso incorreto da session. Vocês estão utilizando algum componente ou framework para manter algum escopo conversacional entre as páginas?

Quais os frameworks que vocês estão utilizando na aplicação?

Nós usamos apenas o que o Netbeans nos fornece, sem nenhum outro framework a não ser o plug-in Visual Web.

rponte wrote:Como está ocorrendo a paginação dos teus registros? Sob demanda ou os dados estão sendo paginados na session?

A paginação dos registros é feita em sessão pelo componente DataTable. Quando o problema acontece, a coleção na memória é de apenas 30 registros.

Obrigado pela atenção!

Oi alexandremlima,

Obrigado pela resposta sobre o Visual Web.

Em relação ao seu problema gostaria de saber como é que está o tempo de resposta do seu banco de dados. Porque se a resposta for baixa isso irá fazer com que sejam criadas mais threads no servidor causando grande uso de memória verifique também se o ciclo de vida das requisições está correto, sem deixar conexões com o banco pendentes.

[]'s

fantomas wrote:Em relação ao seu problema gostaria de saber como é que está o tempo de resposta do seu banco de dados. Porque se a resposta for baixa isso irá fazer com que sejam criadas mais threads no servidor causando grande uso de memória verifique também se o ciclo de vida das requisições está correto, sem deixar conexões com o banco pendentes.

Nós usamos o Hibernate sob a especificação JPA para "conversar" com o banco de dados. Nós fizemos uma aplicação desktop que testa os objetos de negócio; o tempo de resposta nesse caso é bem satisfatório. A ferramenta Lambda Probe nos mostra que o Tomcat fica com mais ou menos umas 150 threads rodando enquanto o servidor estiver ativo (eu mesmo configurei o pool de threads do Tomcat). Estamos usando o Hibernate com o pool nativo do Tomcat. A ferramenta Lambda Probe mostra que as conexões estão sendo abertas e fechadas normalmente. Vou tentar pegar uns screenshoots da ferramenta Lambda Probe para postar aqui e ver se melhora o entendimento do problema.

Obrigado!

Alexandre, na equipe em que trabalho utilizamos o spring para gerenciamento de alguns beans, suporte ao Hibernate e sua implementação para AOP.
Realmente a curva de aprendizado é mais longa porém acredito que por tratarem-se de frameworks com papéis distintos (não utilizamos o Spring Web MVC) o tempo empreendido no assunto é de grande valia.
A produtividade aqui só aumentou depois do investimento.

rponte,
Quanto ao comentário sobre a tag <redirect/>, ele pode sim causar um um aumento significativo no consumo de memória se não utilizado devidamente.
No livro Java Server Faces The Complete Reference você pode encontrar toda uma explanação mais abrangente e detalhada mas a recomendação é utiliza-la somente quando existe a necessidade primordial das tuas url's tornarem-se "Favoritas" (Bookmarks).

No processamento da tag ou de uma chamada FacesContext.getCurrentInstance().getExternalContext().redirect() você realiza um novo postback no teu servidor.
Isso acaba "forçando" ao servlet container do JSF iniciar um novo ciclo de vida quando isto não é sempre necessário.
O consumo de memória está diretamente ligado a chamada de um novo ciclo quando desnecessário.

Lembrando que logo no primeiro ciclo (Restore view) o JSF vai fazer uma nova procura aos componentes relacionados aquela nova view correspondente.
Estes componentes já haviam sido inicializados no ciclo anterior! O fato do JSF ter um delay de URL acaba confundindo pessoas com conhecimento em CGI (pessoalmente penei com isso).
Assim toda a instanciação dos componentes UI relacionados a tua UIViewRoot serão novamente chamadas.

E para piorar, como está não é uma initial view (que faz com que o JSF pule do primeiro para o último ciclo) você acaba tendo problemas com beans gerenciados por requisições.
Espero ter sido claro.

Abraços,
Gertel

Coletei uns screenshots de nossa instância do Tomcat, monitorada pelo Lambda Probe.

O servidor, sem nada rodando nele, está do jeito que mostram esses screenshots.

Após o deploy da aplicação, a memória salta para 13,9%. Forçando o Garbage Collector, consigo uma redução desse consumo.

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