Usual hibernate performance pitfall

Question

Hi,

We have just finish to profile our application. ( she's begin to be slow ). the problem seems to be "in hibernate".

It's a legacy mapping. Who work's, and do it's job. The relational shema behind is ok too.

But some request are slow as hell.

So, we would appreciate any input on common and usual mistake made with hibernate who end up with slow response.

Exemple : Eager in place of Lazy can change dramaticly the response time....

---

Edit : As usual, read the manual is often a good idea. A whole chapter cover this subject here :

http://docs.jboss.org/hibernate/core/3.3/reference/en/html/performance.html

Answer 1

One thing that happened at my company comes to mind. You could see if loading an entity also loads some serialized entity, that will be deserialized every time the entity is loaded. In addition, when commiting the transaction hibernate might do a flush() for you (is configurable). If it flushes, to maintain persistance, it will do a comparison on the entitiy committed and the one in the database. In this case it will do a comparison on the serialized object, which takes a long time.

Another thing you could do is check if you have any unnecessary persistance cascading i.e. @Cascade({CascadeType.PERSIST, CascadeType.SAVE_UPDATE}) annotation on columns.

Another thing you could do, which is not specifically related to hibernate, is that you create views to do a single query, instead of doing lots and lots of queries to different tables. That made a huge difference for us on a certain feature.

Answer 2

One of the most common pitfalls is the infamous n+1 selects problem. By default, Hibernate doesn't load data you didn't ask for. This reduces memory consumptions but exposes you to the n+1 selects problem which can be avoided by switching to the right fetching strategy to retrieve all the data you need to load objects in their appropriately initialized state.

But also don't fetch too much or you'll run into the opposite problem, the cartesian product issue: instead of executing to many SQL statements, you may end up creating statements that retrieve too much data.

That's the whole point of the tuning: finding the middle between not enough and too much data for each use case of your application (or at least, for the one that require to be tuned).

My recommendations:

• first activate SQL logging at Hibernate's level
• run the critical use cases (the 20% used 80% of the time) or even all of them if you have that luxury
• identify suspicious queries and optimize the fetch plan, check if indices are used appropriately, etc
• involve your DBA

Answer 3

As guys already mentioned the Hibernate performance is all about the right settings. I was once able to improve some credentials cache refresh speed by the factor of 10 (from 2s to 200ms) by switching to a stateless session (that particular code was not dependent on any type of lazy fetching so I could safely do what I did).