When you start to think about profiling Java applications, many tools come to mind - but did you think profiling could be as easy as adding logging statements? This is the goal of the Perf4j project:
Perf4J is to System.currentTimeMillis() as log4j is to System.out.println()
With this goal in mind, Perf4J provides an impressive feature list of:
- A simple stop watch mechanism for succinct timing statements.
- A command line tool for parsing log files that generates aggregated statistics and performance graphs.
- Easy integration with the most common logging frameworks and facades: log4j, java.util.logging, Apache Commons Logging and SLF4J.
- Custom log4j appenders to generate statistics and graphs in a running application (custom java.util.logging handlers coming soon).
- The ability to expose performance statistics as JMX attributes, and to send notifications when statistics exceed specified thresholds.
- A servlet for exposing performance graphs in a web application.
- A @Profiled annotation and a set of custom aspects that allow unobstrusive timing statements when coupled with an AOP framework such as AspectJ or Spring AOP.
- An extensible architecture.
InfoQ caught up with Alex Devine, a project lead on the Perf4j project, who explained how Perf4j came about:
Realizing that the problem of performance tracking and management would affect pretty much every project at our company (and, indeed, almost all server-based, distributed applications), we decided to build and productize a standard performance library, which eventually became Perf4J.
"Are there any particularly tricky performance issues that Perf4j can help solve":
Perf4J is especially well-suited for tracking down performance problems in widely distributed services-oriented applications. For example, at Homeaway a single hit on one of our search pages results in a call to the front end webserver, which makes database calls in addition to calling the search service and an ad server over HTTP. And the search service itself aggregates results from several search nodes. If performance degrades in a live production environment, it is much easier to quickly pinpoint the component at fault using Perf4j.
This lead to the next question of "can Perf4j be used in a production environment?"
Perf4J is definitely designed to be used in production environments. Indeed, often times everything looks great in staging only to crater miserably in production; having monitoring turned BEFORE a big performance hit is often crucial to tracking down the problem.
For performance overhead, Alex added:
The overhead is similar to logging, as starting and stopping a StopWatch essentially breaks down to the same thing you would do if you called System.currentTimeMillis() before and after the code to be timed and then logged it. Thus, similar to logging, the overhead ultimately depends on the appenders you have attached. The design of the AsyncCoalescingStatisticsAppender is that it just pushes the log message on a queue that is drained by downstread appenders in a separate thread, so when those downstream appenders end up doing a lot of work it won't affect the execution time of the main thread. In addition, if you are using the @Profiled annotation with load-time weaving, you can determine which methods you want to be profiled at runtime, in which case there is absolutely zero overhead for the methods that you do NOT profile.
And for what's coming next:
We want to enable runtime profiling even if the code to be profiled has no StopWatches or @Profiled annotations. That is, I want to enable developers to specify particular methods to be profiled in an aop.xml file or in a Spring application config. This would allow you, for example, to profile third party libraries that had no knowledge of Perf4J, and it completely removes all profiling statements from the source code.
Perf4j can be downloaded from http://perf4j.org.