Accelerate your hibernate engine (top)

1. Introduction

Hibernate is one of the most popular Object relational mapping (ORM) engines that provide data persistence and query services.

It's easy to introduce hibernate into your project and make it run. But it takes a lot of time and experience to make it run well.

With some examples from our energy projects using Hibernate 3.3.1 and Oracle 9i, this article covers a number of hibernate tuning techniques. It also provides some knowledge of the database necessary to master the Hibernate tuning technology.

We assume that the reader has a basic understanding of hibernate. If a tuning method is described in detail in the Hibernate reference document (hereinafter referred to as HRD) or other tuning articles, we provide only a reference to the document and make a brief description of it from different angles. We focus on tuning methods that are effective but lack documentation.

2.Hibernate Performance Tuning

Tuning is an iterative, ongoing process that involves all phases of the software development Lifecycle (SDLC). In a typical Java EE application that uses hibernate for persistence, tuning involves the following:

Business Rule Tuning

Design Tuning

Hibernate tuning

Java GC Tuning

Application Container Tuning

The underlying system is tuned to include both the database and the OS.

It is time-consuming and likely to have little effect without a well-designed plan to do the above tuning. An important part of a good tuning method is to prioritize the content of the tuning. This can be explained by the Pareto Law (also known as the "80/20 rule"), which means that typically 80% of application performance improvements originate from the performance problem of the first 20% ^[5].

Memory-and CPU-based access provides lower latency and higher throughput than disk-based and network-based access. This hibernate tuning based on Io and the IO portion of the underlying system should take precedence over tuning of the GC, CPU, and memory portions of the underlying system based on CPU and memory.

Example 1

We tuned a HQL query to select the current, dropping it from 30 seconds to less than 1 seconds. If we work on garbage collection, there may be little effect--perhaps only a few milliseconds or at most a few seconds--and improvements in GC are negligible compared to hql improvements.

Another important part of a good tuning method is deciding when to optimize ^[4].

Advocates of positive optimization advocate for tuning at the outset, for example, at the business rules and design stages, and continue to optimize throughout the SDLC, because they believe that late changes to business rules and redesign costs too much.

Others advocate tuning at the end of the SDLC because they complain that upfront tuning often complicates design and coding. They often cite Donald Knuth's dictum that "premature optimization is the root of all evils" ^[6].

Balancing tuning and coding requires some trade-offs. According to the author's experience, appropriate upfront tuning can lead to smarter design and careful coding. Many projects fail on application tuning because the "premature optimization" phase mentioned above is disconnected from the context when referenced, and the corresponding tuning is either delayed too late or too little to devote resources.

However, it is not possible to do many upfront tuning, because without profiling, you are not sure where the bottleneck of the application is, and the application generally evolves like this.

The analysis of our multithreaded enterprise applications also shows that most applications have an average of only 20-50% CPU usage. The remaining CPU overhead is just waiting for database and network-related IO.

Based on the above analysis, we conclude that combining the business rules and the design of the hibernate tuning in the 20% part of the Pareto law, their corresponding priority is higher.

A more practical approach is to:

Identify the main bottlenecks, and expect most of them to be hibernate, business rules, and design (the number depends on your tuning goals; But three to five is a good start).

Modify the application to eliminate these bottlenecks.

Test the application, and then repeat step 1 until you reach your tuning goal.

You can find more common advice on performance tuning stages in Jack Shirazi's Java performance tuning^[7] book.

In the following sections, we will explain some of the specific tuning techniques in the approximate order of tuning (the most frequently affected in the previous column).