Tenho uma aplicação desenvolvida com eclipseLink (JPA), JSF2, primefaces e rodamos sobre o Glassfish 3.1.
Essa aplicação conta com pelo menos 300 ejb’s e ela é separada em módulos (são um conjunto de projetos do eclipse), então tenho um módulo geral e vários outros mini módulos.
Esses outros módulos podem acessar o módulo geral, já o contário não ocorre.
Fora isso, usamos 01 iframe na camada de apresentação (que acredito causar perca de desempenho na renderização da tela).
Essa aplicação eapresenta lentidão e excessivo consumo de memória e devido a isso, estou analisando algumas medidas para melhorar.
Uma das medidas é a revisão de consultas, já que usamos muito NamedQueries e JPQL.
Acredito que isso vai fazer a aplicação ter uma melhora, mas não o bastante.
Uma segunda medida seria rever a necessídade do uso de ejb’s, mas tenho muitas dúvidas nesse assunto.
Por exemplo, acreditam que o uso de EJB’s adiciona um gasto de memória e desempenho a aplicação?
Poderia substituir os EJB’s por alguma outra tecnologia pensando em ganho de desempenho e redução de uso de memória?
EJB é mais voltado para client Java. Para web se torna excesso de engenharia, assim como JPA/Hibernate, que é um ORM muito custoso e sem benefícios para esse tipo de aplicação, já client Java tem o benefício do usuário ter o objeto Java, cache e lazy localmente. JSF é outra bomba. A stack oficial de frameworks Java sempre foi ruim.
Uma opção menos custosa para Java, sem perder produtividade, é usar Spring Boot seguindo REST e na persistência JDBCTemplate.
E emergencialmente considerando o que você tem hoje, seria:
Retirar esses iframes e usar ajax.
Analisar o plano de execução dos SQLs e criar índice para o que tiver ruim.
Revisar as queries geradas pelo hibernate, principalmente verificar se você não está cometendo o erro de gerar n + 1 SQLs. No geral, cuidado com lazy, já que lazy é inútil em requisições HTTP.
Eu sugiro rever a questão do front. iframe é e sempre foi bastante complicado e pesado.
Os ejbs são singleton, stateless ou stateful? Dependendo de como você tem esses caras configurados, o consumo de memória é excessivo, sim.
Persistência: embora a teoria pareça bacana, o ideal mesmo é abandonar o JPA e partir para customizar queries na mão mesmo.
Opa, eu já uso ajax dentro do iframe, mas acredito que de para melhorar isso.
Vou rever as consultas com certeza.
Vou pesquisar sobre JDBCTemplate, pois não conheço, mas quando você diz que JPA é pesado e sem benefícios para meu tipo de aplicação, o que quer dizer com isso?
Sobre os ejb’s, tenho em torno de 300 criados, acha que isso influencia muito na questão de memória?
Vou rever esse lance do iframe, acredito que consiga retirar ele.
Os ejb’s são Stateless, tenho um ou outro Stateful, porém, no glassfish uso algumas configurações para manter 10 instâncias deles sempre ativos,
Talvez tenha que rever essas configurações.
Não sei qual o ganho que você tem mantendo as instâncias deles ativas. Talvez fosse mais interessante mudar para stateful, pois o ciclo de vida já prevê que ele seja ativado, execute e vá dormir.
Ah, outra coisa, como os dados são exibidos? Pode ser que seja um problema com relação à renderização em si.
Menos mal já usar ajax, então se livra da carga do iframe.
Sobre JPA/Hibermate, se uma session factory é pesada, imagina 300. Escalabilidade com hibernate é custoso. E se sua aplicação consulta informações online do banco de dados, qual benefício traz hibernar os dados no web server durante uma requisição HTTP pro client? Qual sentido tem o lazy numa requição web? São custos sem retono pro cliente.
Sobre os 300 Ejbs, deixa eles por último, vai atacando o que for viável no momento, como falei da parte emergencial.
Obrigado pelas dicas.
Demorei em responder pois estava analisando tudo o que vc e os demais comentaram sobre o meu problema.
De início, vamos rever as consultas e tentar migrar para JDBCTemplate, abandonando o JPA.