(Cast Rui Digital - Compilation)
1 Introduction
In Java's wide application, a key driver is due to the use of standard class libraries and application frameworks to increase production efficiency. By reducing software development tasks such as necessary design, implementation, and debugging, Java greatly improves integration and interoperability between various platforms; other development environments cannot provide powerful functions like Java. In fact, there is no environmental icon J2EE, which has a significant frame development, and J2EE can quickly build scalable, distributed security enterprise applications.
Although these advantages have been promoting J2EE's unprecedented development, there are often some troubles, which is often disappointed with the performance of J2EE applications. Therefore, we need some tools and survey strategies to help J2EE development team resolve these performance issues. This is the problem to be solved by Quest Jprobe Profiler and JProbe Memory Debugger.
1.1 J2EE performance over
In general, the end user is closely related to the J2EE application performance and the following level:
1 J2EE architecture
l J2EE Application refers to the Servlets, JSPS, EJBS, and support classes, which forms a customer's application in the context environment of the J2EE application server.
l J2EE Application Server refers to the design, implementation, and configuration of the J2EE application server infrastructure, which provides a context environment for the J2EE application.
l Java operating environment refers to the design and implementation of Java virtual machines and its configuration (size, etc.).
l Platform - underlying hardware (such as the number of CPUs, the size of memory, I / O subsystem, etc.) and operating system design, implementation, and configuration (thread and process schedule, subsystem optimization, overall load, etc.).
Although there is no doubt, the bottom level will affect the entire performance, and experience is constantly indicating that the universal reasons for performance decline is caused by the design problems and poor implementation of the composition J2EE application. This article will focus on how to identify performance degradation in this underlying.
1.2 overview
This article describes how to use Quest JPROBE MEMORY DEBUGER and PROFILER to analyze J2EE applications in the BEA WebLogic Server 6.1 context environment. Includes three main parts:
l Setting - After introducing JPROBE architecture, we will describe how JPRobe Memory Debugger and Profiler are integrated into the WebLogic Server 6.1 environment.
l Object cyclic analysis - In J2EE applications, the universal reason for performance is to create excessive short-term objects (also known as object cycles). In this section, we will show how to use Jprobe Memory Debugger's Garbage Monitor to identify a large number of methods for creating short-term objects. These are further analysis to reduce the best way to create excessive objects.
l J2EE Performance Analysis - Finally, we will use JProbe Profiler to tell you how to perform the performance analysis of J2EE applications, and quickly identify some time-consuming methods at the statement level.
2. Integrate BEA WebLogic Server and Quest Jprobe
2.1 Quest Jprobe
The Quest JPRobe product line consists of a family tool, which includes the following four analytics tools.
l JProbe Memory Debugger - Check the memory usage of Java software.
l JProbe Profiler - Analysis of the performance of Java software.
l JProbe Threadalyzer- identifying the deadlock of the thread and the wrong access conflict
l JProbe Coverage - Verify the integrity of the test framework by providing the provisioned statement level.
Although this article focuses on JPRobe Memory Debugger and Profiler, all four tools have the same architecture design and is the same as the BEA WebLogic server integration. 2.1.1 JPROBE architecture
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 user graphical interface (GUI) for establishing an investigation session, viewing analysis information at runtime and analyzing the information content in the Snapshot file at runtime.
Test type Java Virtual Machine-Jprobe provides the callback method provided by JVMPI (Java Virtual Machine Profiling Interface) using standard Java virtual machines to run Java applications and collect analysis information, which is provided by vendors. In an analysis of WLS-based J2EE applications, Java applications are running in a Java virtual machine, which consists of the basic framework of the WebLogic server, just as the J2EE application is deployed above.
This structure has a very flexible start-up mode. You can start the test type 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 the JProbe Application Server Integration Tool
1. Start JPROBE Application Server Integration.
2. Select the BEA WebLogic server version you want to integrate from the left corner drop-down list.
Figure 3 Jprobe Application Server Integration Window
3. Click the "CREATE" button. Edit the content on the right side of the window, as shown in Figure 3.
4. Edit the following area or use the default.
Integration ID: JProbe Demo 1 Integration ID, easy to reuse each integration process Server Directory: D: /bea/wlserver6.1 directly Enter the WLS server root path or entered by "Browse". Domain name: MyDomain Enter the domain name you want to analyze. Startup script: startWeblogic.cmd directly Enter the startup script to be investigated or entered by "Browse". JPROBE SETTINGS: (JPL file)
Check The Var Checkbox Integration Tool allows you to use the previously created JPL (JPROBE LAUNCHPAD) file. If you want to use the JPL file created by each tool when you start, select the VAR check box. Java EXECUTABLE: D: /SUN/JDK1.3.1/bin/java.exe Enter the execution file path of the Java virtual machine directly by browsing.
5. Click the "Advanced >>" button.
6. Fill in the following area.
Java Options: -classic -mx128m -ms64m selectively inputs parameters to the Java virtual machine.
7. Click the "Save" button.
Figure 4. JProbe Application Server Intergation Window
You have successfully created and integrated with bea webLogic 6.1, all four tools can use this integration process.
8. Click the "Close" button.
3. Identify J2EE application performance drops
JProbe Memory Debugger can help you track the free object (LoITering Objects) and reducing the creation of excessive objects, and Jprobe Profiler can help you find performance bottlenecks. According to the specific situation, it is necessary to analyze. Here, we simply summarize the steps of the two common problems used to resolve the object cycle and performance bottlenecks. More information and other methods of using Jprobe Memory Debugger and JProbe Profiler, you can refer to online help or read JProbe Memory Debugger Guide and Jprobe Profiler Developer's Guide. 3.1 Object Cycling
One of the main reasons for the decline in performance in Java is to create excessive objects (or object cycles). The Java virtual machine assigns excessive memory to create unnecessary objects and initialize these objects, increasing garbage collection activities, causing performance to decline.
As a performance analyst, you first need to identify how many short-term objects are created. These methods are ideal in reducing the number of analytics analysis of creating objects. . A garbage monitoring feature provided by JPRobe Memory Debugger connects objects and assigning them, and how many objects that have been tracked when your application is running.
3.1.1 Start JProbe Memory Debugger research session
1. Start Jprobe Memory Debugger. When the welcome interface appears, click "Run" to start starting.
Figure 5. Jprobe welcomes interface
2. In the JPRobe LaunchPad window:
a. Select "Using Application Server"
b. Select Bea WebLogic6.1 from the "Application Server" drop-down menu.
C. Note Fill in JPROBE DEMO 1 in the "Integration ID" drop-down menu
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" in the drop-down menu of the "Display" column.
4. Check the "Monitor Garbage Collection" check box.
5. Select "Snapshot Directory:" to D: / Temp.
6. Click the "RUN" button.
Figure 7. JProbe LaunchPad Pad window
When WebLogic Server initializes, Runtime HEAP Graph will increase, which reflects object creation and garbage collection activities. Once WebLogic Server has been fully initialized, you can start to analyze.
3.1.2 Running time interaction
Once WebLogic Server is fully initialized, select an application case you want to analyze object cycles. Select the Grabage Monitor tab, press the steps below:
1. First run a GARBAGE COLLECTION
Recycling objects allocated in Java pile, but no longer use. The Garbage Monitor table updates the situation reflecting these recycled objects at any time.
2. Click "Clear Table" to empty the Garbage Monitor table.
3. Run your application case. When the Java virtual machine starts garbage collection, the Grabage Monitor table will be updated. Tip: Looking for load peaks in Heap usage Chart. The load peak of sharp rise and fall means that some objects only survive very short time before being trash recovery. Some of the rapid lifts of a sharp lift is a clear signal that means an object cycle problem.
4. After completing your application case, run Garbage Collection again.
Recycling the object that is finally allocated but no longer used.
3.1.3 Analysis Results
When the session ends, the Garbage Monitor contains the top ten classes that have been reclaimed. Typically, these classes are not your own class, accurately, they are class of third parties allocated by some methods (direct or indirectly). The last column is the method name that assigns these recycled objects.
Tip: If the instance assigned by different methods belongs to the same class, and all the top ten classes, you will see the same class as two lines.
1. Use Filter Allocating Methods, only display some of your methods in your package, and mask the methods in other packages. In our example, the customer J2EE application is defined inside the profiler.com.quoteme.stockwatch package, so we use the filter specification profiler.com.quoteme.stockWatch. *. * Enter the filter allocating methods text input control.
2. In the gc'ed column, you can see how much instances have been assigned your method. As a comparison, view the alive column to see how many instances are still in the heap. Java developers often feel surprised by how many objects created and removed.
3. Now you have identified your questions. Think about how you might modify these assigned objects, reducing or excluding object cycles? For example, you can try to reuse an object or create a reusable object pool.
4. After WebLogic Server 6.1 compiles JSP, a servlet class name is automatically generated and gives a package name and class name. For example, if there is a JSP file called Testjsp.jsp, it will be compiled as a class named JSP_SERVLET .__ TestJSP (JSP name follows two underscores, and is lowercase letters).
Use Filtering Classes to jsp_servlet. * Limit the contents of Garbage Monitor, you can see JSP that has been returned to Garbage Monitor with garbage. Set JSP_SERVLET. *. * Or JSP_SERVLET.. * Or JSP_Servlet. * Limit the contents of the Garbage Monitor, view the garbage collection object from the assigned JSP.
make deeper research
If you assign a method that appears in Garbage Monitor, or after a significant problem; you need to make stack tracking, check which method is invoked to create an instance and assign space. You need to view the stack tracking using Heap Snapshot. To learn more, please see the Garbage Collection Tutorial or Jprobe Memory Debugger Developer's Guide in the online help.
3.2 Performance Analysis
Solving the performance loop problem helps performance improvements, but you may still face performance bottlenecks. Performing a performance analysis helps you identify low efficiency algorithms in J2EE applications. JProbe Profiler provides an application method level and source line grade metric.
3.2.1 Start JProbe Profiler Survey Session.
1. Start JPROBE PROFILER. When the welcome interface appears, click "Run" to start.
Figure 9. Jprobe Welcome Window
2. 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 in the Integration ID drop-down menu to fill in JPROBE DEMO 1
4. Select Filter
a. Click on the please enter a package, class, or method to display data for. Enter the package profiler.com.quoteme.StockWatch
d. Select Line Lever from the drop-down menu of the Detail Level
This element defines what we want to regard all Java software running in the environment as an infrastructure. Because we don't want to understand their performance information (we just want to know the impact on the code, we don't want to analyze more details)
Tip: JSP Profiling in WLS6.1
When JSP is compiled by WebLogic Server 6.1, the generated servlet is given a generated package and class name. For example, if there is a JSP file called TestJsp.jsp, it is compiled, generated a class named JSP_SERVLET._TESTJSP (two bottom lines are followed by JSP names, all write letters). If you want to track your JSP how much time in execution, you must specify the correct filtering policy to capture data.
5. Select "CPU TIME"
6. Select "Record Performance At Program Start" checkbox
7. Select "A Snapshot Directory:" for D: / Temp
8. Click the "RUN" button
Figure 11. JProbe Profiler LaunchPad Window
3.2.2 Running time interaction
In performance analysis, Heap usage Chart differs from a Monitor that performs progress, which is different from the Garbage Monitor of the previous section, which does not provide similar runtime performance information. Enable WebLogic Server to initialize it to fully start.
As the object cycle analysis, we recommend using the application level, perform performance analysis in the use case-centric approach, as follows:
1. Empty accumulated performance data
.
2. Run your application case.
3. Implement a single performance snapshot
, Save performance information.
Performance snapshots include time and measure data such as object creation during use, start from reset performance information during this run - the first step, and the end of the snapshot end, the third step).
3.2.3 Interpretation Results
JProbe Profiler provides two tools that displays collected data in different formats;
l Method List refers to data information related to the method in the form of a table. Using Method List can be sorted by name or measured value, or display only some of them.
l Call graph - refers to a method of displaying a view of a map. You can use the Call Graph to view and track the call relationship between methods in the program.
From Method List or Call Graph, you can use the following tools to go deep into more detail data.
l Method Detail View refers to what methods (also known as parent methods) are called or they call.
l Source Window Displays the statement level performance information of the selected method.
3.2.3.1 Time and Object Creation Metrics
JProbe Profiler collected three basic metrics in the method:
l Number of calls refers to the number of times the method is called during the session.
l Method Time means that the total time spent on the implementation of this method is the total number of objects created by this method.
Based on these basic metrics, JProbe Profiler calculates two metric representations to call the tree:
l Cumulative Time refers to the sum of time to perform these methods and performing their direct or indirect calls.
l Cumulative Objects refers to the objects that these methods created, and these methods directly or indirectly calls the overalls of other methods.
Four average metric based on Number of Calls:
l avg.Method Time means the time divided by the modification method
l avg.Method Objects refers to the number of method objects divided by the number of calls (the method object refers to the number of objects created during execution, does not include the number of derived objects created)
l avg.cumulative time means that the cumulative time divided by the number of times
l avg.cumulative objects refers to the number of cumulative objects
By default, the data displayed by the Call Graph is data in performance snapshots. We recommend that you close the Call Graph will open the Method List window again.
3.2.3.2 Method List
The Method List window (see Figure 12) shows performance data in the form of a table.
Figure 12. JProbe Profiler Method List Window
Each row shows the time and method of the method to create the metric of the object. Using Method List can quickly identify your most time consuming method. Usually you will find your performance bottlenecks and these methods.
If you are the first survey, follow these steps will allow you to use Method List more effectively.
1. Select your Snapshot to open "Method List".
2. The "Filter" area is only used to display methods in your package or in the class you interested.
3. Click the "Method Time" column name to rank your most time-consuming method. Check it carefully to see the top ten. Is there some metrics to be surprised? Can you improve the algorithms in your method?
4. Click the "Cumulative Time" column name to the top of the most consumable call tree. Compare "Method Time" and "Cumulative Time". Although the method itself is highly efficient, it is also possible to call low efficiency methods, which may be in your code or in a third party package or application framework.
5. Click the "Number of Calls" column name to see which method you are called up to. If one or more metrics also reflect these methods inefficient, it is necessary to consider reducing these methods, or calling those efficient methods.
3.2.3.3. Call graph
Call graph (see Figure 13) provides a very powerful way to call a relationship. It puts the J2EE application in the WebLogic Server context environment, so you can see all threads that WEBLOGIC launched, including calling the J2EE application. For convenience, Call Graph is "Method List".
When analyzing performance, Call Method is the most effective in the entry point of the positioning J2EE application and the data related to WebLogic threads. Based on the data separated by the application, the execution process can be quickly shown and clearly displayed in graphics.
Here is an effective technique using Call Method:
1. Check your snapshot, open "Call Graph"
.
2. Click "Find" and locate your J2EE application's entry location. Usually the doget () or dopost () method in the servlet.
3. Select the method and separate the data formation graphics
.
4. A subset of the display method is started, and these methods are the most time consuming method according to "Cumulative Time". When you analyze a method, you will add additional nodes on the call tree of the method.
5. In "Method List", select the same measure value in the drop-down list of "Color B" according to the bottleneck of "Color BY". Depending on the metrics you selected, the most time consuming method is highlighted in bright colors.
6. Select the most time consuming method. Expand the parent method tree (by clicking on the node section or the node mark on the left part of the node), you can see which method calls it. Can you call different methods? Do you need to call these methods frequently?
7. Expand the child method tree (point to the right side of the node), you can see which time-consuming method is called. What is the child method also time consuming? Do you realize the actual time consumption of a third party? Can you call a different approach to achieving more efficient algorithms?
Figure 13. JProbe Profiler Call Graph Window
3.2.3.4 Method Detail View
From Method List or Call Graph, you can analyze in depth, which is convenient to see metrics for time consuming methods, and the metric of their sub-methods and parent methods. Select the method and open "Method Detail View"
.
"Method Detail View" (see Figure 14) shows the selection method in the center of the window, and its parent method is above, its sub-method is below. Our heads of the column are already familiar, they are the same as those you see in other tools. An important difference is: Used to display the parent method and sub-method metrics indicate the contribution to the selected method, not their own metrics. So, if a method is called 12 times, these calls it, and 12 calls are displayed in the parent method. If you want to continue to analyze the parent method or child method, double-click the method so that the method is displayed in the center of "Method Detail View".
Figure 14 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 are collecting data by row, you can see these data in Source Window. In the left column, the data metric value of each statement is displayed. The row stage metric is the refinement of the method level measure value, including the number of calls, the time of executing the line, the number of objects, accumulation time, and accumulated objects created when executing the line.
Tip: If you need to edit your code and have already integrated integrated development environment IDE and JPRobe Profiler, you can open your integrated development environment by selecting Edit> Edit Source. Of course, you need to run the code you rewritten and create a new JPRobe Profiler analysis session, what you do is reflected on JProbe Profiler.
Figure 15 JPROBE PROFILER SOURCE WINDOW
Contact: 010-87755371email: wangyi1997@yahoo.com.cn
