Alguma dica para fazer um "tunning" no Spring Framework?

Oi Adriano,

o consumo de memória não me parece tão alto assim. Mas sempre há uma coisinha ou outra que podemos fazer não é mesmo? Se o objetivo é diminuir o consumo, você pode observar algumas coisas:

• está usando AOP em excesso ou só o básico?
• escopo dos beans. É comum em sistemas que usem muitos beans do tipo prototype que estes consumam muita memória temporáriamente, antes da execução do GC. Neste caso é questão de verificar o uso mesmo.
• Hibernate: será que não estão rolando sessões gigantes?

Vamos ir discutindo aqui que, se bobear, a gente descobre algumas alternativas massa pro seu problema ok?

adriano_si:

Fala galera, estou usando hoje Spring em 2 projetos Desktop que precisam acessar uma mesma base assincronamente.

Estou com os Sistemas rodando e emperfeito funcionamento… Um deles é bem pequeno, só Background e acessa uma base de terceiro, o segundo, possui algumas telas Swing e fazem o trabalho grosso do Sistema.

O grande galho é, ambos estão consumindo em média, 55Mb de memória (o que agora não é problema, mas em breve será) e queríamos diminuir esse número.

Em ambas, usamos Spring JDBC/ Spring ORM (para a JPA)/ IoC / Scheduler…

Está bom, está rodando e funcionando bonito… Só queremos mesmo é ver algum recurso do Framework para diminuir esse consumo de memória, se é que há algo que dê pra tentar…

Abs []

oi,

Não sei se a otimização seria no Spring, mas talvez você possa dar uma olhada em outras coisas ao redor …

Por exemplo, é possível otimizar as queries SQL? precido de um índice nas tabelas? preciso de cache de segundo nível? posso por exemplo criar uma view ao invés de fazer vários joins? usando uma stored procedure eu teria alguma vantagem?

Além disso você pode tentar fazer o tunning da JVM mesmo, ver o que e onde está gastando recursos, e também verificar o tunning do servidor de aplicação onde a aplicação está rodando…

abs

Você pode usar o jmap para ver quantos e quais objetos estão sendo correntemente usados (casualmente, este exemplo é de uma aplicação que usa o Spring Framework também). Ele pode lhe mostrar algo como:

Object Histogram:

num 	  #instances	#bytes	Class description
--------------------------------------------------------------------------
1:		276850	26577600	br.com.exemplo.framework.messaging.avl.AVLMessageField
2:		460444	14713944	char[]
3:		137169	13661976	byte[]
4:		476060	11425440	java.lang.String
5:		81122	6489760	java.lang.reflect.Method
6:		49262	5799088	* ConstMethodKlass
7:		49262	4340600	* MethodKlass
8:		46117	3899080	java.util.HashMap$Entry[]
9:		77164	3703872	br.com.exemplo.RealLevel
10:		75465	3248304	* SymbolKlass
11:		46494	2872528	java.lang.Object[]
12:		4440	2472152	* ConstantPoolKlass
13:		91160	2187840	br.com.exemplo.framework.util.number.ScaledDecimal
14:		45455	2181840	java.nio.HeapByteBuffer
15:		45447	2181456	java.nio.HeapCharBuffer
...

Obviamente isso não é trivial de analisar mas pode lhe dar uma boa idéia

Quer usar um profilador ótimo de memória? Use o Netbeans, o dele é excelente e compatível com tudo.
Se seu projeto for baseado em Maven, ele já vai abrir direto nele.

Fala galera, já havia usado o jvisualvm da própria JDK que no final das contas é profile do netbeans…

Realmente Kico, estava observando e hoje dei uma olhada nos escopos… Um dos projetos estava abusando do Prototype, o outro estava o padrão, que creio eu, seja Singleton…

O que estava com Prototype na camada de serviços, sempŕe na execução do GC, cai pra 18 Mb e depois vai detonando pra 50 de novo, já o que usa singleton, fica fixo nos 50 e quando GC passa, cai no máximo pra 39 Mb. Ambos possuem Scheduler que executam Threads de 2 - 5 segundos.

Fiz uma varredura no Projeto agora pela tarde, mudando escopo de objetos, detonando algumas Strings que estavam sobrando e eliminando sujeira… Caiu uma média de uns 3 mb, mas ainda assim será um problema no futuro.

Quanto ao Hibernate, o cache de segundo nível estava implantado antes de eu chegar no projeto. Mas o Hibernate é o provider da JPA no nosso caso. Como eu nunca configurei o Hibernate e nunca tinha precisado desse ajuste fino, acabou que nunca conheci a fundo a estratégia de cache, vou dar uma estudada e ver o que eu consigo com isso.

Outro detalhe é que acesso 2 BDs, um Firebird (ou qualquer outro dependendo do cliente) e um Postgre (esse é fixo porque é interno do nosso negócio).

Como precisarei de acesso a vários bancos de acordo com cada cliente, usei JDBC no lugar da JPA para acesso aos mais variados bancos de dados com seus próprios campos e suas próprias regras. Aproveitei então o Spring JDBC (por já estar usando Spring) e confesso que não estudei a fundo o mesmo, sendo que vou tomar vergonha na cara e ver o que consigo também dando uma olhada na doc do Spring JDBC com calma.

Andre, já havíamos feito esse tunning a nível de base, valeu por lembrar.

No mais é isso aí galera, valeu pelos toques… Se lembrarem de mais alguma coisa que ajude a tunnar a App, agradeço… Quero tunnar a JVM como último recurso, mas não está fora de cogitação

Abs []

Já pensou na interface grafica? Os componentes do swing são meio pesados. Já tentou fazer uma limpa nelas? Tirar o que é mais “frescura” e deixar somente o que é realmente necessário… E os escopos das Threads como estão? atualizam algum componente gráfico pesado em pouco intervalo de tempo? Creio que o problema possa estar na interface grafica…

Fala Luis, valeu pelo retorno. Sim, as GUIs já estão o mais limpas possíveis…

Como lhe falei, o mais pesado é justamente o que fica com as Threads em Background… O que tem as interfaces, até que pesa, mas quando passa o GC ele cai pra 19 - 20 Mb.

Vamos dar uma olhada sim e ver se podemos enxugar mais as telas.

Valeu