- 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?
Data storage allows you to uniformly record the following information for each event:
- Where it happened: stack trace, thread
- When it happened: process uptime
- Event-specific numerical or text information. For example, this can be a number of bytes written to a stream, or an URL string of request being processed etc. - you can record whatever you want.
This information will be available as telemetry when you connect to the monitored application, as well as saved in captured snapshots.
The UI will provide rich set of tools to analyze the gathered information, or to export it for external processing.
Although it is intended to use the storage to gather information, if you wish you can also store it your own way, e.g. write it to your application's log, to a file or simply write to console.