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

This article shows you a sample analysis of Quest JProbe best practices, which is concise and easy to understand. I hope you can learn something from the detailed introduction of this article.

1. Introduction

In the wide application of Java, a key driver is the improvement of production efficiency due to the use of standard class libraries and application frameworks. By reducing the necessary software development tasks such as design, implementation and debugging, Java greatly improves integration and interoperability among various platforms; other development environments can not provide as powerful features as Java. In fact, no environment has the obvious advantages of framework-based development like J2EE, and J2EE can quickly build scalable, distributed secure enterprise applications.

Although these advantages have been promoting the unprecedented development of J2EE, there are often some troubles, that is, people are often disappointed with the performance of J2EE applications. Therefore, we need some tools and research strategies to help the J2EE development team solve these performance issues. This is the problem that Quest JProbe Profiler and Jprobe Memory Debugger are trying to solve.

1.1 Overview of J2EE performance

In general, the end-user experience of J2EE application performance is closely related to the following levels:

J2EE architecture diagram

J2EE applications refer to servlets,JSPs,EJBs and supporting classes, which constitute the client's application in the context of the J2EE application server.

J2EE application servers refer to the design, implementation and configuration of J2EE application server infrastructure, which provide the context of customer J2EE applications.

JAVA runtime environment refers to the design and implementation of JAVA virtual machine and its configuration (heap size, etc.).

Platform-underlying hardware (such as the number of CPU, memory size, IPUBO subsystem, etc.) and operating system design, implementation and configuration (thread and process scheduling, subsystem optimization, overall load, etc.).

Although there is no doubt that the bottom layer will affect the overall performance, experience continues to show that the common cause of performance degradation is caused by design problems and poor implementation of Servlets,JSPs and EJBs that make up J2EE applications. This article will focus on how to identify the reasons for performance degradation in this underlying layer.

1.2 Overview

This article describes how to use Quest JProbe Memory Debugger and Profiler to analyze J2EE applications in the BEA WebLogic Server6.1 context. It consists of three main parts:

Setup-after introducing the architecture of JProbe, we will describe how to integrate JProbe Memory Debugger and Profiler into the WebLogic Server6.1 environment.

Object Loop Analysis-in J2EE applications, a common cause of performance degradation is the creation of too many short-term objects (also known as object loops). In this section, we will show how to use JProbe Memory Debugger's Garbage Monitor to identify a large number of ways to create short-term objects. These are the best ways to further analyze and reduce the creation of too many objects.

J2EE performance Analysis-finally, we will use JProbe Profiler to show you how to perform performance analysis of J2EE applications and quickly identify some of the most time-consuming methods at the statement level.

two。 Integrate BEA weblogic server and Quest JProbe

2.1 Quest JProbe

The Quest JProbe product line consists of a family of tools that include the following four analytical tools.

JProbe Memory Debugger- checks the memory usage of the Java software.

JProbe Profiler- analyzes the performance of Java software.

JProbe Threadalyzer- identifies thread-level deadlocks and incorrect access conflicts

JProbe Coverage- verifies the integrity of the test framework through the statement-level execution information provided.

Although this article focuses on JProbe Memory Debugger and Profiler, all four tools adopt the same architectural design and are integrated in the same way as BEA WebLogic servers.

2.1.1 Architecture of JProbe

A JProbe-based survey session consists of two programs:

Figure 2 JProbe architecture

The JProbe console is a Swing-based Java application that provides a graphical user interface (GUI) for establishing survey sessions, viewing analysis information and deeply analyzing the information content in Snapshot files while the program is running.

Test Java virtual machine-JProbe uses the callback method provided by JVMPI (Java Virtual Machine Profiling Interface) to run Java applications and collect analysis information using a standard Java virtual machine, which is provided by the manufacturer. In the analysis of WLS-based J2EE applications, the Java application runs in the Java virtual machine, which is composed of the basic framework of the WebLogic server, just as the J2EE application is deployed on it.

This structure has a very flexible startup mode. You can start the test Java virtual machine from the user graphical interface itself, or you can start the test Java virtual machine separately and connect it to the JProbe console.

2.2 using JProbe Application Server Integration Tool

1. Start JProbe Application Server Integration.

two。 Select the version of the BEA Weblogic server you want to integrate from the drop-down list in the upper left corner.

Figure 3 JProbe Application Server Integration window

3. Click the Create button. Edit the contents on the right side of the window, as shown in figure 3.

4. Edit the following area or use the default values.

Integration ID:JProbe Demo 1Integration ID to facilitate the reuse of each integration process Server Directory:D:\ bea\ wlserver6.1 directly enter the WLS server root path or enter through the "browse" mode. Domain Name:Mydomain enter the domain name you want to analyze. Startup Script:StartWeblogic.cmd enters the startup script of the server to be investigated directly or through "browse" mode. JProbe Settings: (JPL File) the check the VAR checkbox integration tool allows you to use the JPL (JProbe Launchpad) files you created earlier. If you want to use the JPL file that is created by default by each tool at startup, select the VAR check box. Java Executable:d:\ sun\ jdk1.3.1\ bin\ Java.exe can be entered directly or browsed into the execution file path of the Java virtual machine.

5. Click the Advanced > > button.

6. Fill in the area below.

Java Options:-classic-mx128m-ms64m selectively enter parameters to the Java virtual machine.

7. Click the Save button.

Figure 4. JProbe Application Server Intergation window

You have successfully created an integration with BEA Weblogic6.1, and all four tools can use this integration process.

8. Click the Close button.

3. Identify the performance degradation of J2EE applications

JProbe Memory Debugger can help you track loitering objects and reduce the creation of too many objects, and JProbe Profiler can help you find performance bottlenecks. According to the specific situation, it needs specific analysis. Here, we briefly summarize the steps used to solve two common problems, object loops and performance bottlenecks. For more information and other ways to use JProbe Memory Debugger and Jprobe Profiler, please refer to the online help or read JProbe Memory Debugger Guide and JProbe Profiler Developer's Guide.

3.1 object Loop (Object Cycling)

One of the main reasons for the performance degradation of Java applications is the creation of too many objects (or object loops). The Java virtual machine allocates too much memory, creates unnecessary objects and initializes them, increasing garbage collection activity and causing performance degradation.

As a performance analyst, you first need to identify ways to create a large number of short-term objects. These methods are ideal starting points for further analysis of reducing the number of objects created. JProbe Memory Debugger provides a garbage monitoring feature that connects objects to the methods that allocate them, and keeps track of how many objects have been garbage collected when your application runs.

3.1.1 start the seminar on JProbe Memory Debugger

1. Start JProbe Memory Debugger. When the welcome screen appears, click "Run" to start.

Picture 5.JProbe Welcome screen

two。 In the JProbe LaunchPad window:

A. select "Using Application Server"

B. Select BEA Weblogic6.1 from the "Application Server" drop-down menu

C. Note that fill in JProbe Demo 1 in the drop-down menu of "Integration ID"

3. Select "Filter"

A. Click "Please enter a package,or method to display data for". Enter the package you want to investigate: profiler.com.quoteme.stockwatch

B. Select "Display" from the drop-down menu in the "Display" bar.

4. Select the Monitor Garbage Collections from Program Start check box.

5. Select "Snapshot Directory:" as d:\ temp.

6. Click the Run button.

Figure 6.JProbe LaunchPad Pad window

When WebLogic Server is initialized, Runtime Heap Graph increases, reflecting object creation and garbage collection activities. Once the WebLogic Server has been fully initialized, you can start the analysis.

3.1.2 Runtime interaction

Once the WebLogic Server is fully initialized, select the application use case you want to use to analyze the object loop. Select the Grabage Monitor tag and follow these steps:

1. First run Garbage Collection to recycle objects that are allocated in the Java heap but are no longer used. The Garbage Monitor table is updated to reflect the situation of these recycled objects.

two。 Click "Clear Table" to clear the Garbage Monitor table.

3. Run your application use case. When the Java virtual machine starts garbage collection, the Grabage Monitor table is updated.

Tip: look for peak load in Heap Usage Chart. The sharp rise and fall in peak load means that some objects survive only a short period of time before they are garbage collected. Some of the sharp ups and downs of load peaks are a clear signal that it is an object loop problem.

4. After you have finished applying the use case, run Garbage Collection again to recycle the objects that were last allocated but no longer used.

3.1.3 Analysis results

When the session ends, the Garbage Monitor contains the top ten classes that have reclaimed the most instances. Usually, these classes are not classes that you apply on your own. To be exact, they are third-party classes assigned (directly or indirectly) by some of your methods. The last column is the name of the method that allocates these recycled objects.

Tip: if the instances assigned by different methods belong to the same class and all belong to the first ten classes, you will see two lines of the same class.

Using Filter Allocating Methods, only show some of the methods in your package and block out the methods in other packages. In our example, the customer J2EE application is defined in the profiler.com.quoteme.stockwatch package, so we enter the filtering specification profiler.com.quoteme.stockwatch.*.* into the Filter Allocating Methods text input control.

In the GC'ed column, you can see how many instances are allocated by your method. For comparison, look at the Alive column to see how many instances are still in the heap. Java developers are often surprised at how many objects have been created and removed.

Now you have identified the method in which you have a problem. Think about how you might modify the way these objects are allocated to reduce or eliminate object loops? For example, you can try to reuse an object or create a pool of reusable objects.

When WebLogic Server6.1 compiles JSP, it automatically generates a servlet class name and assigns a package name and class name. For example, if you have a JSP file named TestJSP.jsp, it will be compiled into a class named jsp_servlet.__testjsp (the JSP name is followed by two underscores, both in lowercase letters).

Using Filtering Classes to restrict the contents of the Garbage Monitor for jsp_servlet.*, you can see the JSP that has been garbage collected into the Garbage Monitor. By setting jsp_servlet.*.* or jsp_servlet._.* to restrict the contents of the Garbage Monitor in Filtering Allocating Methods, you can view the garbage collection object in the specified JSP from the point of view of allocation.

Further research

If none of the methods you assign appear in Garbage Monitor, or if you still have an object loop problem after modifying the obvious problem, you need to do a stack trace to see which method call caused the instance to be created and allocated space. You need to use heap snapshot to view the stack trace. For more information, see Garbage Collection Tutorial or JProbe Memory Debugger Developer's Guide in the online help.

3.2 performance analysis

Solving object looping problems can help improve performance, but you may still face performance bottlenecks. A performance analysis can help you identify inefficient algorithms in J2EE applications. JProbe Profiler provides method-level and source code line-level metrics for applications.

3.2.1 start a JProbe Profiler survey session.

1. Start JProbe Profiler. When the welcome screen appears, click "Run" to begin.

Figure 8 JProbe Welcome window

two。 In the JProbe LaunchPad window:

a. Select "Using Application Server"

b. Select BEA Weblogic6.1 from the Application Server drop-down menu

c. Note that fill in JProbe Demo 1 in the Integration ID drop-down menu

3. Select Filter

a. Click Please enter a package,class,or method to display data for. Enter the package profiler.com.quoteme.stockwatch you want to investigate

b. Select Line Lever from the drop-down menu in the Detail Level column

This element defines that we want to treat all Java software running in the environment as the infrastructure. Because we don't want to know their performance information in detail (we just want to know the impact on the code, we don't want to analyze it in more detail)

Tip: JSP Profiling in WLS6.1 when JSP is compiled by WebLogic Server6.1, the resulting servlet is given a generated package and class name. For example, if you have a JSP file named TestJSP.jsp, it is compiled to generate a class named jsp_servlet._testjsp (the two underscores are followed by the JSP name, both in lowercase letters). If you want to keep track of how long methods in your JSP take to execute, you must specify the correct filtering strategy to capture data.

4. Select "CPU Time"

5. Select the Record Performance at Program Start check box

6. Select "a Snapshot Directory:" as d:\ temp

7. Click the "Run" button

Figure 9 JProbe Profiler LaunchPad window

3.2.2 Runtime interaction

In performance analysis, Heap Usage Chart is like a monitor of execution progress, and unlike Garbage Monitor described in the previous section, similar runtime performance information is not provided here. Initialize WebLogic Server itself to full startup.

As an object loop analysis, we recommend using an application-level, use-case-centric method for performance analysis, as follows:

1. Clear the accumulated performance data.

two。 Run your application use case.

3. Perform a performance snapshot to save performance information.

The performance snapshot includes metrics such as time and object creation during the use case run (this run starts with resetting the performance information-the first step until the end of the snapshot, and the third step).

3.2.3 explain the results

JProbe Profiler provides two tools to display collected data in different formats, which can be selected on a case-by-case basis:

Method List refers to the display of method-related data information in the form of a table. Using Method List, you can sort by name or measure, or display only some of the methods.

Call Graph-- refers to the display method in the form of a directed graph. You can use Call Graph to view and track the call relationships between methods in a program. From Method List or Call Graph, you can use the following tools to drill down into more detailed data.

Method Detail View is to show which methods (also called parent methods) or which methods (also called child methods) they have called for the selected methods.

Source Window displays statement-level performance information for the selected method.

3.2.3.1 Time and Object Creation Metrics

JProbe Profiler collects three basic metrics in terms of methods:

Number of Calls refers to the number of times the method was called during the session

Method Time is the total time it takes to execute the method

Method Objects refers to the total number of objects created by this method

Based on these basic measures, JProbe Profiler calculates two metrics to represent the method call tree:

Cumulative Time is the sum of the time it takes to execute these methods and the time it takes to execute the methods they call directly or indirectly.

Cumulative Objects is the sum of the objects created by these methods and the objects created by these methods directly or indirectly calling other methods

Based on Number of Calls, four average measures are used:

Avg.Method Time is the time it takes to call a method divided by the number of calls

Avg.Method Objects refers to the method object divided by the number of calls (method object refers to the number of objects created during method execution, excluding the number of derived objects created)

Avg.Cumulative Time is the cumulative time divided by the number of calls

Avg.Cumulative Objects refers to the cumulative object divided by the number of calls

By default, the data displayed by Call Graph is the data in the performance snapshot. We suggest you close Call Graph and then open the Method List window for a while.

3.2.3.2 Method List

The Method List window (see figure 10) displays the performance data as a table.

Figure 10 JProbe Profiler Method List window

Each line shows the time of the method and the measure of the object created by the method. Using Method List can quickly identify your most time-consuming methods. Usually you will find that your performance bottleneck is related to these methods.

If this is your first survey, following these steps will enable you to use Method List more effectively.

1. Select your snapshot and open "Method List".

two。 The "Filter" area is only used for methods that are displayed in your package or in classes you are interested in.

3. Click on the "Method Time" list to put your most time-consuming method at the top. Take a closer look at the top ten. Are there some metrics that surprise you? Can you improve the algorithm in your method?

4. Click on the "Cumulative Time" column name to put the most time-consuming call tree at the top. Compare "Method Time" with "Cumulative Time". Although the method itself may be efficient, it may also call inefficient methods, which may be in your code or in a third-party package or application framework.

5. Click on the "Number of Calls" column to see which of your methods are called the most. If one or more measures reflect that these methods are inefficient at the same time, you need to consider calling fewer of these methods, or calling those methods that are slightly more efficient.

3.2.3.3. Call Graph

Call Graph (see figure 11) provides a very powerful view of method invocation relationships. It puts the J2EE application in the WebLogic Server context, so you can see all the threads started by WebLogic, including the threads that call the J2EE application. For ease of search, there is a "Method List" under the Call Graph.

When analyzing performance, Call Method is most effective in locating entry points for J2EE applications and excluding data related to WebLogic threads. On the basis of separating the data of the application, the execution flow can be quickly drawn and graphically displayed clearly.

Here are some effective tips for using Call Method:

1. Select your snapshot and open "Call Graph".

two。 Click "Find" and locate the entry location of your J2EE application. It is usually the doGet () or doPost () method in servlet.

3. Select the method and separate the data to form a graph.

4. To start by displaying a subset of methods, sorting by "Cumulative Time" is the most time-consuming method. When you analyze a method, additional nodes are added to the method's call tree.

5. In "Method List", select the same measure in the drop-down list of "Color By" based on the location of the bottleneck you found. According to the metrics you choose, the most time-consuming methods now are highlighted in bright colors.

6. Choose the most time-consuming method. Expand the parent method tree (by clicking on the empty arrow tick in the node section or the left part of the node), you can see which method calls it. Can you call different, less time-consuming methods? Do you need to call these methods often?

7. Expand the submethod tree (pointing to the right of the node) to see which time-consuming method was called. What other sub-methods are also time-consuming? Are you aware of the actual time-consuming situation of the third-party approach? Can you call a different method that implements a more efficient algorithm?

Figure 11 JProbe Profiler Call Graph window

3.2.3.4 Method Detail View

You can analyze both Method List and Call Graph in depth, and you can easily see the metrics of time-consuming methods in one view, as well as the metrics of their child and parent methods. Select the method and open Method Detail View.

"Method Detail View" (see figure 12) shows the selection method in the center of the window, with its parent method above and its child methods below. We are already familiar with column headers, which are the same metrics as you see in other tools. An important difference is that the metrics used to display parent and child methods represent the contribution to the selected method, not to their own measures. So, if a method is called 12 times, the method that calls it, and the 12 calls are shown in the diagram of the parent method. If you want to continue analyzing parent or child methods, double-click the method to make it appear in the center of the "Method Detail View".

Figure 12 JProbe Profiler Method Detail window

3.2.3.5 Source Window

To view the code in your method, select the method and open Source Window. You need to point out the specific location of your source code.

If you collect data by row, you can see it in Source Window (see figure 12). In the left column, the data metrics for each statement are displayed. A row-level measure is a refinement of method-level measures, including the number of calls, the time the row was executed, the number of objects created when the row was executed, the cumulative time, and the number of cumulative objects.

Tip: if you need to edit your code and have integrated the integrated development environment IDE and JProbe Profiler, you can open your integrated development environment by selecting Edit > Edit Source. Of course, your changes will only be reflected on JProbe Profiler when you need to run your rewritten code and establish a new JProbe Profiler analysis session.

Figure 13 Jprobe Profiler Source Window

The above is a sample analysis of Quest JProbe best practices. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.