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.
Contents:
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.
