Recently, I am involved in a hibernate performance tuning project. We used to use Oracle Toplink as the Object-Relational mapping tool for our application. Several months ago, we decided to switch to the more popular JPA/Hibernate.

However, after the switch, we experienced wide-spread performance slowdown. To tune the performance of Hibernate, I did a thorough research in related articles. The more I dug in, the more I realized that performance tuning is a systematic effort. There are a lot factors contributing to the performance of Hibernate. I would like to list our experience here as a reference to everyone who use Hibernate.

Considerations for Hibernate Performance Tuning:

1. Database level

  • Data Model: The data model design can significantly impact the performance of your OR mapping. Not all the existing data model fits the requirement of Hibernate. Some tables need to be restructured.
  • Execution Plan: Hibernate uses its own set of queries. The execution plan for those queries need to be revisited.
  • RBO vs. CBO: Did you make the best use of the Cost Based Optimizer in Oracle 10g?
  • Full Analyze: Our DBA informed me this trick. Running a full analyze of Oracle may help Oracle to adjust to the new Hibernate usage pattern.

2. Connection/Sessions

  • Driver: Are you using “thin” or “oci”? Still using Oracle 9i driver? That may be the issue.
  • Connection pooling: Is the connection pooling set up appropriate?
  • Session Management: Did you cache your hibernate SessionFactory? It worthwhile to review the hibernate configuration for the sessions.
  • Flush mode: What is your flush strategy?

3. Query

  • Hibernate vs. Stored Proc: In some of the scenarios, it’s better to use stored procedures instead of Hibernate.
  • Tune your HQL
  • Batch update/query
  • Join: Revisit how you do the join.
  • Fetch mode

4. Object Model

  • Lazy loading: Without lazy loading, the performance may take a huge hit. Revisit your objects to avoid loading unnecessary objects in your object graph
  • Collections: Revisit how the collections are loaded

5. Cache

  • Cache Hit Ratio: The hit ratio of your secondary cache is an important factor of your performance. The more you cache, the better the performance, if you have enough memory
  • Cache provider: You need to find the most appropriate cache provider for your application. Revisit the cache configuration to reflect the unique needs of your application.

6. Memory

  • Heap size: Revisit your JVM settings
  • Garbage Collector settings

The Process To Approach Hibernate Performance Tuning:

  • Setup performance measurements
    • Determine which performance metrics (page to page speed, transaction execution time, top SQLs, etc.) to measure
    • Determine which resource utilization (memory, CPU, thread, connections, GC, etc.) to measure
    • Setup necessary tools to monitor those metrics. The best tool we use is CA Wily Introscope. You may also use Window Performance Monitor or other similar tools.
  • Run the Stress Test with performance monitors tuned on
    • Identify the worst performance problems. Find out the top 5 worst performed business transactions. You may use the product of average execution time and total number of transactions to measure the overall “impact” of that transaction to your application’s overall performance.
    • Review the resource utilizations to identify possible bottlenecks.
  • Run Profiler tool against the worse performed business transaction
    • Identify the bottleneck
    • Understand the root cause of the problem
  • Make changes according to the Profiling result.
  • Rerun the Profiling to see if there is any improvement. Repeat until performance is satisfactory.
  • Apply the lessons learned in tuning the worst performed transactions to similar transactions project wide.
  • Repeat the Stress Test to find more heavy transactions.

In my own experience, performance tuning is a long and iterative trial-and-error process. You may try a lot of things before you find the right solution. But once you find one problem and the solution for that, most likely, it’s applicable to many places of your project.

Another tip is you need to keep repeating the full iteration of test-diagnosis-fix-test. Fixing one problem may cause another problem. Or other deeper problems may emerge once you clean up the easy to fix problems.

There is no silver bullet to solve all the issues. Every application is unique and requires unique configuration and tuning. So, be patient and keep working.

Reference: