Hibernate Program Performance Optimization

This article is based on the hibernate help documentation, some online books and project experience, and provides only the key points and ideas. You can leave a message to discuss the specific practices, or find more detailed and targeted information.
People who use hibernate may have encountered performance problems and implemented the same function. It is normal that the performance difference between Hibernate and JDBC is more than 10 times. If it is not adjusted as soon as possible, it may affect the progress of the entire project.
In general, the main considerations for hibernate performance tuning are as follows:

• Database Design Adjustment
• Hql Optimization
• Correct use of APIS (for example, selecting different sets and querying APIs based on different service types)
• Master configuration parameters (log, query cache, fetch_size, batch_size, etc)
• Optimization of ing files (ID Generation Policy, second-level cache, delayed loading, and association optimization)
• Level 1 Cache Management
• There are also many unique policies for level-2 caching.
• Transaction control policy.

1. Database Design

A) reduce the complexity of Association

B) Try not to use the federated primary key
C) ID generation mechanism. Different databases provide different mechanisms.
D) Appropriate redundant data, but the pursuit of high paradigm
2. hql Optimization
Aside from its association with some caching mechanisms of hibernate, hql's optimization skills are the same as common SQL optimization skills, so it is easy to find some experience on the Internet.
3. Master Configuration
A) query cache, which is different from the cache described below. It is a cache for hql statements, that is, cache data can be used for re-execution of identical statements. However, the query cache in a transaction system (data changes frequently and the probability of the same query conditions is not large) may be counterproductive: it will consume a lot of system resources in vain, but it is difficult to come in handy.
B) fetch_size, which is similar to JDBC-related parameters. The larger the parameter is, the better. You should set it according to business characteristics.
C) Same as batch_size.
D) In the production system, remember to turn off SQL statement printing.
4. Cache
A) database-level cache: this level of cache is the most efficient and secure, but different database management levels are not the same. For example, in Oracle, you can specify to cache the entire table during table creation.
B) session cache: the cache is valid in a hibernate session. This level of cache is not reliable and is more efficient than hibernate's automatic management. However, it provides a method to clear the cache, this is effective in bulk Add/update operations. For example, if you add 100,000 records at the same time, you may find an outofmemeroy exception. In this case, you may need to manually clear the cache: Session. evict and session. Clear.
C) Application cache: it is effective in a sessionfactory, so it is also the top priority of optimization. Therefore, there are many policies to consider. Before putting data into this cache level, consider the following prerequisites:
I. data will not be modified by a third party (for example, is there another application that is also modifying the data ?)
II. The data is not too big
Iii. data will not be updated frequently (otherwise, using the cache may be counterproductive)
Iv. Data is frequently queried.
V. Data is not key data (such as money and security issues ).
The cache can be configured in several formats in the ing file: Read-Only (read-only, applicable to static/historical data with few changes), nonstrict-read-write, read-write (common format with average efficiency), transactional (in JTA, few caching products are supported)
D) distributed cache: the configuration is the same as that of C), but the selection of cache products is different. Currently, there are not many options available in hibernate, such as Oscache and JBoss cache. Most of the current projects, they are conservative in using clusters (especially key transaction systems. In a cluster environment, database-level cache is the safest.
5. Delayed Loading
A) object delayed loading: implemented through dynamic proxy
B) Set delayed loading: hibernate provides support for this by implementing its own set/list.
C) Delayed attribute loading:
6. Method Selection
A) to do the same thing, Hibernate provides some options, but the specific method may affect performance/code. It is shown that 100,000 records (list/set/bag/MAP) are returned for processing at a time, which may result in insufficient memory. If you use a cursor (scrollableresults) or iterator result set.
B) the load/get method of the session. The former uses the second-level cache, while the latter does not.
C) query and list/iterator. If you study them carefully, you may find many interesting situations. The main differences between the two are: (if spring is used, find in hibernatetemplate, iterator method ):
I. list can only use the query cache (but it does not play a major role in the query cache in the transaction system). It cannot use a single entity in the second-level cache, but the objects identified by list will be written to the second-level cache, however, it generally generates only a small number of SQL statements for execution. In many cases, it is one (unassociated) statement ).
II. iterator can use the second-level cache. For a query statement, it first finds the IDs of all qualified records from the database, and then uses the IDs to cache the query, for records not in the cache, you can easily find them from the database by constructing statements. If no matching record exists in the cache, using iterator will generate n + 1 SQL statement (n is the number of qualified records)
Iii. Use iterator and Cache Management APIs to solve memory problems in massive data queries, such:
While (it. hasnext ()){
Youobject object = (youobject) it. Next ();
Session. evict (youobject );
Sessionfactory. evice (youobject. Class, youobject. GETID ());
}
If the list method is used, the outofmemory error may occur.
Iv. As described above, I think you should know how to use these two methods.
7. Set Selection
Detailed descriptions are provided in "3.1. Understanding collection performance" in hibernate 19.5.
8. Transaction Control
The main impact of transactions on performance includes the selection of transaction methods, transaction isolation levels, and lock selection.
A) transaction method selection: if you do not involve multiple Transaction Manager transactions, you do not need to use JTA. Only JDBC transaction control is supported.
B) transaction isolation level: see standard SQL transaction isolation level.
C) Selection of locks: Pessimistic locks (usually implemented by the specific transaction Manager), low efficiency but secure for long transactions. Optimistic lock (usually implemented at the application level). For example, you can define the version field in hibernate. Obviously, if multiple applications operate on data and these applications do not use the same optimistic lock mechanism, the optimistic lock will become invalid. Therefore, there should be different policies for different data. As in many cases above, we often find a balance between efficiency and security/accuracy, optimization is not a pure technical problem. You should have a sufficient understanding of your applications and business features.
9. batch operation
Even when JDBC is used to update a large amount of data, the efficiency of batch differs greatly from that of no batch. You can set batch_size to support batch operations.
For example, to delete objects in a table in batches, such as the "delete account" Statement, Hibernate finds the IDs of all accounts and then deletes them, this is mainly to maintain the second-level cache, which is definitely not efficient. Bulk delete/update is added in subsequent versions, but it cannot solve the cache maintenance problem. That is to say, Hibernate's batch operation efficiency is not satisfactory due to the maintenance of the second-level cache!
As we can see from the many points above, we often find a balance between efficiency and security/accuracy. In any case, optimization is not a pure technical problem, you should have a sufficient understanding of your applications and business characteristics. In general, the optimization scheme should be basically determined during the architecture design period. Otherwise, unnecessary rework may occur, resulting in project delays, as architects and project managers, we have to face possible complaints from developers. We have little control over changes to user requirements, however, technical/architecture risks should be realized and relevant countermeasures should be developed at the initial stage.
Note that the cache at the application layer is just a icing on the cake. Never take it as a life-saving tool, as well as the foundation of the application (database design, algorithms, efficient operation statements, and appropriate API selection) is the most important.