Caching jdbc statements constructors would improve performance

[GoogleCodeExporter]

Our application does high number of database calls. Adding JavaMelody to it add 
significant overhead. Profiling shows that one of bottlenecks is creating 
statements proxies, more specific - loading actual class. This could be 
optimized by caching Constructor objects. 
Attaching piece of code using right now.

Original issue reported on code.google.com by kaln...@gmail.com on 17 Oct 2013 at 6:21

Attachments:

• javamelody.png
• javamelody.txt

[GoogleCodeExporter]

This seems interesting to optimize.

First, you say "Our application does high number of database calls", but how 
high is it? Is it an in-memory database (H2, HSQLDB...) for example?

In your piece of code, why do you use a key with both the class and the 
classloader? Is the class not enough as key?

I think that we need something against memory leaks. For example, on undeploy 
if javamelody.jar is shared between webapps. Probably, a synchronized 
WeakHashMap would be good.

Original comment by evernat@free.fr on 17 Oct 2013 at 5:10

[GoogleCodeExporter]

Database is Oracle. For number attached screenshot from performance test.
Classloader used for key construction as it is  used in Proxy.getProxyClass 
call. I'm not sure can same class come from different classloaders, so for  
safety added it to key.

Original comment by kaln...@gmail.com on 21 Oct 2013 at 7:12

Attachments:

• javamelody2.png

[GoogleCodeExporter]

Wow! 140,000 sql hits per minute on Oracle DB are a high number of calls indeed.
I better understand your issue now.

For the classloader:
Given that the classloader used comes from the class anyway, I think that the 
classloader does not add anything to the key. And so I think that the class can 
be used as key.

Original comment by evernat@free.fr on 27 Oct 2013 at 12:40

[GoogleCodeExporter]

The creation of jdbc proxies is now optimized, for the case when there is a 
high frequency of sql hits (for example, more than 100000 sql hits per minute)

It's committed in trunk (revision 3556) and ready for the next release (1.48).

I have made a new build from trunk and it is available at:
https://javamelody.googlecode.com/files/javamelody-20131101.jar

Thanks

Original comment by evernat@free.fr on 2 Nov 2013 at 12:35

• Changed state: Fixed