Hi,

We have implemented a webabb that executes around 5000 reads upon initial load.
We added hibernate to our application for different databases support (SQLServer, MySQL) this was done
successfully and we are benifiting greatly from Hibernate for about a year now. However, we now are looking at the
performance overhead that Hibernate adds. We are ready to accept an overhead for the advantages we have gained but we
initially measured an load time that is 400% of the native sql code.

After some tweaking, we reduced the time to around 200% by setting the "Auto-Commit" property to true.
We still feel that a 200% increase is too much of a price to pay. We proceeded to measure more precisely
the native SQL calls versus the Hibernate calls and we have found the following:
(we are under WinXP, Tomcat, MSSQL, hibernate 3, Microsoft JDBC drivers, executing simple selects (no inter-entity mapping used for hibernate))

1. Observing SQL profiler, we see that multiple SQL calls coming from the native code implementation have the same timestamps while
every sql call coming from the hibernate implementation is "sequential" (with carying delays of 10-20ms). We have not been able to
identify the reason for this difference in behavior.

2. Adding debug strings before and after the API calls to the database (native and hibernate), we observe an almost
instantaneous execution of the native call while hibernate calls take around 16ms. (we use the CreateQuery API). Is this a normal
hibernate parsing overhead?

Can anyone give us their opinions on the performance differences we are observing?

Questions:

a. Is the transaction manager a factor in our issues ? (We defined JDBCTansaction in our config file)
b. Is the connection manager a factor in our issues? ( We are using c3p0)
c. Is this a normal overall performance overhead?




Thanks,
Minh

Point 1 above suggests to me that you have an exhaustive flush strategy. Are you noticing this after reads, or only writes? If writes are the main culprits, you may want to read up on bulk updates, and reduce the number of calls to Session.flush() in your app.

My only other observation would be that a doubling of load time at start-up would be a reasonable price to pay if those 5000 entities remain in a cache and have negligible lookup times after start-up. The main hibernate-using app that my company is developing has not noticed enough of a performance hit (in the 9 months since we converted) to prompt any complaints from users; however, we don't have 5000 selects running at log-on time.

Just to make sure: in both cases you have measured the whole thing (running the SQL, creating the java objecs,....) and not just Query.list vs. PreparedStatement.execute query?

You migth want to check whether you have more objects in your hibernate session than you need. Have lots of objects in your session ain't a good idea as hibernate usually checks whether there are any modified objects that might have to be flushed before a SQL query can run. Perhaps you can use Session.evict to remove objects that are no longer needed or you could use some custom code to determine what needs to be flushed.

Have you run your Java code in a profiler?

1. The measures were made on the whole thing as you described.
2. Concerning Session.flush()

We used HibernateSynchronizer to generate our initial code (Hibernate 2.x) and have modified our code so it can run with Hibernate 3. All we do are reads (no writes) on load and these are done with the return "s.createQuery(query).list()" call. These calls are mostly SELECT ... WHERE ID = X.

We do not explicitly call any session methods when running these queries.
We haven't looked at the mechanism of the session object. Should we be doing something particular in the initialization phase or during out calls?

This brings me to the question : How do are you setting up your hobernate config files?

3. We haven't run our Java code in a profiler. Which profiler do you suggest and what do you think we can identify by doing this?


Thanks,
Minh

Also I noticed that there is noticeable lag before the first SQL is passed to MSSQL with hibernate. In our case, almost 10 seconds pass before I see any activity on SQL PROFILER. While, the native implementation, the SQL start almost instantaneously. So I see two performance bumps:

1. On start-up, our hibernate implementation takes time to get going
2. The SQL reads are not processed as fast with hibernate as with the native implemenation.

thanks,
Minh

1. On start-up, our hibernate implementation takes time to get going

Yes, it takes time to parse XML, generate byte code on startup.

2. The SQL reads are not processed as fast with hibernate as with the native implemenation.
Try Stateless session, it must be as fast as JDBC code in theory, but it will not use cache (cache can help for readonly stuff, "session.load" for "SELECT ... WHERE ID = X" type queries);

http://ehcache.sourceforge.net/document ... ocId590937

I tried using StatelessSession and it does not appear to help the performance. I replaced all reference to Session with StatelessSession and continued using the CreateQuery call (as there is no LOAD method for the stateless session).

thanks,
Minh

use a profiler to find the problem/difference.