Performance Monetoring and Optimization of Hibernate Application

2010-11-28T07:10:00.000-08:00

Performance Optimization of Application

Now a days, enterprise systems are getting developed with various ORM tools like Hibernate, but if we use these tools incorrectly, it may degrade the system. We will see how to improve the performance of the system developed with one of the most popular ORM tool -Hibernate.
Following Diagram shows by what all ways hibernate application performance can be improved.

Using Hibernate Caching

A cache is the way to reduce traffic between your application and the database by conserving data already loaded from the database with the principle that database gets accessed only when retrieving data that is not currently available in the cache.

There are three types of cache available with Hibernate

First Level Cache

Second Level Cache

Query Cache

We will see it one by one in the below section.

First Level Cache

Cache associated with the Hibernate Session is first level cache, that means, whatever operations you do in single hibernate session gets executed in one query. Wel, its not true, actually it means, whatever database operations you perform in single hibernate session, Hibernate tries to optimize the generated SQL for you and hence reducing the database traffic. When you load the same data from multiple points in single session, hibernate actually fires only one query to retrieve data and for subsequent calls, you get the data from Session cache. Same happens if you are updating something multiple times in one session, there will be only one update query to database at the end of transaction containing all the modifications.
Also single session of hibernate represents one transaction to the database so you need not to commit operations explicitly(remove your extra useless lines of code :) ).

Second-Level Cache

Second-level cache keeps loaded objects at the Session Factory level across transaction boundaries. The objects in the second-level cache are available to the whole application, not just to the user running the query. This way, each time a query returns an object that is already loaded in the cache, transactions potentially gets avoided
The application may need to empty (invalidate) the cache from time to time if the database is updated or modified in some way, because it has no way of knowing whether the cache is up to date, again that can be configured with different strategies of second level caching.

Read-only
Read/write
Non-strict read/write
Transactional

Read-Only Cache

Useful for data that is read frequently but never updated.
Simplest and best-performing cache strategy.

Read/write Cache

Appropriate if your data needs to be updated.
They carry more overhead than read-only caches

Non-strict Read/write Cache

Does not guarantee that two transactions won't simultaneously modify the same data.
Therefore, it may be most appropriate for data that is read often but only occasionally modified

Transactional Cache

A fully transactional cache that may be used only in a JTA environment

Query Cache

Query result sets may also be cached. This is only useful for queries that are run frequently with the same parameters. Use it when you need to cache actual query results, rather than just persistent objects.

Fetching Strategy

Join Fetching

Hibernate retrieves the associated instance or collection in the same SELECT, using an OUTER JOIN.

Select Select Fetching

A second SELECT is used to retrieve the associated entity or collection. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.

Sub-select Fetching

A second SELECT is used to retrieve the associated collections for all entities retrieved in a previous query or fetch. Unless you explicitly disable lazy fetching by specifying lazy="false", this second select will only be executed when you actually access the association.

Batch Bach

An optimization strategy for select fetching ‐ Hibernate retrieves a batch of entity instances or collections in a single SELECT, by specifying a list of primary keys or foreign keys

Performance Monitoring

To improve application performance, you will need to first monitor it.
Hibernate provides a full range of figures about its internal operations. Statistics in Hibernate are available per SessionFactory. Don't forget to use these APIs before making any changes to your application for improving its performance to know the bottleneck.

Summary

Check if really hibernate needed for particular or it can be better done with SQL.
Decide appropriate fetch strategy for your tasks
Overuse of cache can be dangerous, use appropriate cache strategy where needed.

Performance Optimization of Hibernate Application