Code profiling provides extra insight into code level execution time that is otherwise not captured by auto-instrumentation. See code profiling for general information.
- Currently only traced Servlet requests and SDK initiated traces are profiled. The frequency breakdown is based on the main handling thread hence asynchronous operation is not captured, nor would a non-blocking entry point such as Akka HTTP or Netty generate profiling information.
- Profiling information has granularity base on profiling interval (default is 20ms), and is configurable in profiler settings.
- Java class name, method name, base file name and line number will be collected. However, native method calls do not have line number.
- By default low-level java libraries are excluded (package "java", "javax", "com.sun" etc). This could be changed in profiler settings.
- Profiler is disabled by default, please refer to enabling code profiling.
- Traces with duration shorter than the configured profiling interval (default is 20ms) might not have profiling information.
- Traces are not servlet based nor SDK initiated.
- Profiles might be omitted if the profiling circuit breaker (more below) is triggered. When triggered, the library would print INFO level log message similar to:
Pause profiling for ... secs. Previous profiling operation took ... ms. That's total of ... consecutive profiling operation(s) that exceeded the circuit breaker duration threshold ... ms
- Overhead might be more noticeable in systems with high number of threads. To reduce overhead, increase code profiling interval such that the library would take snapshots less frequently.
- A circuit breaker is in place to prevent extra overhead when the JVM is under heavy load. Profiling will be paused when system load is too high.
- "Unknown" accounts for occasions where the library failed to obtain snapshots on the given interval. Various conditions can trigger missing snapshots, for example long Garbage Collection operation or high CPU load.