In general, the main considerations for HIBERNATE performance tuning are as follows:
* database design adjustment
* HQL optimization
* the correct use of API (such as selecting different collection and query APIs according to different business types)
* Main configuration parameters (log, query cache, fetch_size, batch_size, etc.). )
* Map file optimization (ID generation strategy, secondary cache, delayed loading, association optimization)
* Level 1 cache management
* L2 cache has many unique strategies.
* transaction control strategy.
1, database design
A) reduce the complexity of association
B) Try not to use federated primary keys.
C) ID generation mechanism. Different databases provide different mechanisms.
D) Redundant data appropriately, and do not excessively pursue high paradigm.
2.HQL optimization
If HQL abandons the association with some caching mechanisms of HIBERNATE itself, then its optimization skills are the same as ordinary SQL, and it is easy to find some experience on the Internet.
3, the main configuration
A) Query cache, different from the cache mentioned below, is the cache of HQL statements, that is, the cached data can be used when the same statement is executed again. However, in a trading system, the query cache may be counterproductive (the data changes frequently, and the probability of the same query conditions is small): it will consume a lot of system resources in vain, but it is difficult to come in handy.
B) fetch_size, similar to JDBC parameter, the parameter is not as big as possible, but should be set according to business characteristics.
C) batch_size is the same as above.
D) In the production system, remember to close the printing of SQL statements.
4. Hidden objects
A) Database-level cache: This level of cache is the most efficient and secure, but different databases can manage different levels. For example, in ORACLE, you can specify that the entire table is placed in the cache when it is created.
B) SESSION cache: It is effective in HIBERNATE sessions. This level of cache is not intrusive, and it is mostly managed automatically by HIBERNATE, but it provides a method to clear the cache and is effective in a large number of add/update operations. For example, if you add100,000 records at the same time and follow the normal way, you are likely to find an OutofMemeroy exception. At this point, you may need to manually clear this level of cache: Session.evict and Session.clear
C) Application cache: It is effective in SESSIONFACTORY, so it is also the top priority of optimization. So we also considered various strategies. Before putting data into this level of cache, there are some prerequisites to consider:
I data will not be modified by a third party (for example, is there another application that is also modifying data? )
Two. The data won't be too big.
Three. Data will not be updated frequently (otherwise using cache may be counterproductive).
Four. Data will be frequently queried.
Verb (abbreviation of verb) data is not critical data (for example, it involves money, security and other issues. ).
There are several forms of cache, which can be configured in the mapping file: read-only (suitable for static data/historical data with little change), non-strict reading and non-strict reading and writing (a common form with average efficiency), and transactional (JTA, which supports less cache products).
D) Distributed Cache: It is the same as the configuration in c), but the choice of cache products is different. Currently, there are not many choices in HIBERNATE. At present, most projects, such as Oscar Oscar oscache and jboss cache, are conservative in their use in clusters, especially in key trading systems. In a cluster environment, it is safest to use only database-level cache.
5. Delayed loading
A) Delayed loading of entities: realized by using dynamic proxy.
B) collection delayed loading: HIBERNATE provides this support by implementing its own collection/list.
C) delayed loading attribute:
6. Method selection
A) In order to accomplish the same thing, HIBERNATE provides some ways to choose from, but the specific way to use it may have an impact on performance/code. Display a return of100000 records (list/set/package/graph, etc. ) is likely to lead to the problem of insufficient memory, but if you use result sets based on cursors or iterators, this problem does not exist.
B) load/get method of the session, the former will use L2 cache, while the latter will not.
C) Queries and lists/iterators. If you study them carefully, you may find many interesting things. The main differences between them are (if Spring is used, the find find and iterator methods are corresponding in HibernateTemplate):
I. list can only use the query cache (but the query cache has little effect in the trading system), and cannot use a single entity in the secondary cache. However, the objects found in the list will be written into the secondary cache, but it usually generates only a few SQL statements, and in many cases it is only one (irrelevant).
Two. Iterators can use second-level caching. For a query statement, it will first find out the ID of all qualified records from the database, and then cache them by ID. For records that are not in the cache, it will construct a statement to find out from the database. So it is easy to know that if there are no qualified records in the cache, using iterator will produce N+ 1 SQL statements (n is the number of qualified records).
Three. With the help of iterator and cache management API, memory problems in massive data query can be well solved, such as:
while(it.hasNext()){
YouObject object =(YouObject)it . next()；
session . evict(you object)；
session factory . evice(you object . class，you object . getid())；
}
If you use the list method, you may get an OutofMemory error.
From the above explanation, I think you should know how to use these two methods.
7. Selection of sets
It is explained in detail in "19.5". Understand the collection performance of HIBERNATE 3. 1 document.
8. Transaction control
Transaction has an impact on performance, including the choice of transaction mode, transaction isolation level and lock.
A) Choice of transaction mode: If multiple transaction managers are not involved, JTA is not needed, only JDBC transaction control is enough.
B) Transaction isolation level: refer to the standard SQL transaction isolation level.
C) Lock selection: pessimistic locks (generally implemented by a specific transaction manager) are inefficient, but safe for long transactions. Optimistic locking (usually implemented at the application level), such as version fields can be defined in HIBERNATE. Obviously, if there are multiple applications that manipulate data, and these applications do not use the same optimistic locking mechanism, optimistic locking will fail. So different data should have different strategies. Like many previous cases, we often find a balance between efficiency and safety/accuracy. In any case, optimization is not a purely technical issue, and you should have a good understanding of your application and business characteristics.
9, batch operation
Even if JDBC is used, the efficiency of batch processing and non-batch processing is very different when updating a large amount of data. We can support batch operation by setting batch_size.
For example, if you want to delete objects in a table in batches, such as "delete accounts", you will find that HIBERNATE finds out the ID of all accounts and then deletes them. This is mainly to maintain the secondary cache, so the efficiency is definitely not high. Batch deletion/update has been added in subsequent versions, but this cannot solve the problem of cache maintenance. In other words, due to the maintenance problem of secondary cache, the batch operation efficiency of HIBERNATE is not satisfactory!