There is a wrong assumption that Hibernate is slower then JDBC, this is not true.
For the tests that I have done I had found that Hibernate performance are not less then Pure JDBC.
I had compared the performance between Hibernate and Pure JDBC for writing 10,000 rows to the DB table, The results are really surprising.
The test run on a single thread which write in a loop the rows in bulk update, the JDBC used batch update processing with prepared statement, the Hibernate run on a single session which flush the inserts to the DB every 100 rows (Bulk Updates).
I had worked with Hibernate 3.0 on a regular Pentium Pentium 4 2.66GHz with 2GB RAM, The DB was remote Oracle 9 DB.
Well are are the surprising, Hibernate and Pure JDBC results are completely the same !!!
Hibernate doesn't have a huge overhead as you expect it to have.
For the results I manage to write 10,000 rows to the DB in 1.5 Seconds !!!
Here are some tips for improve your Hibernate performance are:
- Try to reduce the number of open and close of hibernate sessions
- Using Hibernate bulk updates were possible
- When using Hibernate bulk updates try to separate the SQL Insert/Update/Delete statements to groups, the DB would process this groups faster (For example 20 SQL inserts then 40 SQL updates and then 25 SQL delete statements)
15 comments:
Hi!
I've run tests with Toplink Essentials as JPA provider.
Insert were at least 100x - 1000x slower (compared to native jdbc with bulk insert). I can't find anything useful in the Toplink Essentials documentation about bulk updates.
Could you rerun your test with Toplink Essentials?
Does anyone know how to tell Toplink Essentials to use bulk inserts or does it already use them?
Thanks
- stephan
Hi Stephan
I assume that Toplink Essentials open a new session each time you do a single SQL insert, or that it doesn't use prepared statements - The statement need to be something like this: "insert into TABLE values (?,?,?,?)"
Only if you would use prepared statements and single session to the access the DB then Oracle would write it to you in Bulk
Okay, now do a similar test for alternating inserts, updates, deletes with different statements. And then also do a test with complex queries.
There's a lot more to performance than inserting... ;-)
Hibernate is slower than pure JDBC by design. I work in finance industry and my team does not use Hibernate mostly because its convenience can not make us ignore its weakness: performance.
Anyone who is competent enough in Java already knows Hibernate is a wrapper around JDBC to provide an OOP interface to SQL queries. It means that Hibernate = JDBC + lot more CPU cycles + more memory. However, Hibernate is written by very competent Java developers so its implementation is full of code optimization to make underlying JDBC work at its best.
I believe that Hibernate is a good tool for developers those who are not familiar to SQL and/or work with database. However, to good Java developers with strong SQL skill, Hibernate is not an optimal choice. iBatis is better apparently.
Therefore, I think that junior and upper junior Java developers love to work with Hibernate in not-so-complex database query scenarios because it helps them to reduce a lot of code. But when they are good enough in writing SQL, understand database server insight out and want more flexibility and optimization and/or need to write complex queries, they will consider Hibernate a bad choice. Think iBatis, right?
hibernate can spec the insert update and delete queries just like ibatis. addtionally, you get all of the additional hibernate power. so, i think hibernate is an easy choice.
i would take issue with the statement that hibernate is slower because it is a wrapper. in theory, this can be correct. theory, though, is not reality. in practice, programmer's often make mistakes. the boiler plate code that converts sql resultsets to objects and caches them in some meaningful way can be problematic. in fact, caching efficiently is difficult to get right. hibernate already does this well and is highly optimized. so, in practice, it is absolutely possible to get huge performance gains out of hibernate depending on how you tune it's use of caching.
Therefore, I think that junior and upper junior Java developers love to work with Hibernate in not-so-complex database query scenarios because it helps them to reduce a lot of code. But when they are good enough in writing SQL, understand database server insight out and want more flexibility and optimization and/or need to write complex queries, they will consider Hibernate a bad choice. Think iBatis, right?
Um.....the whole point is not that people are not "good enough in writing sql" to not use Hibernate. Hibernate (or any ORM) buys you the ability to think of your data model as object and model it accordingly. Also with ORMs you don't have to litter your code with sql all over the place. Who wants to maintain that?, Yuck!
I've done a few of my own performance measurements and also don't find there is much difference between inserting using JDBC or Hibernate. The Hibernate team seem to have written some slick code in this area.
However, I do seem to be finding that the query performance is significantly slower going through hibernate.
Hibernate vs JDBC performance
I've been looking into using Hibernate this week and testing with it seems to take 2-3x more time to execute 100,000 records in bulk as straight jdbc prepared statements which seems a bit slow to me. It's taking 32-45 seconds to insert 100,000 records versus 10-20 seconds with straight jdbc batched prepared statement. I'm going to be looking at iBATIS now since we need to support a very high volume insert rate.
If anyone knows any tricks into getting Hibernate to perform closer in line with batched jdbc prepared statements please respond.
Jesse Said: "If anyone knows any tricks into getting Hibernate to perform closer in line with batched jdbc prepared statements please respond.
"
Jesse here are the tricks to get Hibernate to perform close with JDBC:
1. User the same Hibernate Session for the Bulk inserts.
2. Write group of Hibernate HQL insertes with the same arguments order to the Same table.
3. Config your Hibernate XML file Bulk Size.
4. You may need to config Oracle to work in Batch(Bulk) mode.
5. Every 100/200 Inserts flush your Hibernate Session
need a J2EE/Hibernate developer in NYC for developing a high volume application.
if interested please email me at zmulla@sidglobal.com
How do you Configure your Hibernate XML file Bulk Size?
in hibernate.cfg.xml write
hibernate.jdbc.batch_size 20
for example
My personal experience is Hibernate performs better than pure JDBC especially while inserting complex parent-child relationships. But for reading data, I would prefer JDBC while working with high volume database oriented applications.
I also found Hibernate 10 to 40 times slower than plain JDBC.
I used to insert 20000 rows and same rows updates using Hibernate and JDBC.
Database was in remote location.
Hi, I created performance test beetween jdbc and hibernate, and you can find it here
http://phpdao.com/hibernate_vs_jdbc/
Post a Comment