Overview: Most Application Performance Management (APM) solutions only consider and analyze a level of performance issues for J2EE applications. This method is not enough to solve the performance problem of architectural complex applications. Good APM tools should be able to let you go deep into the database layer from the J2EE layer to ensure that performance issues are quickly resolved. The situation is not getting better and better, the company's website performance drops to very low, lost customers began to find other manufacturers. IT survey institutions have begun survey and believes that J2EE applications are chi-chi-chi-chi-chi-child. This immediately brings great pressure to the J2EE development team, they must determine and solve this problem. J2EE Development Team After conducting some initial surveys, they believe that the problem is not in the J2EE layer, but can always track into the database. But the database team refutes that the problem is actually in the J2EE layer. The incidence between each other is increasing, and the team's spirit disappears, and the confusion begins to popularize, customers and revenue continue to decrease. The above situation highlights a major demand: in order to support better interaction ability between J2EE and database layers, IT departments must be able to make decisions quickly and decisively. Basic Challenge: Finding the cause of the problem When the response time is launched away from the user of the Web site, J2EE developers have to join this mutual blame. The programmer in the intermediate layer development application must interact with the database. When the performance bottleneck occurs, if the database is the cause of the lower layer, the problem is also shown in the J2EE layer. In fact, the real problem is interacting. How to best adjust the integrated relationship between these two hierarchies to obtain the best performance of the application? A more deeper, how to view these bottlenecks, identify the true problem caused, and deal with these problems as quickly as possible? Many APMs (Application Performance Management) tools can assist us identify and resolve these performance issues. Find the most commonly used methods of the bottleneck in the J2EE application is: 1. Use the instrument programs with different color alarms to monitor the status of the system. Green means good, yellow or red means you have to handle performance problems. This instrument program can also report the response time of different components in the system. 2, not waiting for the performance to deteriorate to a certain extent to track the warning information of the instrument program, but use pre-protection methods and attempt to identify excessive response time or resource usage. You can implement such an operation by checking the top-level service request (according to the response time) and further analyzes what components they call. Assume that there is a bank system. A customer who views account information visits your web site to get outline information for your own account in the past seven days. This customer clicks on the "Get Account Profile" link. The process of obtaining an account profile is done by calling a particular URL through a web browser. Of course, in the next layer, it calls a lot of components that interacts to provide the correct output information. In the process of finding the bottleneck, you start from the top of the top, and you can follow all the components called by the Call Tree View "Get Account Summary Information" service calls, then view these components called Components, until the bottom, in a lot of cases, it may be the SQL statement to call the database using the JDBC (Java Database Connection). You must know which of these components spend too long, but it takes a lot of time when using this way, it takes a lot of troubles, and it is especially true that you are not too familiar with you in your individual characters. You must check each component and ask yourself how much it takes? Is it necessary to generate output information for 10 seconds to respond to "Get Account Summary Information"? You are not particularly sure, because if you need to understand this information, you must know how each method or program component is running for details. The only person who knows this information is probably only a developer of a particular component.
If you suspect that the problem is in the response time of the database, then you need to contact the Database Team to further study this issue. Isolation SQL statement assumes that the search account information takes too long. Users who request account summary information will wait for 15 seconds to respond. So will the problem will be in the database? Is there a problem with application code? Network problem? Even if the user's internet connection is too slow? However, in this case you suspect that the problem with database retrieval should be blamed. One way to find the cause is to let the APM tool displays all SQL statements issued by the application, sort by the response time so that you can see if a SQL statement spends too long because of an error (some SQL statements will cost For a long time - such as a list of all transactions within one year by account. Now you see the SQL statement at the top of the list. It enters the database and spends a 1 second response. Such performance is not too bad; if this is the worstable SQL statement of performance, then the problem may not be in the SQL statement at all. Therefore, the next question is: Is it what the application is missing? Who is calling this statement? How many times call? If an application calls the SQL statement exceeding your expectations, you have reason to suspect that the application has failed. The APM tool can help you this time. You can simply click on the SQL statement, there will be a link, showing its entire call tree, starting from the customer request account profile, until the SQL statement enters the database. Now you have two parties: You can definitely check a particular request for the service request; you can see the influence of each independent component on the response time. Now you can view the component description of the call to the SQL statement, and you find that its response time is 9 seconds. Obviously, it is the main factor that causing the customer to wait for 15 seconds. The list of APM tools displayed simultaneously shows the SQL statement 7 calls. This tells you that most of the 9 seconds is to call the SQL statement consumption. The component not only has executed excessive calculations, but also calls the SQL statement multiple times. Such operations may have some good reasons, but any performance management tools cannot illustrate their causes. The most important thing is that you have pointed out the program components that must be investigated. Good APM tools can also provide some suggestions to resolve this issue.
