Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the performance indicators of enterprise Java applications". In the daily operation, I believe that many people have doubts about the performance indicators of enterprise Java applications. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "what are the performance indicators of enterprise Java applications?" Next, please follow the editor to study!

Application performance Management (APM) is a systematic solution for real-time monitoring to achieve application performance management and fault management. At present, it mainly refers to the monitoring and optimization of the key business applications of enterprises, and finally achieve the goal of improving the reliability and quality of enterprise applications, ensuring that users get good services, and reducing the cost of IT.

Although many people have predicted that Java will collapse, it is undeniable that Java still plays an extremely important role in many important projects, especially some large-scale bank and government projects. Tao Bingzhe, an Java engineer at OneAPM, a leading domestic APM company, has repeatedly participated in the performance optimization of banks, operators and other large enterprises, and summed up the four personality indicators that enterprise-level Java applications should pay most attention to, including: business affairs, external services, garbage collection and application layout. The following will be described one by one:

1. Business affairs

Business transactions are an intuitive reflection of real user experience: they capture real-time performance data that users experience when they interact with applications. To measure the performance of a business transaction, you need to capture the overall response time of a business transaction and the response time of each component. These response times are then compared with the benchmarks that meet the business requirements to determine whether the application is normal.

If you plan to measure only one aspect of the application, this article recommends that you measure the performance of business transactions. Although capacity indicators (container metrics) can help you decide when to adjust the size of the cluster, it is the business transaction that determines the performance of the application itself. Instead of asking about the usage of the application server thread pool (thread pool), you are concerned about whether users can complete their business transactions quickly and whether they perform properly.

A little background: business transactions are identified through their entrances, that is, the entrances through which users interact with your business. Such interactions include a web page request, a web service call, or a message in a message queue. Of course, you can also define multiple entries for the same web request based on a URL parameter, or multiple entry points based on the content of a service call. The key point is: business transactions must be related to your business process. For example, China Mobile's air payment business corresponds to multiple atomic services in the system. We should aggregate these atomic services into an air payment service through the corresponding association to monitor.

Once a business transaction is identified, its performance is measured throughout the application ecosystem. The performance of each business transaction is compared with its benchmark to determine whether it is normal or not. For example, if the response time of a business transaction is greater than the threshold you set, we determine that it is running abnormally.

All in all, business transactions best reflect the user experience, so they are also the most important capture dimension.

two。 External service

External services come in a variety of forms: subordinate web services, legacy systems or databases, etc. External services are systems that interact with applications. Code running in external service systems is often out of control, but we can control the configuration of these systems, so it is also important to know whether they are working properly and when they go wrong. And we must be able to distinguish whether the problem comes from our own applications or from these external service systems.

From a business perspective, we can identify and measure these external services that are in their own applications. Sometimes we need to configure monitoring methods to identify those methods that wrap external service calls. But for common protocols, such as HTTP and JDBC, external services can detect them automatically.

Business transactions give you global control over the performance of your application and help you classify performance issues. But external services can always greatly affect the operation of applications in unexpected ways, so you have to monitor them.

3. Garbage collection

Since the earliest version of Java, the core feature that has been retained is garbage collection, which is both loved and hated. Garbage collection eliminates the need to manually manage memory: when an object is finished, we just delete its reference, and garbage collection automatically frees it. You will be grateful if you have ever used a language that requires manual memory management, such as C # or Clippers. Garbage collection reduces the tedious steps of allocating and releasing memory space for programmers.

In addition, because the garbage collector automatically releases unreferenced memory space, it reduces the traditional content leak, that is, after the memory is allocated, the reference to the memory is deleted before the memory is freed. Sounds like a panacea, doesn't it?

Although garbage collection achieves the goal of not having to manage memory manually and prevents traditional memory leaks, the garbage collection process is sometimes quite clumsy as a cost. Garbage collection strategies vary depending on the JVM. An in-depth discussion of these strategies goes beyond the purpose of this article. However, readers should understand that it is important to understand how the garbage collection period works and how to configure it.

The enemy of garbage collection is the legendary main (major) or (full) garbage collection. All JVM have this problem except Azul JVM. In general, garbage collection is roughly divided into two categories:

Secondary

Main

In order to release objects with a short survival time, secondary garbage collection occurs relatively frequently. They do not block threads at run time and have less impact.

However, major garbage collections, sometimes referred to as "Stop The World, STW" garbage collections, because they block all threads in the JVM at run time.

When garbage collection runs, it runs a reachability test (reachability test), as shown in figure 4. It creates a root collection of objects (root set) that contains directly visible objects in each running thread. Next, it explores the other objects involved in the objects in the root collection, and then explores the objects involved in those objects until all objects are involved. In this process, it records (mark) the memory address of the currently active object, and then sweep all addresses that are not in use. To put it more appropriately, it frees memory that is not referenced by the root collection object. Eventually, it compresses and collates the memory so that the new objects can get the memory allocation.

According to different JVM, the secondary and primary recycling methods will be different. Figure 5 and figure 6 show the operation of secondary and primary recycling in Sun JVM.

In secondary recycling, memory is mainly allocated to Eden space until it is filled. Next, the copy collector (copy collector) copies the active objects in the Eden to the two survivor spaces (survivor spaces, to space, and from space). Objects left in the Eden are removed. If the survivor space is filled, but there are extra active objects, these objects will be moved to the tenured space. Only primary reclamation can free up memory for tenured space.

Eventually, the tenured space will be filled and the main recycling will be performed. It does not copy live objects that cannot be placed in the survivor space into the tenured space. At this point, JVM blocks all threads, runs reachability tests, clears young data (Eden and two survivor spaces), and compresses tenured space. We call it the main recycling.

You might think that the larger the heap, the less often the main recycling runs. But when it is executed, it takes longer than a small heap. Therefore, adjusting heap size and garbage collection strategy is also important for application performance.

4. Apply layout

* * the performance metric to be discussed is the application layout. With the advent of the cloud, applications have become more flexible: the application environment can be resized according to the needs of users. Therefore, it is very important to detect the layout of the application to determine whether the number of instances is appropriate. If you have too many instances, the cost of your CVM will increase. But if you don't have enough examples, business affairs will be affected.

In the evaluation process, the following two indicators are particularly important:

Throughput of business transactions

Container performance

Business transactions should be benchmarked, and you should know the number of instances needed to meet the benchmark at a given time. If the throughput of your business transactions grows suddenly, you need to increase the number of instances to satisfy users.

Another thing that needs to be monitored is container performance. Specifically, you want to determine if any of the instances in the application are overloaded, and if so, you may want to add instances to that application. It is important to look at the status of an instance from an application perspective, because a single instance may be overloaded by factors such as garbage collection, but if most instances in the application are overloaded, the application may no longer be able to support the traffic it accepts.

Because the instances in the application can be scaled individually, it is very important to analyze the performance of each instance and then adjust the application layout.

At this point, the study on "what are the performance indicators of enterprise-level Java applications" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.