Overview

The section provides an overview of the Waveset’s Profiler’s features and functionality. The information is organized as follows:

• Major Features

• How the Profiler Locates and Manages Source

• Statistics Caveats

The Profiler provides helpful information, but has a performance cost on its own. If you do not need the Profiler data, you can disable this utility using the instructions provided in .

Major Features

You can use the Profiler utility to

• Create “snapshots” of profiling data.

  A snapshot is the cumulative result of profiling since the last time you reset all of your collected profile results.

• Display snapshot results in four, different data views:

  • Call Tree view provides a tree table showing the call timing and invocations counts throughout the system.

  • Hotspots view provides a flattened list of nodes that shows the aggregate call timings regardless of parent.

  • Back Traces view provides an inverted call stack showing all the call chains from which that node (known as the root node) was called.

  • Callees view provides an aggregate call tree of the root node, regardless of its parent chain.

• Specify what kinds of information to include in your snapshot:

  • You can include every element of form, workflow, and XPRESS or restrict the content to a set of specific elements.

  • You can pick specific Java methods and constructors to include or exclude from the instrumentation. Instrumentation of Identity Manager classes and custom classes is supported.

• Manage your project snapshots as follows.

  • Save the snapshot in your project’s nbproject/private/idm-profiler directory or to an arbitrary location outside of your project.

    ---

    Note –

    You can view a list of all saved snapshots in the Saved Snapshots section of the IDM Profiler view.

    ---

  • Open snapshots from your project or load them from an arbitrary location outside your project.

  • Delete snapshots.

• Search for specific nodes, by name.

How the Profiler Locates and Manages Source

This section describes how the Profiler looks up and manages the source for the following Waveset objects:

• Forms, Rules, Workflows, and XPRESS objects: When you take a snapshot with the Profiler, the server evaluates all of the profiling data and discovers on which sources the data depends. The server then fetches all of these sources from the repository and includes them in the snapshot. Consequently, you can be sure that the Waveset objects displayed in the snapshot are accurately reflecting the point at which the snapshot was captured.

  This process adds to the size of the snapshot, but the source size is actually a relatively small fraction of the total size. As a result, you can send a snapshot to Sun’s Customer Support without having to send your source files separately.

• Java source: When you take a snapshot of Java source, the client downloads the snapshot and then goes through the snapshot to capture all referenced Java sources from the project. When you save the snapshot, the client zips the sources and attaches them to the end of the snapshot.

  Then, when you view the snapshot and go to the Java source, the client first checks the content of the snapshot. If the client cannot find the content there, it checks the project’s content. This process allows you to send a snapshot containing profiling data from both your custom Java code and Waveset code.

  ---

  Note –

  In a Java source snapshot, do not assume the source is up-to-date with the server or always available.

  ---

In Call Tree view or Hotspots view, you can double-click any node that corresponds to a Java method, workflow, form, rule, or XPRESS to view the source for that node.

Statistics Caveats

The following sections contain information to consider when you evaluate results provided by the Profiler:

• Self Time Statistics: To compute a root node’s Self Time statistic, the Profiler subtracts the times of all children nodes from the root node’s total time. Consequently, an uninstrumented child node’s time is reflected in the root node’s self time. If a root node has a significant self time, you should certainly investigate why. You might not have the proper methods instrumented and so you are looking in the wrong place. For example, assume method A calls method B.

  Method A takes a total time of 10 seconds (where total time includes the call to B) and the call to B takes a total time of 10 seconds.

  If both A and B are instrumented, the call stack reflects that information. You will see that A has a self-time of 0 seconds and that B has a self-time of 10 seconds (where 10 seconds was actually spent in B). If, however, B is not instrumented, you only see that the call to A takes 10 seconds and that A’s self-time is 10 seconds. Consequently, you might assume the problem lies directly in A rather than in B.

  In particular, you might notice large self times on JSPs during their initial compile. If you reset the collected results and then re-display the page, the self time value will be much less.

• Constructor Calls: Because there are limitations in the Java instrumentation strategy, initial calls to this() or super() will appear as a sibling to the constructor call, rather than as a child. See the following example:

  class A { public A() { this(0); } public A(int i) { } } and: class B { public static void test() { new A(); } } The call tree will look like this: B.test() -A.<init>(int) -A.<init>() Rather than this: B.test() -A.<init>() -A.<init>(int)

• Daemon Threads: Do not be misled by the seemingly large amount of time spent in a number of Waveset’s daemon threads, such as ReconTask.WorkerThread.run() or TaskThread.WorkerThread.run(). Most of this time is spent sleeping, while waiting for events. You must explore these traces to see how much time is actually spent when they are processing an event.