Developer

JProbe Profiler: The perfect profiling tool?

Sitraka's JProbe Profiler is a wonderful performance-monitoring tool, but is it worth the steep licensing fee? Find out what it has to offer and whether it might be a good option for your development arsenal.


So you've written a cool application or Web site in Java, but it seems to be running slowly. Despite what some developers will tell you, speed and Java don’t have to be mutually exclusive. You just need to figure out how to speed things up. Unfortunately, the big problem with optimization isn't speeding up the slow part—it's finding the slow part in the first place! That's where JProbe Profiler can help.

JProbe Profiler, a Java application created by Sitraka, can help you find bottlenecks and inefficiencies in your code by running and monitoring a heavily instrumented version of your app’s byte code. With pricing starting at $649, it's likely not the cheapest weapon in a Java developer's arsenal, but it may be the most indispensable.

Sitraka JProbe Profiler

$649 and up

Highs:
Optional text-only installation
Live or offline remote display
Powerful UI
Data export functionality


Lows:

Clunky licensing system
Live remote display requires shared drive space
Inability to completely ignore a method after a snapshot has been taken



Although Java is slowly gaining ground in the desktop applications space, it still finds its greatest use in server-side software, and Sitraka took this into account when creating JProbe. The product installer has two versions, one with a graphical interface and one without. The latter is useful when your application server is running on a remote box to which you have only terminal access, and I found it to be a nice touch.

The first step to getting JProbe up and running is the creation of the snapshot capture settings files, also known as .jpl files. These files specify the classes and methods that should have their execution timed and scrutinized, and they can be created only by using the graphical wizard built into the JProbe console. I found this odd restriction to be a real nuisance since the system I’m monitoring happens to be a remote system that I can access only in text mode. The only solution I found was to create the .jpl file on a local graphical machine and then transfer it to the remote server.

JProbe can integrate with many popular app servers including IBM's Web Sphere, JBoss, Tomcat, and Resin. Missing is integration with Mort Bay's Jetty HTTP Servlet Container, the default servlet container within JBoss. It isn't supported in its stand-alone capacity, which may be a bad thing depending on your shop’s setup.

Features are excellent overall…
During an instrumented program execution, JProbe’s Analysis Engine carefully records the time spent in and the number of objects created by each method. JProbe’s data can be viewed in real time or from a saved snapshot file sometime later in a graphical console. These snapshot files are created automatically when the application or server being monitored exits and can be created more frequently as configured in the .jpl file.

It’s the job of the JProbe graphical console to take the copious amounts of data collected by the Analysis Engine and put it into a format you can make sense of. It largely succeeds in this task: The user interface is extremely powerful. Within the main window for each snapshot are two different and complementary views of the data gathered by the Analysis Engine. Figure A shows the display of an execution snapshot.

Figure A


The top half of the display contains the method call graph, which shows the relative execution times of each method call through intuitive color-coding. In this case, the bright-red coloration of the encodeAsPng method shows that more time was spent in this method than any other during this particular execution. Hovering the mouse over a box reveals the percentage of total execution time that was spent in that method. In this case, encodeAsPng ate up 74.4 percent of the program execution time, making it a very likely candidate for optimization.

The lower half of the display shows the same timing information found in the call graph in a tabular format. The lower display can be sorted in a number of ways and even exported to spreadsheet-compatible formats for further external analysis. In addition to method timings, both views can be used to display object instantiation counts, which can be used to explain inordinately slow methods, and can help identify the indirect cause of excessive garbage-collection delays.

…But still not perfect
Though very powerful, the snapshot display leaves a little to be desired. Most notably, there's no way to eliminate a method from consideration in the timing percentages after a snapshot has been made. For instance, if an application spends 99 percent of its time waiting in a Socket.accept call for new TCP connections, you can eliminate that method from the display graph, but JProbe won’t recalculate the percentages for the other methods. As a result, you’re left comparing 0.5 percent to 0.05 percent timings to find their relative magnitudes. You can always exclude a method from the timing percentages by configuring the .jpl settings file to avoid tabulating that method's execution, but that means rerunning the application to generate a new snapshot. There should be an easier alternative.

A really nice feature of JProbe is that you can run its graphical console on your local machine while the Analysis Engine is running and monitoring code on a remote server. The only downside is that this live remote display requires not only a TCP connection to the remote machine but also shared network disk space of the type provided by NFS or SMB. This requirement takes some of the shine away from what is otherwise a very nice feature and hints that it might have been a bolt-on afterthought rather than an initial design goal.

If your patience or corporate network security policy prevents you from setting up shared disk space between the two machines, you still have the option of transferring analysis snapshot files from the server machine to your local machine for inspection using the JProbe graphical console.

Licensing system is apt to annoy
However, before you can run JProbe and enjoy all of its great features, you must deal with its irksome licensing system. Obtaining a license involves sharing some machine-identifying information with Sitraka. The company then e-mails you a license file.

Ten-day evaluation licenses are available for free from the Sitraka Web site in exchange for filling out a questionnaire. Permanent licenses have various price ranges, come with various levels of restrictions, and collect more information from the host machine. On the budget end of the scale, you can purchase a single-user, single-host, nonexpiring license for $649, while a floating license system with an associated license server is available at the high end of the price spectrum.

All in all, I found JProbe to be an excellent performance analysis tool with some great features. It has a few annoying quirks and a rather high price tag. Still, JProbe is a useful tool that's worth consideration.

Editor's Picks