Profiling J2EE Applications Using Attach Profiler

If you want to profile a J2EE application on a remote application server or a local server other than Tomcat, Sun Java System Application Server / GlassFish or JBoss, you need to use the Attach Profiler method. However, this method requires some manual configuration of the server and the server startup script. You also need to compile and deploy the J2EE application to the server manually to use this method. This method is recommended only for experienced users.

If you want to profile J2EE applications running on a registered local Tomcat, Sun Java System Application Server / GlassFish or JBoss installation, see Profiling J2EE Applications Using Profile Project.

Note: You should familiarize yourself with the Profiling Tips before obtaining and evaluating profiling results from the J2EE application. The Profiling Tips describe various facts and tips related to the behavior of profiled applications and profiling results accuracy.


Profiling Performance of J2EE Applications on Any Local or Remote Web/Application Server

You can use the Attach Profiler method to profile any J2EE application running on a local or remote web/application server. When you use this method, the application has to be compiled and deployed on the server manually. You also need to manually modify the server startup script to prepare the server for profiling, and manually start the server and invoke application code from a web browser or other client.

Deploy J2EE Application to the Server

You have to compile and deploy the J2EE application manually before profiling it on a local or remote web/application server. If the target server is supported by the IDE (Tomcat, Sun Java System Application Server / GlassFish, JBoss, WebLogic), you can specify the server as the deployment server in the project properties, and then use Build Project and Deploy Project in the IDE. To specify the target server, right-click the project and choose Properties in the pop-up menu. In the Run category of the Project Properties dialog, select the target server from the list of servers registered with the IDE.

If your server is not supported by the IDE, you have to deploy the application to the server manually before profiling. For many servers this means copying the .war/.ear file to the autodeploy directory. For instructions on deploying the application, see the documentation for your server.

Configure and Start the Server

You can use the following two methods to attach Profiler to a server:

  • Direct attach. Direct attach means that the Profiler agent blocks the server VM until the Profiler connects. When starting the server using Direct Attach, the server is not really started. Instead, the server waits for the Profiler. Once the Profiler attaches, the server continues to start up. Direct Attach is the preferred method for profiling J2EE applications as it can be used with standard JDKs supported by the Profiler.
  • Dynamic Attach. Dynamic Attach allows you to connect the Profiler after the server has been started. This method is only available when the server is running using the Modified Profiler JDK. Note: the Modified Profiler JDK is no longer supported.

To configure and start the server for profiling, follow the instructions in the Profiler Attach Wizard. To open the Attach Wizard, choose Attach Profiler in the Profiler menu. In the Select Profiling Task dialog box, click Attach Wizard. Configuring the server for Direct Attach is strongly recommended. When you use the Attach Wizard, a modified server startup script is created for you to use to start the server in profiling mode. For Tomcat, Sun Java System Application Server 8.x PE / GlassFish and JBoss the startup script is created automatically and local servers can be started directly from the Attach Wizard. If the target server isn't listed in the Attach Wizard, follow the instructions for Generic Web/App Server.

Alternatively, if you want to start a registered instance of Tomcat or the Sun Java System Application Server / GlassFish for Direct Attach, you can right-click the server instance in the Runtime window and choose Start in Profile Mode. No additional configuration is required in this case. You can simply select a profiling task and click Attach once the server is ready for profiling.

Note. If you are profiling a J2EE application on the Sun Java System Application Server 9 / GlassFish server on Windows, starting the server for profiling may fail if the NetBeans IDE is installed on a path that contains spaces (such as the default NetBeans IDE installation path on C:\Program Files\netbeans-5.5). The workaround for this is to install/copy the NetBeans IDE to a location without spaces in the path (such as C:\netbeans-5.5) and run the IDE from that location.

Setup Profiling Session

To set up a profiling session once the server is configured and started for profiling, choose Attach Profiler from the Profiler menu to open the Select Profiling Task dialog box. Select the appropriate J2EE application from the drop-down list at the top of the Select Profiling Task dialog box. Note. Do not select the <Global Attach> option. The Global Attach option should only be used for profiling applications without project or sources. If you are profiling the project for the first time, a message will appear notifying you about modifications that need to be made to the project's build script to enable profiling.

When you profile your application, you choose the profiling method in the Select Profiling Task dialog box. The following methods are available in the Select Profiling Task dialog box:

Analyze Performance - Entire Application. You should choose this profiling method if you need an overview of the behavior of the entire application or if you just do not want to experiment with more detailed profiling settings. In this mode, all the methods of your application will be profiled. All the code called from these methods down to core Java classes is also profiled, unless this code is filtered out by the Instrumentation Filter described below. The Entire Application profiling method generally imposes higher profiling overhead than Part of Application method.

If you select the Profile application server startup option, server startup will be profiled before any code of your application executes. Typically you do not need to use this feature for regular profiling.

Analyze Performance - Part of Application. If you think you know where a performance bottleneck is, or if you want to profile some specific part of your code, such as only one or a few servlets, you should use this profiling method. This method allows you to set the profiling root methods from which the application will be profiled. Detailed information about profiling using root methods can be found in Instrumenting a Root Method.

This profiling method typically imposes significantly lower profiling overhead than using the Entire Application method. When you choose this method, only the data you are really interested in is collected and displayed. To define root methods for profiling, click Select and use the Add From Project option, and use the tree of appropriate project.

Instrumentation Filter. The Instrumentation Filter enables you to filter out various packages/classes that you are not interested in. This significantly reduces profiling overhead. The Instrumenation Filter enables you to specify the packages/classes (in the entire application or within root method execution) that will be instrumented and profiled.

There are two types of instrumentation filters:

  • Exclusive. When you choose this option, the specified packages and classes are excluded from profiling.
  • Inclusive. When you choose this option, only the specified packages/classes are profiled.

You can choose the Quick Filter for a simple instrumentation filter definition, or you can define your own Filter Sets to be used in specific projects or for specific types of profiling. For example, you can create an instrumentation filter that you use when profiling web applications on Tomcat. You can create a new exclusive Filter Set that filters out Core Java Classes, Tomcat Classes and NetBeans Classes (useful when HTTP Monitor is enabled), and give the filter set a name like "Tomcat WebApp Exclusive". Alternatively, you can create an inclusive Quick Filter which specifies only the packages defined in the project, such as test.servlets. ortest.beans.MyBean. When this filter is selected, only the classes in the test.servlets package and test.beans.MyBean class are profiled.

From this example, you can see that you can use several packages/classes definitions at the same time. When doing this, use a space ( ) or a comma with a space (, ) as a separator. You can also use the "*" wildcard at the end of the filter definition, but as the instrumentation filter uses simple starts-with logic, it will be simply removed during evaluation.

Detailed information about defining and using the Instrumentation filter can be found at Analyze Performance.

Start Profiling

Attach Profiler - Direct Attach. To start profiling in Direct Attach mode, click Attach in the Select Profiling Task dialog box. If the Profiler agent is already waiting for connection on the server side, the Profiler connects immediately. If the Profiler agent is not running, a dialog box with a progress indicator is displayed indicating that the Profiler is waiting for the agent. You should now start the server for profiling if you have not already started it. Note that for some servers, using the native launcher (like Sun Java System Application Server / GlassFish) it can take several seconds after running the server startup script before the Profiler agent is activated and ready for attach. After profiling data has been collected, you can disconnect the Profiler without needing to stop the server.

Attach Profiler - Dynamic Attach. For Dynamic Attach, you should let the server completely finish the start up process before attaching to it. To connect to the server configured for Dynamic Attach, click Attach in the Select Profiling Task dialog box and use one of the following connection methods.

  • PID connection. If you are using this method, a dialog appears listing all of the running VMs that the Profiler can connect to. Once you select the appropriate VM to attach to and click OK, the Profiler attaches to the server and starts profiling the J2EE application.
  • Ctrl+Break or or Ctrl+\. If the server console is available, you can use the Ctrl+Break (Windows) or Ctrl+\ (UNIXes) connection method. After clicking Attach, a dialog box with a progress indicator appears. This dialog box indicates that the Profiler is waiting for connection. To invoke connection, press the key combination in the server's console. When you invoke the connection, the Profiler attaches to the server and starts profiling the J2EE application. After profiling data has been collected, you can disconnect the Profiler without stopping the server.

    On UNIX, if you keep the server running you can re-connect to it for Profiling at any time. However, on Windows only one dynamic attachment can be done for a single server session, any other attempts won't succeed.

For both connection methods, the application's working directory has to be set up correctly otherwise dynamic attach will fail. The working directory differs according to the server. For example, Tomcat's working directory is the directory from which the startup script was started. If the server console is available, you can determine the working directory by invoking a thread dump (Ctrl+Break) - a debug message will also be displayed: "JFluid: JVM startup directory is ...". Otherwise you can obtain it for example by using a simple servlet which prints out the value of the appropriate system property: System.getProperty("user.dir");

Obtain and Evaluate Profiling Results

Profiling results are collected as soon as the profiling session is started. If you are profiling the Entire Application, some interesting data is available immediately after server startup, specifically the web application's listeners and filters initialization. You can use the controls in the Profiler window to display live profiling results or to take a snapshot of the collected data. Depending on which profiling root methods you selected, you probably will not get this data if you are using the Part of Application profiling method.

Usually you are not interested in data about listeners or filters, so you can click Reset Collected Results to clear that data. The first usable data will be collected after some code is invoked as a result of some action in the web browser, typically displaying a .jsp page that uses JavaBeans and/or custom tags or processing servlet's doGet/doPost method. You should note that the data collected when the application starts up the first time often only represents the startup behavior of the J2EE application.

If a .jsp page is being displayed for the first time, it is compiled to the servlet internally by the server, which affects the call tree and the methods timing. Also, the behavior of servlets and other application code can be slightly different during the first run than it is in a real production environment, where the application is running constantly. To obtain profiling data that better represents real application performance, you should generate some workload on the profiled code before measuring any times (call trees should not be affected by this). Load generators can help you with this. You may also want to investigate how your J2EE application works with the caching capabilities of various browsers.

To improve the readability of the collected data, you can use the Results filter in the Hot Spots view in the Profiling Results window. The Results filter is applied to the results that have already been collected and is not related to the Instrumentation filter. When you use the Results filter, you filter the results which start, contain or end with a defined pattern. You can also use more complex regular expressions for filtering. Data is filtered based on package/class/method names exactly as they appear in the first results table column. Like the Instrumentation filter, you can specify more than one pattern, separating the patterns by a space or comma with space.

Profiling Performance of J2EE Applications Without Project or Sources

The NetBeans Profiler allows you to profile any Java application even if you do not have its sources or it is not configured as an IDE project. However, some advanced features like automatic root methods determining for profiling Entire Application and Go To Source functionality will not be available. To profile a J2EE application without project or sources, follow the steps described in Profiling Performance of J2EE Applications on Any Local or Remote Web/Application Server. In the drop-down list at the top of the Select Profiling Task dialog box, select the <Global Attach> option. This tells the Profiler that no project context is known for the profiling session.

When using the Part of Application mode for profiling an application without a project or sources, you have to use the Add Manual option in the Specify Root Methods dialog box and define the profiling root methods manually by entering the class name, method name and method signature. Note that the method signature has to be in VM format. You can use the javap tool from the JDK distribution to determine the correct method signatures from a .class file (usage: javap -s package.ClassName).

Profiling Memory of J2EE Applications

You can use the NetBeans Profiler to analyze a J2EE application's memory usage by selecting the Analyze Memory Usage task. By choosing Profile Project, you can profile the memory of a J2EE application running on a local Tomcat or Sun Java System Application Server or properly configured J2EE Application created from an existing Ant script (free-form). For detailed information about memory profiling, see Analyze Memory Usage. For an example of profiling memory usage of a web application, see the NetBeans Profiler tutorial.

When profiling memory, you cannot set the profiling root methods and/or instrumentation filters, so all objects created during the server's life are tracked. This can lead to significant profiling overhead and memory consumption for complex application servers like the Sun Java System Application Server / GlassFish. Therefore you should use a machine that is powerful enough for this type of profiling. To lower the profiling overhead, you can modify the setting so that only every 10th object is profiled. You may also want to disable (limit) the recording of stack traces for object allocations.

When profiling J2EE applications to detect memory leaks, using the metrics for Surviving Generations can be very useful. By tracking the number of various object generations surviving garbage collection cycles, the NetBeans Profiler is able to detect memory leaks in the beginning before it uses any noticeable amount of memory. See Profiling Results - Memory Usage for more details.


Project Features

About this Project

Profiler was started in November 2009, is owned by Tomas Hurka, and has 58 members.
By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
Please Confirm