Hello.

We have been using Hibernate since April 2004. Some stats about our application in Hibernate layer are: 90+ .hbm, 200+ queries.

At the moment we are trying to migrate Hibernate from 2.1.8 to release 3.

After the reading of the "Hibernate3 Migration Guide" we applied the next steps: package naming, association fetching strategies, DTD.

Ok... The result is drammatically slow for a factor ten.
There is a heavy function, PortfolioAnalisys, in our application: with the release 2 the time was 60 sec.; now the time spent in that function is 600 sec.

We used 3.0.5 and 3.1beta2 without success. Maybe it's the way to analyze and execute the query. We tried to use the quey analyzer of 2.1 in 3 without success. Of course we experimented a lot of try without success.

We are using JDK 1.5.0_04.

Any idea? Exchanging only the Hibernate libraries and modifing the code to fix the errors (package naming, etc.), the application slows down.


Thank for your support.

Regards,
Alberto Santini

and it is not just because your DTD still references the hibernate 2 dtd instead of the hibernate 3 dtd ?

If not, then enable sql logging and compare the two versions sql - that should give you a pretty good hint on what the difference is.

No. DTD was one of the first things we fix.

The part of log about that function is 4Mb. It's hard to read or to compare, but it will be the last chance.

Regards,
Alberto

did your 60 sec routine generate 4Mb pure SQL ? pretty effective i must say ;)

Ok... 4Mb for all the log... :) not only Hibernate.
I will try to filter Hibernate trace.

Did you any experience about the performance issue of the migration from 2 to 3?


Regards,
Alberto

H3 is more tunable so if used correctly it can be made faster than H2.

You have to check how the change from non-lazy to lazy affects you.
Maybe you loaded everything by default before with H2 and gained from that, where as in H3 it will only load on demand and that might slow you down....just need to check what is most usefull for you.

I know the default value for lazy attribute in H2 is false, in H3 is true.
We didn't change out .hbm during the translation: only DTD reference and some HQL parsing error. We had no lazy="false" and a lot of lazy="true".

So the expected result is a gain in H3. Again in our unit testing H3 is faster than H2. Sure.

Ok. I describe the last two try. We have our application and our focus is on Hibernate libraries and the code generated for .hbm by HibernateSyncronizer, an Eclipse plugin.

1) Using H2 framework and the correspondent level of code generated for the .hbm files (and fixing the errors in the application, you know, packaging name, etc.), the application works fine.

2) Using H3 framework and changing the code generated to port to H3 level for the .hbm files (and fixing the errors in the application, you know, packaging name, etc.), the application works slow.

Sigh! :(

Regards,
Alberto

you'll just need to go look at where the time is spent with a profiler

Uhm... maybe I cannot justify correctly... but this is the profile
for the 10 first class base time ordered:

Class Package <Base Time (seconds) Average Base Time (seconds) Cumulative Time (seconds) Calls
DefaultFlushEntityEventListener org.hibernate.event.def 14.60% 0.00% 28.89% 7.76%
AbstractFlushingEventListener org.hibernate.event.def 4.86% 0.00% 43.76% 2.52%
AbstractEntityPersister org.hibernate.persister.entity 4.25% 0.00% 10.19% 11.51%
CollectionType org.hibernate.type 2.91% 0.00% 4.27% 6.53%
CollectionEntry org.hibernate.engine 2.72% 0.00% 5.06% 6.45%
Cascade org.hibernate.engine 2.62% 0.00% 8.89% 2.59%
Collections org.hibernate.engine 2.60% 0.00% 2.62% 1.58%
StatefulPersistenceContext org.hibernate.engine 2.02% 0.00% 2.60% 6.19%
TwoPhaseLoad org.hibernate.engine 1.62% 0.00% 7.70% 0.33%
AbstractPersistentCollection org.hibernate.collection 1.46% 0.00% 3.52% 2.62%
DefaultSaveOrUpdateEventListener org.hibernate.event.def 1.44% 0.00% 1.65% 1.10%

sorry - but i can't help you profiling this way (takes too much time).

you need to compare with the H2 version and find out where the difference lays! ...it should be easy to find what is the big difference when it is from 60 sec to 600...

Got it!

After comparing the profiling between H2 e H3 we noted a different use of dirtyCheck function. There is a flag FlushMode for the session.

The default in H3 is AUTO as, I think, in H2.
Setting this attribute to NEVER, when the session is created, we the application runs with the same time using H2.

Maybe in the implementation of Hibernate there is a different use of FlushMode for the value AUTO in H2 and in H3.

At the moment I don't understand what is the side effect of this change, but I'm quite happyof the discovery.

Thanks for the support and for the patience.

Regards,
Alberto Santini

FlushMode defaults have not changed in H3 compared to H2.

Are you sure you are not just loading much more into memory than expected so flushing takes more time than it did in H2 ?

You should not change FlushMode if you dont understand the meaning of it.

Our .hbm are the same with H2 library and with H3 library.
We have lazy attribute set to true. I checked it again and I confirm it.

So I think we have the same load in H2 and in H3.

Am I wrong?

Regards,
Alberto Santini

check your logs and session size!

Sorry max... my fault... but how to check session size?
I suppose is not default batch fetch size.

Thanks,
Alberto Santini