Performance Optimization Summary: a task frequently operates databases and sends a large number of messages. Long time!
0. Socket exception. Errors occur when a large amount of data is transmitted in RMI calls, and the system processes data is getting slower and slower. After testing, we found that the default maximum memory is only 64 MB, and-xmx increased the memory.
1. hibernateProblem 1: The data is successfully saved after the first modification, and the second modification is not saved.After tracking hibernate, we found that flush thought that the data did not change after the second modification. The stored objects in the tables have a map attribute, which is defined as user type and mapped to string. because it is a pojo, Hibernate obtains the list of all attributes when determining whether the object has changed. This map is a reference, which is used before and after comparison and cannot be seen. If you use a new map, it will be okay, but re-constructing the map will consume a lot. simply use the serialized string as the attribute, and the original map as @ transient.
Problem 2: after the change, the performance is still not high. From the log perspective, the read object will be flushed to the database without any modification. Then we track and find that the object will also change map string without any modification. After careful tracking, we find that the original hash map is unordered. Therefore, after conversion, the string is different, causing a low-level error. The performance test tool found that the new map to string attribute was frequently called, which was time-consuming. Solution: Convert the map to lazy. The map is converted and cached after the conversion. Problem 3: Read the database frequently. Some queries are also made many times and should be cached. Query. setcacheable (true); if this parameter is set to "no effect", we track and find that hibernate. cache. use_query_cache is not set to "true ". Question 4: Add database transactions and set read cache for mo.
2. JMS It is found that JMS messages frequently generate threads to send messages. After a JMS transaction is added to a task, messages are sent once after the task is completed. Activemq provides its own connection pool. 3. InefficientCode: Many methods are simple, but it takes a lot of time after tens of thousands or even hundreds of thousands of calls. Do not split unnecessary. Some of them can be solved simply by substring. You can consider the stringutils. Split (string, char) of Apache. results can be cached for frequent split. Some objects are destined not to be repeated. The equals () method directly compares the references. Complex and uncommon objects can be lazy init 4. A large number of messages cause no response to the interface After receiving a large number of messages, the swing thread is blocked by a large number of swingutilities. invokelater queues, and user events do not respond. Using invokeandwait () is considered, and the efficiency is not high. Then, after receiving dozens of messages, the system actively calls the empty invokeandwait () to ensure that the screen does not die. Test the response speed of a third-party API and find some improvements.
5. javax. JMS. jmsexception: Start failed: no buffer space available (maximum connections reached ?) : Recv failed It seems that the connection is insufficient and some networks are closed.ProgramLater, it will be better. I suspect that the firewall and SP2 connection restrictions (it seems useless after crack) Others: AlgorithmOptimization, do not send useless messages, reduce unnecessary database access, try to read data in batches at a time.
The optimized running time is reduced from the minute level to the second level, which is satisfactory.