Maximize Java and Database interoperability performance

j2ee| Interactive | data | database | performance | maximize

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

Suppose it took too long to retrieve the account information. Each user requesting an account profile needs to wait 15 seconds for a response. So will the problem be on the database side? Is it possible that the application code is a problem? The problem with the network? Maybe even the user's Internet connection is too slow?

However, in this case you should be blamed if you suspect that database retrieval is a problem. One way to find the cause is to have the APM tool display all the SQL statements emitted by the application. Sort by response time, so you can see if an SQL statement takes too long for the reason of the error (some SQL statements take a long time-for example, to retrieve a list of all transactions per year by account).

Now you look at the SQL statement at the top of the list. It goes into the database and takes 1 seconds 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. So the next question is: Is there something wrong with the application layer? Who is calling this statement? How many times did you call it? If an application calls a SQL statement more often than you expect, you have reason to suspect that the application has failed.

The APM tool will help you again this time. You can simply click on the SQL statement, and a link appears, showing its entire call tree, starting with the customer request account profile, to the SQL statement entering the database. Now you have two pieces of information: You're sure you're looking at a particular request for the service, and you can see the impact of each individual component on the response time.

Now you can view the description of the component that invoked the SQL statement, and you find that it responds 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 called the SQL statement 7 times. This tells you that most of the 9 seconds are consumed by invoking the SQL statement. Not only did the component perform too many calculations, it also called the SQL statement several times. There may be some good reason for this, but no performance management tool can explain the cause. The most important thing is that you have pointed out the program components that must be investigated. A good APM tool can also provide some advice on how to solve this problem.

Is it really a problem with the database?

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

What you need now is a performance management tool that allows you to delve into the database layer for a specific service request (Get account profile). Please return to the list of SQL statements you have received and click on the link to the SQL statement that you are interested in, which will take you from the Java EE side to the database side. Now you are looking at the SQL statements in the Oracle database or other database product environment. The tool may help you identify database-side problems and may provide some professional tuning recommendations that database administrators (DBAs) can use to improve database performance. The problem may be poor disk performance in the data table space, it is recommended that you move it to another disk, or you may lose an index, you can increase the speed by creating a new index, or you may have too many threads running in parallel on the database, and you must isolate the threads to reduce the concurrency problem.

There are other possibilities. Data retrieval can take too much time because it takes a long time to get a database connection. The code is good, the database is running normally, but this wait time may tell you that the database connection pool is not large enough to handle a large number of even normal communication. You can query the application server to see how many connections have been defined, compare this number to a typical number of concurrent requests, and quickly determine if more connections are needed.

Improve interactive operation capability

Your performance management tool needs to identify not only the elements of the Java layer response time. It should also allow you to see the interaction between the Java-EE layer and the adjacent database layers, and provide a way to analyze performance problems at these two levels. To efficiently handle performance issues, Java EE Developers and DBAs are required to use integrated APM products. It also allows EE and the database team to "speak in the same language." The goal of most APM solutions is a single level in the architecture system that provides diagnostic information for a single level. When using this method, time will be wasted, mutual blame will form a storm, and often there is no solution to the problem. Today's complex architecture and sophisticated technology means that the performance problems caused by interaction between one level and the other levels are not positioned in this way. The most mainstream APM tools we can use now allow us to track the database layer from the Java EE layer to ensure that performance issues are resolved in a timely manner, regardless of the level of problem.

Conclusion

Increasing the interaction between the Java-EE layer and the database layer offers obvious advantages: faster end-user response times, increased customer loyalty, increased morale, and higher service boundaries. Now we can use advanced tools to fill the gap between the Java layer and the database layer, automatically search for bottlenecks, identify causes, and provide specific recommendations for solving problems. Each Java EE development team should seriously consider the value of these integrated APM tools for their production.