Maximizing the performance of Java EE and database interaction operations

Overview: Most application performance management (APM) solutions only consider and analyze performance issues at one level of the Java application. This approach is not sufficient to address the performance problems of architecture-complex applications. A good APM tool should enable you to drill down from the Java EE layer into the database layer to ensure that performance issues are resolved quickly.

The situation is not getting better, the company's website performance down to a very low point, frustrated customers began to look for other vendors. It investigators began to investigate and considered the Java EE application to be the culprit for poor response times. This immediately brought a lot of pressure on the Java EE development team, and they had to identify and solve the problem.

The Java EE development team, after some initial surveys, thought the problem was not in the Java EE layer, but that it was always traceable to the database. But the database team retorted that the problem was actually in the Java EE layer. The blame for each other has grown, the team spirit has vanished, the chaos has started to pop, and customers and incomes have continued to decline.

This situation highlights a major requirement: IT departments must be able to make decisions quickly and decisively in order to support better interoperability between Java EE and the database layer.

Basic challenge: Finding out the cause of the problem

When the delay in response time drives away the users of the Web site, the Java developer is forced to join in this mutual reproach game. Programmers who develop applications in the middle tier must interoperate with the database, and when performance bottlenecks occur, the problem is also shown in the Java EE layer if the database is the cause of the lower level. The real problem, though, is interoperability. How do you best adjust the overall relationship between these two levels to get the best performance of your application? More deeply, how do you look at these bottlenecks, identify the real cause of the problem, and deal with these problems as quickly as possible?

Many APM (Application performance Management) tools help us identify and resolve these performance issues. Two of the most common ways to find bottlenecks in a Java-ee application are:

1, using a different color alarm instrument program to monitor the state of the system. The green meaning is good, yellow or red means you have to deal with performance problems. The instrumentation program can also report response times for different components in the system.

2. Instead of waiting for the performance to deteriorate to a certain extent to track the warning information of the instrumentation program, it uses a proactive approach and attempts to identify excessive response time or resource usage. You can do this by examining the top-level service requests (based on response time) and further analyzing what components they call.

Suppose there is a banking system. A customer viewing the account information visited your Web site to obtain a summary of their accounts for the last seven days. The customer clicked on the "Get account Profile" link.

The process of getting account profiles is done by invoking a specific URL through a Web browser. Of course, at the lower level, it invokes a number of components that interoperate to provide the correct output information. In the process of locating bottlenecks, you start from the top-level call (possibly Doget () or the Dopost () method), follow the call tree to see all the components of the "Get account Profile" service call, and then look at the components called by these components, all the way to the bottom, in many cases, It may be an SQL statement that invokes a database using a JDBC (Java database connection).

You must know which of these components takes too long, but it takes a lot of time to analyze them in this way, especially if you're not too familiar with the individual characters. Do you have to look at each component and ask yourself if it took too long? Is it necessary to generate output information in 10 seconds in response to "Get account profile"? You're not particularly sure, because if you want to understand this information, you have to know the details of how each of the underlying methods or program components works. The only person who knows this information is the developer of a particular component. If you suspect that the problem is in the database response time, then you need to contact the database team to further study the problem. Isolating SQL statements