JProfiler 6.0: An Overview with Ingo Kegel
Join the DZone community and get the full member experience.Join For Free
Evolve your approach to Application Performance Monitoring by adopting five best practices that are outlined and explored in this e-book, brought to you in partnership with BMC.
Dr. Kegel explains, "These days, the tool category is very well known due to the "Visual VM" tool that is bundled with the JDK. Profilers used to be mostly about performance bottleneck search. However, in Java, memory profiling is very important and thread profiling in highly concurrent applications is also a challenge."
JProfiler has several functionalities in Java development, says Kegel. "We focus on three types of activities: Efficient development, performance QA and fire-fighting performance problems in production. So, JProfiler will be used by different people, depending on what it is used for."
"Towards the low-level side, profilers share a gray area with debuggers," Kegel explains. "They show you stuff that debuggers could show you in principle - but debuggers don't do too well. Towards the high-level side, profilers overlap with monitoring tools that are routinely used in production, but have much stricter requirements for overhead and usually do not use the JVMTI (the native tool interface of the JVM)."
Kegel explained how JProfiler is commonly deployed: "Many of our users use JProfiler through its IDE integrations. In the IDE, users have a "Profile" run mode, much like the "Debug" run mode. JProfiler is opened side by side with the IDE and shows information about the profiled process. In this scenario, there is no configuration required apart from installing the IDE integration, which is a couple of clicks in the JProfiler GUI."
"Often, users have to profile application servers remotely. They will run the command line integration wizard for the server on the remote computer and attach with the JProfiler GUI. Another possibility is to configure a session with triggers that control the recording of data and save snapshots at some time. For example, the profiling agent could wait for the CPU load to exceed 70%, then record 10 minutes of CPU data, and save a snapshot. Those snapshots can then be opened in JProfiler GUI."
Kegel says snapshots can be compared with respect to a wide range of data in the QA perspective. "Reports can be generated in the JProfiler GUI or with command line executables," Kegel explains. "In that way you can detect and analyze regressions across different builds or versions."
JProfiler is a mature project. ej-technologies has been developing JProfiler since 2001. Dr. Kegel says they have enough new features planned to keep developing it for the next 20 years. DZone asked Kegel about the recently released 6.0 version of JProfiler.
Thread and monitor profiling was a big focus in 6.0," Kegel says. "The exceptional method run recording feature is really interesting and quite unique: Often a method that is invoked very frequently, such as a web service call will regularly run in an acceptable time, but every once in a while, say not more often than one in a million, it takes unacceptably long. It is very difficult to analyze such a problem in detail, unless you have the exceptional method run recording feature in JProfiler 6.0 that presents you the call trees of the slowest method runs separately. Also, I think that the tree maps are really cool!"
On the subject of competition, Kegel had some straightforward answers: "On the open source side, the profiling tools with the most features is Sun's Visual VM. The main benefit to us is that we don't have to convince people anymore that they need a profiler. Once people have a serious problem, they go looking for the best tool to solve it and I hope a lot of them end up with JProfiler. On the commercial side, there is the venerable JProbe that's been around since the very early Java days, and a few other tools with a smaller feature set such as YourKit or AppPerfect."
DZone asked Dr. Kegel about the challenges of making a solid profiler. Kegel said, "The biggest challenge that a profiler vendor faces all the time is that recording more data is always desirable for the user, but profiling must not get in the way in terms of CPU and memory overhead. Another piece of complexity is that the profiling agent must be implemented in native code. This means we have to support each platform separately." JProfiler has a long list of supported platforms.
The Future of JProfiler
In closing, DZone wanted to get the inside scoop on ej-technologies' plans for the next version of JProfiler. Kegel told DZone, "[JProfiler] 6.1 early next year will bring full Java 7 support. This concerns code compiled with -target 1.7: Pre-verification is now mandatory and the new invokedynamic bytecode targeted at dynamic languages will be supported. Generally, we want to do more for dynamic languages like Groovy, JRuby, Jython, Clojure and others in future releases. Long term plans include more features for JEE and specific framework analysis. Also, our issue tracker is full with "minor" usability things and smaller feature requests. We implement these in the minor releases while major releases focus on headline features."
For documentation on JProfiler and a reference manual, visit ej-technologies' website.
Opinions expressed by DZone contributors are their own.