PerfSpy 1 -- runtime logging and performance monitoring using AspectJ

PerfSpy is an open source tool (https://code.google.com/p/perfspy/). It enables runtime logging and runtime performance monitoring for Java applications using AspectJ: it has an abstract Aspect, with which you can specify an “entry” method, and it will capture all method invocations within that “entry” method. It uses NetBeans OutlineView tree control to show the method invocations and offers convenient ways to navigate through the method invocation tree.  

In this tutorial, I used two Demo applications: PerfSpyDemo and PerfSpyAspectDemo, you can pick them up from https://code.google.com/p/perfspy/.

You probably think your system is something like this:

In this beautiful diagram, every block does one thing terrifically well, and blocks are put together and communicate with each other through well-defined communication channels. The whole structure is robust, flexible (you can move blocks here and there), and extensible (you can put add more blocks) etc.

But in reality, your system might look like this:

And you feel like that hapless little mice: every time you turn, there are more unexpected nooks and corners, and even death traps. At times like this, you wish there is a thread that can guide you through the maze and remember all the twists that you’ve passed through.

PerfSpy is to give you such a string to expose the maze-like structure of your system to you.

Let me tell you a little bit of my system, so you will understand why I started out to write this tool. The system I was charged in maintaining was written more than 15 years ago. It is a “J2EE” application deployed onto JBoss 4.0. It has two parts: web part (runs on Tomcat 5.5) and Swing part (can be run as Applet). Over the years, technology involved. And Spring, Hibernate, Ajax etc were added into the system, yet old infrastructure stayed in place, and new technologies were simply layered upon the old one. So now, the system has 3 connection pools (all connecting to a single DB), 3 kinds of transaction mechanism, 2 types of cluster communication channels, etc. This is a big picture of the structure of the system:

The big house is JBoss 4.0. For some reason, JBoss 4.0 was tweaked in some mysterious ways, which makes it hard to upgrade to JBoss. So already, the house was not built very strongly (hence it is raining). The two small houses are two web applications deployed onto JBoss – the system is one single web application, and yet there are two WARs. One house is much smaller, and serves a small purpose. Every single page has to be served by two houses. Among other things, this adds complexity to “Jar hell”: some jars have to be placed in A.war, some in B.war, some have to be placed onto the top of the Jboss roof. Not to mention the complex interactions between A.war and B.war.   

Thanks to PerfSpy, I was able to understand all the tweaks involved in making A.war and B.war talk to each other in a short period of time. 

Understanding the system is a daunting task enough, let along refactor it. And yet, short of discarding the system altogether, refactoring it is the only way to avoid it being sunset. First step of refactoring is to understand the system – PerfSpy was born out of this necessity.

You can also use PerfSpy to understand your system’s performance bottleneck. By default, it logs the execution time of every method and how many times of a method is repeatedly invoked. This information will give you a clue as to the performance bottleneck.