hibernate-common-performance-problems-in-logs

The first performance issue is extremely easy to spot and often ignored.
It’s the logging of SQL statements in a production environment.

Writing some log statements doesn’t sound like a big deal, and there are
a lot of applications out there which do exactly that. But it is
extremely inefficient, especially via System.out.println as Hibernate
does it if you set the show_sql parameter in your Hibernate
configuration to true:

In one of my projects, I improved the performance by 20% within a few
minutes by setting show_sql to false. That’s the kind of achievement
you like to report in the next stand-up meeting ?

It’s pretty obvious how you can fix this performance issue. Just open
your configuration (e.g. your persistence.xml file) and set the
show_sql parameter to false. You don’t need this information in
production anyways.

But you might need them during development. If you don’t, you use 2
different Hibernate configurations (which you shouldn’t) you deactivated
the SQL statement logging there as well. The solution for that is to use
2 different log
configurations for development and production which are optimized for
the specific requirements of the runtime environment.

Development Configuration

The development configuration should provide as many useful information
as possible so that you can see how Hibernate interacts with the
database. You should therefore at least log the generated SQL statements
in your development configuration. You can do this by activating DEBUG
message for the org.hibernate.SQL category. If you also want to see
the values of your bind parameters, you have to set the log level of
org.hibernate.type.descriptor.sql to TRACE:

The following code snippet shows some example log messages which
Hibernate writes with this log configuration. As you can see, you get
detailed information about the executed SQL query and all set and
retrieved parameter values:

Hibernate provides you with a lot more internal information about a
Session if you activate the Hibernate statistics. You can do this by
setting the system property hibernate.generate_statistics to true.

But please, only activate the statistics on your development or test
environment. Collecting all these information slows down your
application and you might create your performance problems yourself if
you activate it this in production.

You can see some example statistics in the following code snippet:

I regularly use these statistics in my daily work to
find
performance issues before they occur in production and I could write
several posts just about that. So let’s just focus on the most important
ones.

The lines 2 to 5 show you how many JDBC connections and statements
Hibernate used during this session and how much time it spent on it. You
should always have a look at these values and compare them with your
expectations.

If there are a lot more statements than you expected, you most likely
have the
most
common performance problem, the n+1 select issue. You can find it in
nearly all applications, and it might create huge performance issues on
a bigger database. I explain this issue in more details in the next
section.

The lines 7 to 9 show how Hibernate interacted with the 2nd level cache.
This is one of
Hibernate’s
3 caches, and it stores entities in a session independent way. If you
use the 2nd level in your application, you should always monitor these
statistics to see if Hibernate gets the entities from there.

Production Configuration

The production configuration should be optimized for performance and
avoid any messages that are not urgently required. In general, that
means that you should only log error messages. If you use Log4j, you can
achieve that with the following configuration:

If you use Log4j, you can achieve that with the following configuration:

As I already explained, the n+1 select issue is the most common
performance problem. A lot of developers blame the OR-Mapping concept
for this issue, and they’re not completely wrong. But you can easily
avoid it if you understand how Hibernate treats lazily fetched
relationships. The developer is, therefore, to blame as well because
it’s his responsibility to avoid these kinds of issues. So let me
explain first why this issue exists and then show you an easy way to
prevent it. If you are already familiar with the n+1 select issues, you
can jump directly to the solution.

Hibernate provides a very convenient mapping for relationships between
entities. You just need an attribute with the type of the related entity
and a few annotations to define it:

When you now load an Order entity from the database, you just need to
call the getItems() method to get all items of this order. Hibernate
hides the required database queries to get the related OrderItem
entities from the database.

When you started with Hibernate, you probably learned that you should
use FetchType.LAZY for most of the relationships and that it’s the
default for to-many relationships. This tells Hibernate to only fetch
the related entities if you use the attribute which maps the
relationship. Fetching only the data you need is a good thing in
general, but it also requires Hibernate to execute an additional query
to initialize each relationship. This can result in a huge number of
queries, if you work on a list of entities, like I do in the following
code snippet:

You probably wouldn’t expect that this few lines of code can create
hundreds or even thousands of database queries. But it does if you use
FetchType.LAZY for the relationship to the OrderItem entity:

Hibernate performs one query to get all Order entities and an
additional one for each of the n Order entities to initialize the
orderItem relationship. So you now know why this kind of issue is
called n+1 select issue and why it can create huge performance problems.

What makes it even worse is, that you often don’t recognize it on a
small test database, if you haven’t checked your Hibernate statistics.
The code snippet requires only a few dozen queries if the test database
doesn’t contain a lot of orders. But that will be completely different
if you use your productive database which contains several thousand of
them.

I said earlier that you can easily avoid these issues. And that’s true.
You just have to initialize the orderItem relationship when you select
the Order entities from the database.

But please, only do that, if you use the relationship in your business
code and don’t use FetchType.EAGER to always fetch the related
entities. That just replaces your n+1 issue with another performance
problem.

Initialize a Relationships with a @NamedEntityGraph

There are several different
options
to initialize relationships. I prefer to use a @NamedEntityGraph
which is is one of my favorite
features
introduced in JPA 2.1. It provides a query independent way to specify a
graph of entities which Hibernate shall fetch from the database. In
following code snippet, you can see an example of a simple graph that
lets Hibernate eagerly fetch the items attribute of an entity:

There isn’t much you need to do to define an entity graph with a
@NamedEntityGraph annotation. You just have to provide a unique name
for the graph and one @NamedAttributeNode annotation for each
attribute Hibernate shall fetch eagerly. In this example, it’s only the
items attribute which maps the relationship between an Order and
several OrderItem entities.

Now you can use the entity graph to control the fetching behaviour or a
specific query. You, therefore, have to instantiate an EntityGraph
based on the @NamedEntityGraph definition and provide it as a hint to
the EntityManager.find() method or your query. I do this in the
following code snippet where I select the Order entity with id 1 from
the database:

Hibernate uses this information to create one SQL statement which gets
the attributes of the Order entity and the attributes of the entity
graph from the database:

Initializing only one relationship is good enough for a blog post but in
a real project, you will most likely want to build more complex graphs.
So let’s do that.
You can, of course, provide an array of @NamedAttributeNode
annotations to fetch multiple attributes of the same entity and you can
use @NamedSubGraph to define the fetching behaviour for an additional
level of entities. I use that in the following code snippet to fetch not
only all related OrderItem entities but also the Product entity for
each OrderItem:

As you can see, the definition of a @NamedSubGraph is very similar to
the definition of a @NamedEntityGraph. You can then reference this
subgraph in a @NamedAttributeNode annotation to define the fetching
behaviour for this specific attribute.

The combination of these annotations allows you to define complex entity
graphs which you can use to initialize all relationships you use in your
use case and avoid n+1 select issues. If you want to
specify
your entity graph dynamically at runtime, you can do this also via a
Java API.

Updating entities one by one feels very natural if you think in an
object oriented way. You just get the entities you want to update and
call a few setter methods to change their attributes like you do it with
any other object.

This approach works fine if you only change a few entities. But it gets
very inefficient when you work with a list of entities and is the third
performance issues you can easily spot in your log file. You just have
to look for a bunch SQL UPDATE statements that look completely the same,
as you can see in the following log file:

The relational representation of the database records is a much better
fit for these use cases than the object oriented one. With SQL, you
could just write one SQL statement that updates all the records you want
to change.

You can do the same with Hibernate if you use JPQL,
native
SQL or the
CriteriaUpdate
API. All 3 of very similar, so let’s use JPQL in this example.

You can define a JPQL UPDATE statement in a similar way as you know it
from SQL. You just define which entity you want to update, how to change
the values of its attributes and limit the affected entities in the
WHERE statement.
You can see an example of it in the following code snippet where I
increase the price of all products by 10%:

Hibernate creates an SQL UPDATE statement based on the JPQL statement
and sends it to the database which performs the update operation.

It’s pretty obvious that this approach is a lot faster if you have to
update a huge number entities. But it also has a drawback. Hibernate
doesn’t know which entities are affected by the update operation and
doesn’t update its 1st level cache. You should, therefore, make sure not
to read and update an entity with a JPQL statement within the same
Hibernate Session or you have to detach it to remove it from the cache.