Every application needs to log performance benchmarks in order to identify bottlenecks and show improvements with each deployment iteration. Talking vaguely about where performance is drained are or perceived improvements since a particular deployment surrenders the development effort to subjectivity.
When I decided that my efforts to improve performance in an application I was responsible for cannot be left to the vagaries of uninformed perceptions, I decided to deploy a comprehensive monitoring tool. But I also need something that was fit for purpose and would not impose a heavy burden on existing architecture.
I did some research before hand, and I recommend this article (Java run-time monitoring, Part 1: Run-time performance and availability monitoring for Java systems) from IBM DeveloperWorks for a good fundamental understanding of performance monitoring concepts.
For my implementation, I opted for Perf4J, as it presented me with the least amount of impact on existing software architecture and imposed no additional requirements before deployment. I already had Log4J as my primary logging framework.
The documentation describes how to configure logging Perf4J on Log4J's XML config file, which was not an option for me since I already had an elaborate properties file and I was not willing to migrate to the XML config file. This is where I struggle for a while, but I eventually found the solution on configuring the log4j properties file for Perf4J.
The solution is to configure logging threads on the properties file, one of them being the logger you want assigned to Perf4J (see line 6 of log4j.properties listing). On the Java code, use the Log4JStopWatch instance and provide it with the thread logger defined in the properties file (see line 10 of MyPerformanceMonitor.java listing).
