JProfiler instruments several J2EE service layers on the fly and records semantic data as well as execution times for these service calls. The instrumentation is not implementation dependent and works for all drivers or service providers. The service calls are annotated into the call tree view and can be selected as hot spot types in the hot spot view.
The following service types can be enabled separately:
execute
, executeQuery
, executeUpdate
and
executeBatch
.
The displayed data is always the executed SQL statement, without any parameter substitution.
receive
and receiveNoWait
methods of MessageConsumer
s are
measured. For asynchronous messages, the onMessage
methods of
MessageListener
s or message driven EJBs are measured.
The displayed data is by default the message destination as returned by
message.getJMSDestination()
. If you would like to differentiate messages based on the
content of the message you can write a custom JMSResolver
and register it with
Controller.registerJMSResolver
. Please see the
API documentation for more information.
javax.naming.Context
and javax.naming.directory.DirContext
that return data are measured.
Based on whether a call is a name lookup or a search call, the displayed data will be prefixed with [NAME] or [SEARCH] and contains information about the name or search expression in the parameters.
Service calls are grouped by their display data, i.e. two equal select statements at the same call stack are held as one node in the internal data model. For each node, JProfiler keeps track of the invocation count and total execution times for each thread status. To avoid an overload of the system, there's a maximum number of recorded service calls per call stack. If the maximum number is exceeded, the oldest call is merged into an "[earlier calls]" node. By default, this maximum value is set to 20, if you require more detail you can increase the value in the text field as needed.
If Split call tree for each request URL is enabled, JProfiler will analyze the URLs that occur in calls to servlets and JSPs. For each URL, a new node is created in the call tree. URLs can also be selected as a hot spot type in the hot spot view. In that way, you can differentiate the performance issues of separate pages or requests.
By default, only the URL without the query parameters is used for the above splitting process.
In order to retain selected parameters in the call tree, you can enter them in the text field
labeled retained request parameters. For example, if you want to split the call tree for
each different value of the parameters "action" and "level", enter action,level
into the text field. If you would like to customize the splitting process (for example, if the session
id is incorporated into the URL) you can write a custom HTTPRequestResolver
and
register it with Controller.registerHTTPRequestResolver
. Please see the
API documentation for more information.
Request URLs that do not lead to an unfiltered method in the call tree are not displayed by default. If you would like to display all requests, please check the checkbox labeled Show request URLs that are outside the call tree.
JProfiler can detect the following J2EE component types:
servlets
JSPs
EJBs
The corresponding methods have a separate icon in the call tree. For JSPs, the name of the
JSP source file is displayed instead of the generated class and for EJBs the name of the interface
is displayed instead of the generated stub or proxy classes. In the "method" and the "class" aggregation levels,
the real class names are displayed in square brackets, too.
Based on this component information, JProfiler offers the J2EE components aggregation level in all views with an aggregation level selector. If you would like to disable J2EE component detection, you can deselect the checkbox labeled Detect J2EE components.