Profiling an Enterprise Application in NetBeans IDE
NetBeans IDE includes a powerful profiling tool that can provide important information about the runtime
behavior of enterprise applications.
Using the profiling tool you can easily monitor thread states and obtain data on the CPU performance and
memory usage of an application.
In this document you will use the profiling tool to obtain data about
a simple enterprise application consisting of an EJB module and a web module that is deployed
as an EAR to an application server.
This document shows how to use the IDE to obtain profiling results about the following.
- Runtime behavior of an application
- CPU time used by an application's methods
- Object creation
If you are deploying an application to a local registered Tomcat, GlassFish or JBoss installation,
you can profile the application with only a few mouse clicks and almost zero configuration.
The process of profiling the project is very similar to using the Run command in the IDE.
You can easily start profiling enterprise application projects or individual web and EJB modules
by choosing Profile > Profile Main Project from the main menu.
Contents
To follow this tutorial, you need the following software and resources.
Note: It is strongly recommended that you run the IDE on JDK 6 u4 to ensure that
all features work correctly. The IDE uses connection support included with JDK u4.
Note: In this document you will profile an enterprise application deployed to the
GlassFish application server.
The preferred and the easiest configuration for profiling an enterprise or web application
is when the the application is running on a local Tomcat, Sun Java System Application Server /
GlassFish or JBoss server.
About Profiling Enterprise Applications in the IDE
When profiling enterprise applications, in most cases you will want to analyze the
performance of the application to see the execution time of the project's methods.
This enables you to troubleshoot the application and try to improve the performance.
In some cases you will also want to obtain data on memory usage to optimize
garbage collection.
The process for profiling enterprise applications, EJB modules
and web applications is basically the same as for running the project using the Run command.
After selecting the profiling task and specifying profiling options, you click Run
in the Select Profiling Task dialog box to start the profiling session.
When you start a profiling session, the IDE does the following:
- Compiles the application
- Starts the target server in profiling mode
- Deploys the application
- Attaches to the application
- Opens the web browser to the web page (if specified in project properties)
- Opens the Live Profiling Results tab
Depending on your profiling options, the IDE will immediately start displaying profiling results in the
Live Profiling Results tab.
In some cases, such as when you have specified profiling root methods,
you may need to perform some actions in the web browser before results are displayed.
Profiling Enterprise Application Projects
An enterprise application project in the IDE typically contains an EJB module
and a web module as subprojects.
The enterprise application project does not contain any source files,
only information about building and deploying the enterprise application archive (EAR)
and server configuration metadata.
The business logic of the application is generally contained in the EJB module.
The web module contains the source code for the presentation layer.
If you have all the sources for the enterprise application project,
the best and easiest method for profiling the application is to profile the enterprise application
rather than one of the project's subprojects.
This ensures that all the necessary code is compiled and deployed and that the application
behaves correctly.
You can profile an enterprise application project by doing either of the following:
- If the enterprise application is set as the Main Project, click Profile Main Project from the IDE toolbar or
choose Profile > Profile Main Project in the main menu.
- Right-click the enterprise application node in the Projects window and choose Profile from the popup menu.
When profiling an enterprise application, you can increase the relevance of the profiling results
by specifying profiling root methods and using instrumentation filters to limit the classes that are profiled.
This can help minimize the impact that the profiling overhead imposes on the performance of the application
and increase the relevance of the profiling results.
Unlike web applications, when you run an enterprise applications
the browser is not always opened automatically. (This depends on the project configuration.)
This means that in some cases you may need to manually launch the web application front end
and then invoke code such as the business logic in an EJB module from the web browser.
Profiling EJB and Web Module Subprojects
You can start a profiling session from any EJB module or web module project.
In this case, you may want to try one of the following approaches:
- Profiling an EJB module.
If you take this approach, you will probably need to invoke the application code
manually from the web browser or another client because EJB module projects
are generally not configured to open a web browser.
After the EJB module is deployed to the server, you should invoke its code the
same way as you would for debugging or evaluating application functionality,
typically by launching the web application front end and then performing actions in the web browser.
- Profiling a web module.
If you take this approach you will need to compile and deploy the EJB module to the server before
profiling the web module 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.
Creating the Sample Project
In this document you will profile the ServletStateless enterprise application.
To do this you will use the New Project wizard to to create the sample application.
To create the ServletStateless application:
- Choose File > New Project from the main menu.
- In the New Projects wizard, select the Samples > Enterprise category.
- Select the ServletStateless project.
- Specify a location for the project and make sure the Set as Main Project property is selected.
Click Save.
When you click Finish, the IDE creates the ServletStateless sample project.
You can see that the ServletStateless project is visible in the Projects window and that the name is in bold indicating that
it is set as the main project.
The ServletStateless enterprise application project contains an EJB module project and a web module project.
By default, when using the IDE to profile a project, the IDE will profile the main project.
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.
If you want to profile a project that is not set as the main project, you can right-click the project node in the Projects window
and choose Profile in the popup menu.
Alternatively, you can choose Profile > Profile Other > Profile PROJECT_NAME from the main menu.
If you want to profile a file such as .jsp page or a servlet, right-click the file and choose Profile File from the popup menu.
The behavior is similar to Profile (Main) Project, but when you start the profiling session
the selected web page will open in the browser instead of the default web page for the project.
Profiling for the First Time
The first time that you use the profiling tool, the IDE needs to perform some initial operations to
ensure that accurate profile results are obtained and to integrate the tool with the project.
For more about the calibration and integration steps,
see Introduction to Profiling.
Integrating the Profiler with the Project
The first time you profile a project, you will see a dialog box informing you that the IDE needs to integrate the profiling tool with the target project.
To integrate with the project, the IDE modifies the build script of your project to import an additional build script for the required profiling libraries.
Before modifying the build scipt, the IDE creates a backup of the original build script.
By adding the profiling libraries to the build process, the IDE is able to connect to the application
to monitor and profile the application.
To integrate the profiling tool with the project, click OK in the dialog box.
The IDE creates a backup of build.xml named build-before-profiler.xml
and adds the following line to build.xml:
<import file="nbproject/profiler-build-impl.xml"/>
You can restore the original build script by choosing Profile > Advanced Commands > Unintegrate from the main menu.
Monitoring the Enterprise Application
Monitoring an application enables you to obtain high-level information about properties
of the target JVM, including thread activity and memory allocations.
Because monitoring an application imposes very low overhead,
you can run the application in this mode for extended periods of time.
When you choose the Monitor task, the target application is started without any instrumentation.
To monitor the ServletStateless application:
- Make sure that ServletStateless is set as the main project.
- Choose Profile > Profile Main Project from the main menu.
- Select Monitor in the Select Profiling Task dialog box.
- Click Run.
When you click Run, the IDE builds the application, starts the server in profile mode and
then deploys the application to the server.
The IDE then attaches to the application and starts retrieving data.
Data on threads in the target JVM is displayed in the Threads tab.
The Threads tab displays data on all threads, server threads
as well as threads in the application.
You can view additional monitoring information by clicking the Telemetry Overview button in the Profiler window
to open the VM Telemetry Overview window.
The VM Telemetry Overview window enables you to quickly get an overview of the monitoring data in real time.
You can double-click any of the graphs in the VM Telemetry Overview window to open a larger version of the graph.
When monitoring an enterprise application, the Memory(Heap) and Memory (GC) graphs can help
you quickly see the memory usage of the application.
You can place your cursor over the graph to open a tooltip with more detailed information.
If the heap size or the number of surviving generations is steadily increasing, it could indicate
a memory leak.
If you suspect a memory leak, you may then want to profile the application's memory usage.
Analyzing the Performance of the Enterprise Application
Analyzing CPU performance enables you to see data on the method-level CPU performance (execution time)
of your application and the number of times the method is invoked.
You can choose to analyze the performance of the entire application or select a profiling root to limit
the profiling to a part of the application code.
You can set filters to limit the classes that are instrumented.
When profiling an enterprise application, you will usually want to choose the
Profile project and subproject classes instrumentation filter to limit the instrumented
code to the classes in the subprojects (the EJB module and the web application module).
If you select Profile all classes when profiling a web application or
enterprise application, all classes including core Java classes and server classes are instrumented.
You need to exercise caution if you choose this filter option because instrumenting so many classes
can impose a very significant overhead .
To analyze CPU performance, you choose how much of the application you want to profile by
selecting one of the following options:
- Entire Application.
When you choose this mode the IDE instruments when threads enter and exit all methods
called by the application.
In addition to the Java core classes, in an enterprise application this includes
a number of classes in the target server.
For this reason it is important to choose a filter to limit the sources that are instrumented.
It is recommended that you use the Profile project and subproject classes filter when using this mode.
- Part of Application.
In this mode, you can instrument and profile a limited subset of the application's code.
This can greatly reduce the profiling overhead.
To profile part of an application, you first need to specify one or more root methods.
A root method is the method, class or package in your source code that you specify as an instrumentation root.
Profiling data is collected when one of the application's threads enters and leaves the instrumentation root.
No profiling data is collected until one of the application's threads enters the root method.
In some cases profiling part of an application may be the only way to obtain any detailed and/or realistic data
because of the significant profiling overhead when profiling an entire application.
Profiling the entire application also may generate so much profiling data
as to be unusable.
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.
Depending on the profiling root methods you select, 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).
You can use a load generators to help you with this.
(For more, Using a Load Generator in NetBeans IDE.)
The caching capabilities of various browsers can also have an impact on performance.
Using instrumentation filters
To reduce the profiling overhead you can choose an instrumentation filter from the drop-down list to
limit profiling to the source code that you are interested in.
You can use the filter to specify the packages/classes that are instrumented.
You can choose from the default filters or create a custom filter.
You can create custom filters to use in specific projects or for specific types of profiling.
For example, if you want an instrumentation filter to use when profiling web applications on the Tomcat web server,
you can click "Edit filter sets" to create a filter set that excludes Core Java Classes, Tomcat Classes and NetBeans Classes
(useful when HTTP Monitor is enabled). You can then give the filter set a name such as "Tomcat WebApp Exclusive"
and then choose that filter from the drop-down list when profiling applications deployed to the Tomcat web server.
You can define a simple instrumentation filter by clicking "Edit filter value" and editing the list of
packages or classes that are instrumented. This creates a Quick Filter that you can then select from the drop-down list.
For more information about defining and using instrumentation filters, consult the profiling
documentation in the IDE.
Profiling the Entire Enterprise Application
You should choose the option of profiling the entire application if you need an
overview of the behavior of the entire application
or if you do not want to try more detailed profiling settings.
In this mode, all the methods of your application are profiled.
Though you get an overview of all the classes in your application,
the profiling overhead is higher than if you choose to profile only part of an application.
You will now use the IDE to analyze the CPU performance of the ServletStateless enterprise application.
In this exercise you will analyze the performance of the entire application and select a filter to limit the instrumented
classes to the classes in the enterprise application and the sub-projects (ServletStateless-ejb and ServletStateless-war).
- Stop the monitoring session by clicking the Stop button in the Profiler window.
- Choose Profile > Profile Main Project from the main menu.
- Select CPU in the Select Profiling Task dialog box.
- Select Entire Application.
- Select Profile project & subprojects classes from the Filter drop-down list.
The filter enables you to limit the classes that are instrumented,
in this case to the classes that are found in the main enterprise application project
and its sub-projects (EJB and web modules).
Click Show filter value to see a list of the filtered classes.
- Click Run.
Note. If you are profiling web applications on the GlassFish appliction 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-6.1).
The workaround is to install/copy your NetBeans IDE installation directory to a location that does
not contain spaces in the path (such as C:\netbeans-6.1).
You can see that the Live Profiling Results tab shows the execution time for the init
and service methods for the servlet in the Servlet2Stateless class and that each method was invoked one time.
None of the methods in the EJB module have been invoked yet.
Note. By default, the auto-refresh mode is active so that the data displayed is refreshed every few seconds.
You can activate and de-activate the auto-refresh mode by clicking the Auto-Refresh button in the toolbar.
To improve the readability of the collected data, you can use the Results filter
in the Hot Spots view in the Live Profiling Results window to filter the displayed results.
The Results filter only filters the display of results and does not affect the classes that are instrumented.
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. You can specify more than one pattern,
separating the patterns by a space or comma with space.
You can click the DrillDown button to see a graphic representation of the relative time spent
various areas of the application, for example, servlets, listeners, etc. You can click on the graphic to drill
down into the displayed profiling results.
In the web browser, type your name in the field and click Submit Query.
When you click Submit Query, you can see that the Live Profiling Results tab is updated
to reflect the action in the web browser.
Clicking the button invoked the init
and sayHello methods in the StatelessSessionBean class. Each was invoked one time.
The service method for the servlet in the Servlet2Stateless was also invoked again.
The tab also displays how much time was spent in each of the methods.
You can see that most of the time was spent in the service method.
Instrumenting an application will always impose some overhead when profiling the application.
In such a simple application the overhead is not noticeable, but in a complex application the overhead can
be quite significant.
You can reduce the overhead by limiting the classes that are profiled by
selecting a profiling root method.
Profiling Part of the Enterprise Application
In this exercise you will profile only part of the 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 typically imposes significantly lower profiling overhead than profiling the entire application.
By profiling only part of the application, only the data you are really interested in is collected and displayed.
To profile part of an application you need to set a profiling root method(s).
The IDE instruments only those methods that are called by a thread entering
the profiling root method.
For example, if you set the sayHello method in the StatelessSessionBean class
in the EJB module as the root method, the IDE will start instrumenting methods when
the method is invoked and an application thread enters the method.
The init constructor will not be instrumented because it is invoked before sayHello.
If you select the Profile all classes instrumentation filter the IDE will instrument all methods
called by sayHello, including any Java core classes.
Note:
In a more complex application you may want to specify several root methods.
You can select individual methods, entire classes and packages as profiling roots.
To specify a profiling root and analyze the performance of the application, perform the following steps.
- Stop the previous profiling session (if still running) by clicking the Stop button in the Profiler window.
- Choose Profile > Profile Main Project from the main menu.
- Select CPU in the Select Profiling Task dialog box.
- Select Part of Application.
- Click define to open the Specify Root Methods dialog box.
To profile part of an application you need to first specify the root methods.
By selecting the profiling root, you limit the profiling to the methods called by the thread
entering the profiling root.
- Click Add From Project to open the Select Root Methods dialog box.
- In the Select Root Methods dialog box, select Web Application View in the Select View drop-down list.
- Expand the ServletStateless node and select the
service method under Servlet node.
Note. You can see that the Servlet constructor is not selected.
You can use this dialog to limit the instrumentation to a specific method or methods in a class.
If you do not want to limit the instrumentation to a specific method,
you can use the dialog box to select an entire class or package.
For example, if you select Servlet in the Select Root Methods dialog box,
the IDE will instrument the init constructor and the service method.
Click OK to close the Select Root Methods dialog box.
You can see that the service method is listed as the only root method in the Specify Root Methods dialog box.
You can click Add From Project to add additional methods, classes or packages.
You can also explicit define a method by clicking Add Manual and typing the method signature and class.
- Click OK in the Specify Root Methods dialog box.
In the Select Profiling Task you can see that one root method is specified as the profiling root.
You can click edit to view and modify the selected root methods.
- Select Profile project & subprojects classes from the Filter drop-down list.
- Click Run.
When you click Run, the IDE builds and deploys the application and
opens the web browser to the servlet page.
The IDE displays the profiling results in the Live Profiling Results tab.
You can see that the IDE only displays the results for the method specified as the profiling root.
The application thread has not entered any other methods in the enterprise application after entering
the profiling root.
None of the methods in the EJB module have been invoked yet.
Note. Though the application has entered other methods since entering the profiling root,
these other methods are not displayed because the intrumentation filter limits the instrumentation
to classes that are part of the enterprise application.
- In the web browser, type your name in the field and click Submit Query.
When you click Submit Query, you can see that the Live Profiling Results tab is updated
to reflect the action in the web browser.
Clicking the button invoked the sayHello method in the StatelessSessionBean class one time.
The service method was also invoked again.
The results display the performance of the application, but may not accurately represent the
performance of an application that has been running for some time.
One way to emulate the performance of a web application under more realistic conditions
is to run a load generator script.
- Repeat the previous step a few times in the browser and then click
Reset Results in the Live Profiling Results tab to clear the results.
- After the profiling results are reset, type your name and click Submit Query one more time.
If you look at the profiling results, in many cases you may see that the performance has improved.
Analyzing Memory Usage of an Enterprise Application
You can use the IDE's profiling tool to analyze an enterprise application's memory usage
to obtain detailed data on object allocation and garbage collection.
The Analyze Memory Usage task gives you data on objects that have been allocated in the
target application such as the number, type and location of the allocated objects.
When profiling memory usage 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.
Therefore you should be aware of the potential limitations of your machine before performing 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 enterprise 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 tool can help you to detect memory leaks early, before the application uses any noticeable amount of memory.
To analyze memory performance, you choose how much data you want to obtain by selecting one of the following options:
- Record object creation only.
When this option is selected, all classes currently loaded by the target JVM
(and each new class as it is loaded) are instrumented to produce information about object allocations.
- Record both object creation and garbage collection.
When selected, profiling the application gives you information on object liveness such as about how many
objects of each type are still alive, their size and average age, as well as allocation data.
The first option is a functional subset of the second and has a smaller performance and memory overhead.
The Overhead meter in the Select Profiling Tasks window gives a rough approximation of the increase or decrease
in profiling overhead according to the profiling options you select.
You will now use the IDE to analyze the memory performance of the enterprise application.
You will choose the Record both object creation and garbage collection option.
- Stop the previous profiling session (if still running) by clicking the Stop button in the Profiler window.
When you click Stop, the IDE detaches from the application.
- Choose Profile > Profile Main Project from the main menu.
- Select Memory in the Select Profiling Task dialog box.
- Select Record both object creation and garbage collection.
- Leave the Track every N object allocations at the default value of 10.
This option sets the interval /proportion for stack sampling.
By setting the value 10, this means that for each class only every 10th object allocation will be recorded completely.
To record all information for each object, you can set the value to 1.
However this will substantially increase the profiling overhead.
- Deselect Record stack traces for allocation (if selected).
If you select this option you will notice that the Overhead meter will increase substantially.
When profiling an enterprise application, it is quite possible that you will need to increase
the memory for the IDE because of the amount of collected data.
- Click Run.
When you click Run, the IDE compiles the application, starts the server in profile mode
and deploys the application to the server.
To view the profiling results, click Live Results in the Profiler window to open the
Live Profiling Results window.
The Live Profiling Results window displays information on the size and number of objects that
are allocated on the target JVM.
In addition to the objects allocated by the enterprise application,
the results also include all the objects allocated by the application server.
By default the results are sorted and displayed by the number of Live Bytes,
but you can click a column header to change how the results are displayed.
You can also filter the results by typing a class name in the filter box below the list.
See Also
This document demonstrated basic approaches to obtaining profiling data when
profiling an enterprise application that is deployed to the GlassFish application server.
For more detailed information about profiling settings and features not covered in this document,
please consult the documentation included in the product and available from the Help menu item.
For related documentation, see the following resources:
top
