Profiling J2EE Applications Using Profile Project

You can use the Profile Project method to profile web applications, ejb modules and enterprise applications running on a registered local Tomcat, Sun Java System Application Server / GlassFish or JBoss installation. You can also use this method to profile J2EE applications created from an existing Ant script (free-form web application or ejb module project). Profiling an application using this method is very simple, requiring only few mouse clicks to start profiling, and requires almost no configuration. In general, this method behaves exactly like the Run Project method, starting the Profiler at the start of the J2EE application. This is the recommended method for new and less experienced users.

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, see Profiling J2EE Applications Using Attach Profiler.

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 Web Applications on Local Tomcat, Sun Java System Application Server / GlassFish or JBoss

A web application running on a local Tomcat, Sun Java System Application Server / GlassFish or JBoss is the preferred and the easiest configuration for profiling using the NetBeans Profiler. It requires minimal configuration from the user and allows you to start profiling with just a few mouse clicks. You can see an example of profiling the performance of a web application in the NetBeans Profiler tutorial. A flash demo of profiling performance of web applications is available here.

Setting Up Your Profiling Session

If your web application is set as Main Project in the IDE, you can choose Profile Main Project in the Profile menu to open the Select Profiling Task dialog box. Alternatively, you can select any web application project that is open in the IDE and choose Profile Project in the Profile menu to open the Select Profiling Task dialog box.

If you want to profile a file by choosing Profile File on a .jsp page or a servlet, the behavior is similar to Profile (Main) Project. The only difference is that when you run the application the selected web page will open in the browser instead of the default web page for the project.

Note: 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 the core Java classes is also profiled unless they are filtered out by the Instrumentation Filter described below. Entire Application profiling generally imposes higher profiling overhead than the Part of Application method.

If you select the Profile application server startup option in the Select Profiling Task dialog box, 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. You should use this profiling method 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. 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 Entire Application profiling. 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

To start profiling, click Run in the Select Profiling Task dialog. The profiling session will start immediately. When you click Run, the following occur:

  • The web application is compiled
  • The target server starts in profiling mode
  • The application is deployed
  • The appropriate web page opens in your browser

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

Obtain and Evaluate Profiling Results

Profiling results are collected as soon as the profiling session is started. If you are using the Entire Application method, 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 web 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 web 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 EJB Modules and Enterprise Applications

You can profile performance of ejb module or enterprise application the same way as a web application. The only difference is that for ejb modules and some enterprise applications (depending on their setup) a web browser isn't automatically started after deployment. Actually this reflects the behavior of simply running the project using Run action. To profile ejb module or enterprise application, you may follow one of following approaches:

Invoking application's code from manually started web browser or other client. After the application is deployed to a server, you should invoke its code the same way as you would for debugging or just evaluating application functionality. This typically means launching a web application front end which uses enterprise logic of profiled J2EE application in a web browser. Also other types of clients can be used. Once the code of profiled J2EE application is invoked, profiling data are available.

Profiling appropriate web application front end. You can specify the related web application to be used as the profiled project. Typically, the EJB's code is performed as a result of some user action in a browser. If this action is performed/handled by the web application code, you will see the EJB code in its call tree. To profile an EJB Module using this approach, follow the steps described in Profiling Performance of Web Application on Local Tomcat, Sun Java System Application Server / GlassFish or JBoss. Note that you have to compile and deploy the EJB module to the server before profiling as this is not done when profiling related web application.

Profiling Performance of J2EE Applications with Existing Ant Script (Free-form)

Profiling web application or ejb module with existing Ant script is similar to profiling web application or ejb module on a local Tomcat, SJSAS / GlassFish or JBoss server described above. The only difference is that you need to make some modifications to the build script and server startup script.

Configure FreeForm J2EE Application for Profiling

To profile a J2EE application with an existing Ant script (free-form project), you need to make some modifications to the build script and server startup script. In general this means adding a new Ant target for profiling the project (and eventually another one for profiling separate files) and modifying server startup scripts to enable the Profiler agent. You should also configure the profiling Ant target to automatically deploy the application to the server. Detailed information about build script modifications for profiling can be found in How to setup Projects with existing Ant script (Freeform Projects) for Profiling. Information about modifying server startup scripts is provided by the Profiler Attach Wizard. To display it, choose Profile | Attach Profiler from the main menu and click Attach Wizard... in the Select Profiling Task dialog box.

The first time you start profiling your free-form project, you are asked to select the Ant task that will be used for profiling. This setting is then saved and used for every other profiling session for that project. Once the free-form project is configured for profiling, you can profile the project as you would any other IDE J2EE Project.

Once configured, you can profile the J2EE application with existing Ant script according to the steps described in Profiling Performance of Web Application on Local Tomcat, Sun Java System Application Server / GlassFish or JBoss or Profiling Performance of EJB Modules and Enterprise Applications. Note that you can profile a free-form project on any server configured for profiling, not just projects deployed to a Tomcat or Sun Java System Application Server.

Profiling Memory Usage 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