1. Paging solution, versatility, and parameter loss during paging. How can this problem be solved?
2. hibernate optimization problems. How to optimize database access by programs.
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)
* Main configuration parameters (log, query cache, fetch_size, batch_size, etc)
* Ing file optimization (ID generation policy, secondary 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!
3. The website is dynamic and requires frequent access to the database. How can we increase the access speed and reduce the server pressure?
Provides JDBC database connection pool sharing, greatly reducing database pressure;
Intelligent Dynamic HTML greatly reduces network data traffic;
Massive Data optimization greatly improves logon and access speeds;
User interface and data cache, greatly improving the login speed;
Multi-level architecture, supporting multiple application servers in parallel, greatly improving system scalability, concurrent access to the number of users and data security
4. How to Improve the ranking of websites by using search engine optimization. What are the specific technical measures for optimization?
Precautions for optimizing search engines in website structure design include:
1) Importance of link reference
A. Winning by quantity: Not necessarily adding to the classification directories of traditional portal websites is website promotion. Any reverse link from other websites is useful.
B. Winning by quality: being referenced by websites with high PageRank can improve PageRank faster
C. learn about the search engine's "values": Do not use link farm to improve your site ranking: Google will punish those sites that actively link to link farm to improve their ranking, the page of the corresponding site will not be indexed. But if your page is linked by another link farm, you don't have to worry about it, because this passive link will not be punished.
D. do not mean to give links to other websites: If a webpage only has a large number of access links and lacks export links, it will also be considered as a site of no value by the search engine.
2) How to highlight keywords: Design of webpage titles and themes
A. The theme engine is gradually exceeding <SP>