Improve the interaction capability between the J2EE layer and the database layer

Most applications Program Performance Management (APM) solutions are considered and analyzed only Performance issues at a certain level of J2EE applications. This method is insufficient to solve the performance problems of complicated applications in the architecture. Good APM tools should allow you to go from the J2EE layer to the database layer to ensure that performance problems are quickly solved.

The situation is not getting better and better. The company's website performance fell to a very low point, and the lost customers began to look for other vendors. It research institutions began to investigate and believed that J2EE applications were the culprit in poor response time. This is for J2EE Development The Group puts a lot of pressure and they must determine and solve the problem.

After some initial investigations, the J2EE development team considered that the problem was not at the J2EE layer, but was always traceable to the database. However, the database team retorted that the problem actually exists at the J2EE layer. Mutual blame is constantly increasing, Group Cooperation The spirit disappears, chaos begins to get popular, and customers and revenue continue to decrease.

The above situation highlights a major requirement: to support better interaction between J2EE and the database layer Capability The IT department must be able to make decisions quickly and decisively.

　　Basic challenge: find out the cause of the problem

When the response time delay drive away the Web When users of the site, J2EE developers have to join the blame. Games . The Programmers must interact with the database. When a performance bottleneck occurs, if the database is the underlying cause, the problem is also displayed at the J2EE layer. In fact, the real problem lies in interactive operations. How can we better adjust the comprehensive relationship between the two layers to obtain the best performance of the application? More deeply, how can we view these bottlenecks, identify the real causes of problems, and handle these problems as quickly as possible?

Many APM (Application Performance Management Tools help us identify and solve these performance problems. The two most common methods for finding bottlenecks in J2EE applications are:

1. Use a instrumentation program with different color alarms to monitor the status of the system. Green means good, yellow or red means you have to handle performance issues. This instrumentation program can also report the response time of different components in the system.

2. Instead of waiting for a certain degree of performance deterioration to track the warning information of the meter program, we use a pre-protection method and try to identify excessive response times or resources. . You can check the top layer Service Requests (based on the response time) and further analyze the components they call to perform such operations.

Suppose there is a banking system. A customer who views Account information has visited your web site to obtain the summary of his account over the past seven days. The customer clicked the "get account summary" link.

The process of getting account summary information is completed by calling a specific URL through a web browser. Of course, at the lower layer, it calls many components and these components interact to provide correct output information. In the process of searching for bottlenecks, you start from the top-level call (which may be the doget () or dopost () method, view All group items called by the "get account summary information" service in the call tree, and then view the components called by these components until the bottom layer. In many cases, it may be an SQL statement that uses JDBC (Java database connection) to call the database.

You must know which of these components have taken a long time, but using this method for analysis will take a lot of time and go through a lot of annoying processes, this is especially true when you are not familiar with some of them. You must view each component and ask yourself if it takes too long? Is it necessary to generate output information in 10 seconds to respond to "get account summary? You are not particularly certain, because if you want to know this information, you must know the details of how each method or program component in the lower layer runs. The only person who knows this information may only be a developer of a specific component. If you suspect that the problem lies in the response time of the database, you need Contact The database team further studied this issue. Isolate SQL statements

Assume that it takes too long to retrieve account information. It takes 15 seconds for the user who requests the account summary information to respond. Will the problem occur on the database side? Is it possible that it is a problem with the application code? Network Question? It may even be the user's Is Internet connection too slow?

However, in this case, you should be blamed if you suspect that it is a database retrieval problem. One way to find the cause is to let the APM tool display all the SQL statements issued by the application and sort them according to the response time, in this way, you can see whether an SQL statement takes too long because of an error (some SQL statements take a long time-for example, retrieving the list of all transactions within one year by account ).

Now you can view the SQL statements at the top of the list. It enters the database and takes 1 second to respond. Such performance is not too bad. If this is the worst-performing SQL statement, the problem may not be in the SQL statement at all. Therefore, the following question is: Is it an application? Program What is the problem? Who is calling this statement? How many calls have been made? If an application calls an SQL statement more frequently than expected, you have reason to suspect that the application has failed.

The APM tool can help you again this time. You can simply click this SQL statement and a link will appear, showing its entire call tree starting from the customer request account summary information to the SQL statement that enters the database. Now you have two pieces of information: Service A specific request of a request. You can see the impact of each independent component on the response time.

Now you can view the component description that calls the SQL statement and find that the response time is 9 seconds. Obviously, it is the main factor that causes the customer to wait for 15 seconds. The list displayed by the APM tool also shows that the component has called the SQL statement seven times. This tells you that most of the nine seconds are consumed by calling SQL statements. This component not only executes excessive computation, but also calls SQL statements multiple times. This operation may be for some good reason, but any performance Management Tools cannot describe the cause. 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 .

　　Is it really a database problem?

Let's look at this problem from another perspective. If the component does not call the SQL statement multiple times, it only calls the SQL statement once, but this call consumes most of the 15 seconds. The question is, why does a single statement take so long to execute? This problem is not in the code, so it may be at the database end.

What you need now is a performance management tool that allows you to investigate specific service requests (obtain account summary information) into the database layer. Please return to the SQL statement list you get and click the link of the SQL statement you are interested in. It will take you from the J2EE end to the Database End. Now you are viewing SQL statements in the Oracle Data database or other database product environments. This tool may help you identify database problems and provide professional adjustment suggestions. Database Administrators (DBAs) can use these suggestions to improve database performance. The problem may be that the disk that stores the data table space has poor performance. We recommend that you move it to another disk. Or, you may lose an index. You can increase the speed by creating a new cable; maybe the database runs too many threads in parallel. You must isolate these threads to reduce concurrency issues.

There are other possibilities. Data Retrieval may take too much time because it takes a long time to obtain database connections. The code is good and the database runs normally. However, such a wait time may tell you that the database connection pool is not large enough to handle a large amount of or even normal communication. You can query the application server, learn how many connections have been defined, compare the number with the typical number of concurrent requests, and quickly determine whether more connections are needed.

　　Improve Interactive Operation Capability

Your performance management tool not only needs to identify the composition of the response time of the J2EE layer. It should also let you see the interaction between the J2EE layer and the adjacent database layer, and provide a way to analyze the performance problems at these two levels. To efficiently handle performance issues, it is necessary for J2EE developers and DBAs to use a comprehensive APM product. It also allows J2EE and database groups to use the same Language Speak ". Most APM solutions target a single level in the architecture system, providing diagnostic information for a single level. When using this method, time will be wasted, mutual blame will form a storm, and the problem is often not solved. Today's complex architecture and sophisticated Technology This means that performance problems caused by interactions between a layer and other layers cannot be located. The most popular APM tools that we can use now allow us to track from the J2EE layer to the database layer to ensure timely resolution of performance issues, regardless of the level from which the problem comes.

　　Conclusion

Improving the interaction between the J2EE layer and the database layer brings obvious advantages: accelerating the response time of end users, increasing customer loyalty, increasing morale, and improving the bottom line of services. Now we can use advanced tools to fill in the gaps between the J2EE layer and the database layer, automatically search for bottlenecks, identify the cause, and provide specific suggestions for solving the problem. Each J2EE Development The team should seriously consider these integrated AP
The value of M tools for their production

Note: The above content comes from the Internet and I am not liable for any joint liability.

Article transferred from: http://se.csai.cn/media/200803111629011638.htm