Why is the Hibernate query.list() slow?

Question

I am using Hibernate 4.1.6 and having issues with the speed that a list is built. I am running the following query.

public void doQuery(final Baz baz){
  fi         


        

Answer 1

I am not 100% certain on this answer, since tuning / optimization issues are always so difficult to pinpoint.

However, based on the fact that you turned on show_sql, extracted the query, and ran it directly against the database and saw sub-second results vs execution time through Hibernate Query, I am focusing on the manner in which Hibernate is constructing and hydrating objects that result from the query.list() call.

Here is another user who mentioned similar Query performance issues in Hibernate, and saw dramatic performance increases by adding full convenience constructors (constructors that accept a value for each field) in the POJO: Simple hibernate query returning very slowly

It sounds like they stumbled upon this fix, and there was not a clear understanding of why this worked. There was speculation regarding Hibernate having to use reflection to detect properties. I am curious myself and am planning to dig into the source code for Hibernate to better understand this when I have a chance. In the meantime, though, you may wish to look into adding these full constructors with parameters for all of your POJO class attributes and see if that makes a difference.

Please do let me know what you find, as I am very interested in Hibernate performance optimization. Thanks!

Answer 2

If the queries (with show_sql) don't seem to have a problem, then maybe it's in the code. Start up VisualVM (comes with the JDK as jvisualvm) and use its CPU profiler to find out which methods take the longest time.

Answer 3

I ran that query directly in the database and it returned 23,000 rows in 0.015 ms. So, I'm guessing the query is not the issue.

That may be premature, as query execution times depend on a lot more than the query text. Even if they queries are run on the same data, how do you know that the database used the same execution plan? How do you know that it gets the same amount of cache hits in its disk cache? For instance, hibernate uses prepared statements when talking to the database, but you probably didn't. In Oracle, execution plans are cached by query text, so a different query text means a freshly computed execution plan. Since the cached execution plan may have been formed based on different query parameters it may very well be different - and that can change execution times by orders of magnitude. Note that I am not saying that it is the database, but I wouldn't discount the possibility.

Therefore, the first thing you should do is measure whether the database, or something running in your JVM is wasting all that time. A simple way to do that is to watch the JVMs cpu consumption as the query is being executed. If it is significantly less than one thread, the JVM is waiting for something - presumably the database.

If it is the database, use the optimization tools of your database to capture the execution plan, and other relevant performance metrics.

If it is in the JVM, use a Profiler to pinpoint the performance bottleneck.

Answer 4

I am not sure, but I am facing this problem in my current project.

In my case the problem is that hibernate uses cross join to do implicit joins, so (in my opinion) it takes time after fetching the data from database in order to construct the results (maybe using reflection).

My solution was to use inner join explicitly.

to your problem, I think that you may use inner join explicitly instead of just join.

Answer 5

We ran into a similar issue, dunno if it's related. Basically, since we were newing up new SessionFactorys once per query, it was doing queries like:

 select streamref0_.UUID as UUID145_, streamref0_.Tape_TapeId as Tape2_145_ from StreamRefToTape streamref0_ where streamref0_.UUID=?

You'll notice the large numbers in there. Turns out that it increments once per new session factory. Anyway, this was causing oracle to spend all its time doing a new plan for each query (it reported cpu was almost all in "hard parse" time generating new plans--I guess Oracle is slow to generate plans that it hasn't seen before?). The fix in this particular case was to just use the same factory instead of a new one each time. See also Hibernate produce different SQL for every query

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2588723819082 explains hard parses, which are apparently bad.

Another possible fix is to use "raw sql" (jdbc) or possibly raw sql queries within hibernate, though that didn't seem to fix the problem in this particular case somehow...