News: JProfiler 4.0 released, adds J2EE features
JProfiler 4.0 has been released by ej-technologies. JProfiler 4.0 adds the following J2EE-related features: measurements of JDBC, JMS and JNDI calls are annotated into the call tree and are offered as separate hotspot types. J2EE components are detected automatically and can be used as an aggregation level. The call tree can now be split for each request URL and a URL hotspot type has been added.
- Posted by: Ingo Kegel
- Posted on: June 14 2005 07:17 EDT
The new aggregation levels for all call trees and call graphs allow you to take a higher level view of your system. This release adds support for JVMTI and offers a new non-blocking startup mode, bookmarks (to compare over time), and more.
A trial download is available.
I played a little bit with the new version and it has some unique and really innovating features. Especially the customizable Hotspot view eg. URL hotspots are very usable to identify your bottlenecks from a different perspective than Java method calls. (Especially useful for QA people)
The aggregation of J2EE components is an essential feature if your are profiling server applications and I was always hoping to get such a feature in a standard profiler.
- Mirko -
codecentric - your code is our source
Always like this product. It's pretty cool, I'm just starting to play with 4.0.
We in GigaSpaces used JProfiler 3.x for several months already and I must comment that we found it very useful and usable for our RnD, QA and PS teams.
We have allot of experience with several profilers and I must say that JProfiler is the first serious profiler product. Its configuration, integration with IDE's/AS, is very straightforward. It is reasonably light tool with all you need to find and resolve performance issues such as scalability, TP, footprint, DeadLocks etc.
We now started to evaluate the new goodies in version 4.x.
Good luck you guys, you can be proud with your product
I certainly do hope this version supports the possibility of filtering out method calls (from a class/package) for CPU view.
E.g. if I know it's a method that blocks on IO for a long time/idles/whatever, I really don't want to see it in CPU usage.
This was actually the only thing I missed having in the 3.something version (one of the few reasons for me to choose Borland OptimizeIT instead).