- System requirements
- Profiler architecture
- Running the profiler
- Profiler activation
- Running applications with the profiler
- Connect to profiled application
- Troubleshoot connection problems
- Solving performance problems
- CPU profiling
- Deadlock detector
- Memory profiling
- Garbage collection
- Monitor profiling
- Exception profiling
- Probes: monitor events of various kinds
- Events in user interface
- Event inspections
- Built-in probes
- Probe classes
- Monitoring method invocation events
- Data storage
- Performance Charts
- Inspections: automatic recognition of typical problems
- Automatically trigger actions on event
- Summary, snapshot annotation, automatic deobfuscation
- IDE integration
- Time measurement (CPU time, wall time)
- Snapshot directory customization
- Export of profiling results to HTML, CSV, XML, plain text
- Profiler Java API
- Profiler HTTP API
- Command line tool to control profiling
- FAQ: How to profile in my scenario?
Lasting events and point events
Each table row contains information on some event.
There are two kinds of events:
- Lasting event: this is something which lasts in time. At some point in time it starts, and at a later point in time it ends. The lasting event duration can be measured as end time minus start time.
- Point event: this is some "fact" which just happens at some point of time. The concept of duration is not applicable for the point events.
Which kind to use?
Whether particular event is lasting event or point event, depends on your tasks.
For example, you may think of method
execution as of a lasting event,
which starts when the method enters and ends when the method exits,
if you are interested to know how long the method execution takes,
or to discover other events which happen while
Foo.bar() is running,
e.g. what kind of I/O it performs, whether it accesses database or other resources etc.
In case you are only interested in
Foo.bar() invocations as in a fact,
you may think of them as of point events.
On table creation, you decide which kind of events the table is intended for, specifying appropriate parameters of the table object constructor.
So, each table can store either of the event kinds.
A lasting event starts when table row is created with
and ends when the row is closed with
Table.closeRow() must not be used for tables with point events.
Thread, stack trace and/or times are recorded for all events on row creation, and also on row closing for lasting events.
For lasting events recorded as some table rows it is possible to find rows in other tables which correspond to events which happened during the lasting event. For example, if processing of JSP pages is recorded as lasting events in some table, and database access events are recorded in another table, it will be possible to learn which SQL activities happen during particular JSP page processing.