In practical applications, the impact of large data volumes on the system itself is a problem that must be faced.
When Jbuilder was first used, it had a supporting tool named Optimize Suite, which can be used in JBuilder or independently, it can be used to monitor the running concurrent thread data and memory usage, and is not a very good performance test suite. Unfortunately, with the decline of JBuilder, it gradually disappears into people's sight. I remember another independent performance testing tool called JProfiler. It can be seen from its name that it was used to do the same thing. At that time, it seemed to be a well-received tool.
Since the rise of Eclipse, plug-ins have become increasingly popular. I also like this "pay-as-you-go allocation" mode and add plug-ins as needed. Previously, I was not very conscious of performance, but I paid more and more attention to the last lesson. People always have some lessons before they become effective :)
The first thought was to find it from the Eclipse official website, which did not disappoint me. ECLIPSE officially has a Test & Performance Tools Platform (TPTP) project, which has been available for a long time, but has never been noticed before. The latest stable version is 4.3.1. It can be used for statistical analysis of program Execution time, memory monitoring, object call analysis, etc. What I pay attention to now is Execution Statistics (program Execution Statistics ), it can be shown that the 10 most overhead methods in the program are bottlenecks of the system. Once we find the bottleneck, we can try our best to solve it, or optimize or rewrite it to suit the right of the problem.
In fact, the use of TPTP is very simple, but when downloading and using the TPTP plug-in, you must pay attention to the cooperation between the TPTP plug-in version and the ECLIPSE version, otherwise, it is likely that I will not be able to run normally after several attempts. The following describes the Installation and Use steps:
1. Download TPTP4.3.1 from the ECLIPSE official website, and the corresponding ECLIPSE version is 3.2.2, as shown in Figure 1:
Figure 1
2. After the installation is complete, restart ECLIPSE. If necessary, add the parameter-clean for cleanup. If the installation is normal, the shortcut icon of TPTP is displayed in the standard button column, as shown in Figure 2:
Figure 2
3. Select the main class of the Project for performance testing. Right-click the main class and choose Profile as from the menu. Then select java application. Of course, if your project is not a JAVA application, but a web program, you also need to install the corresponding web plug-in WTP, select Profile on serve, as shown in Figure 3:
Figure 3
4. A window for selecting a monitoring project is displayed. The default monitoring project has three: Memory analysis (basic memory analysis) and executeion Time Analysis (executeion time analysis) method code coverage, as shown in Figure 4:
Figure 4
5. Click "OK" to start running the program, and monitoring will also begin. eclipse will switch the monitoring view, as shown in Figure 5:
Figure 5
6. Double-click the monitoring project to view the specific monitoring results, as shown in Figure 6:
Figure 6
7. from the monitoring results above, we can clearly understand the current method with the largest sales volume in the system. The strange thing is that this method does not seem very special at ordinary times. How can it cause such a huge overhead? After careful analysis of the code, we can determine whether the sender is a mobile number or a Unicom number before and after processing the data, when judging the number, quan2ban (String str) is called to convert the full-width String to the half-width ). Oh, that's it. Although full-angle numbers are taken into account during full-to-half conversion, this possibility is almost invisible in the actual system running process. Therefore, the quan2ban () method can be removed, greatly reducing the overhead. The same is true for the isAllChinese () method. The code is adjusted and tested again, as shown in figure 7:
Figure 7
8. Although great improvements have been made, the two methods seem to have been called many times. What are the problems? Further analysis of method calls shows that the two methods are used when the program initializes the dictionary library, but initialization does not affect the normal data processing of the system, you can first block the initialization process and test again. The result is shown in Figure 8:
Figure 8
9. It is strange that the biggest overhead is the constructor of four classes. The constructor does not execute any operations. How can it have such a large overhead? Besides, I have just tested the creation of objects, but it does not cost much. After careful research, I found that I used the LOG4J utility for log output, and in order to make log output work in my custom mode, when each class is created, I call the following sentence: PropertyConfigurator. configure (ConfParam. LOG4J_PROP_CONF); is it the reason for loading configuration parameters? Block this sentence and eliminate the problem. One by one, the analysis and optimization of relatively large sales methods has greatly improved the processing capability of the system.
In TPTP learning and usage, I mainly use the execution time analysis monitoring function, because the main problems of my system occur in the execution efficiency. If it is a problem of memory overhead, you can focus on memory analysis. Of course, TPTP has other powerful functions that need further study and research.
Tip: When you use TPTP for performance testing, the system startup time and running time may be much longer than the normal running time. I used to complete the initialization process in 1 minute normally, after TPTP is enabled, it can be up to 10 minutes and dizzy...