Analysing the performance degradation/improvements of a Java EE application with interceptors
When you are developing a Java EE application with certain performance requirements, you have to verify that these requirements are fulfilled before each release. An Hudson job that nightly executes a bunch of test measurements on some specific hardware platform is what you may think about.
You can check the achieved timings and compare them with the given requirements. If the measured values deviate from the requirements too much, you can either break the build or at least send an email to the team.
But how do you measure the execution time of your code? The very first thought might be to add thousands of insertions of time measuring code into your code base. But this is not only a lot of work, but also has an impact on the performance of your code, as now the time measurements are also executed in production. To get rid of the many insertions you might want to leverage an aspect oriented framework (AOP) that introduces the code for time measurements at compile time. Using this way you have at least two versions of your application: the one with and the one without the additional overhead. To measure performance at some production site still requires a redeployment of your code. And you have to decide which methods you want to observe already at compile time.
Java EE comes therefore with an easy to use alternative: Interceptors. This is were the inversion of control pattern plays out its advantages. As the Application Server invokes your bean methods/web service calls, it is easy for it to intercept these invocations and provide you a way of adding code before and after each invocation.
Using interceptors is then fairly easy. You can either add an annotation to your target method or class that references your interceptor implementation or you can add the interceptor using the deployment descriptor:
@Interceptors(PerformanceInterceptor.class)
public class CustomerService {
...
}The same information supplied in the deployment descriptor looks like this:
<interceptor-binding>
<target-name>myapp.CustomerService</target-name>
<interceptor-class>myapp.PerformanceInterceptor.class</interceptor-class>
</interceptor-binding>The interceptor itself can be a simple POJO class with a method that is annotated with @AroundInvoke and one argument:
@AroundInvoke
public Object measureExecutionTime(InvocationContext ctx) throws Exception {
long start = System.currentTimeMillis();
try {
return ctx.proceed();
} finally {
long time = System.currentTimeMillis() - start;
Method method = ctx.getMethod();
RingStorage ringStorage = RingStorageFactory.getRingStorage(method);
ringStorage.addMeasurement(time);
}
}Before the try block and in the finally block we add our code for the time measurement. As can be seen from the code above, we also need some in-memory location where we can store the last measurement values in order to compute for example a mean value and the deviation from the mean value. In this example we have a simple ring storage implementation that overrides old values after some time.
But how to expose these values to the world outside? As many other values of the Application Server are exposed over the JMX interface, we can implement a simple MXBean interface like shown in the following code snippet:
public interface PerformanceResourceMXBean {
long getMeanValue();
}
public class RingStorage implements PerformanceResourceMXBean {
private String id;
public RingStorage(String id) {
this.id = id;
registerMBean();
...
}
private void registerMBean() {
try {
ObjectName objectName = new ObjectName("performance" + id + ":type=" + this.getClass().getName());
MBeanServer platformMBeanServer = ManagementFactory.getPlatformMBeanServer();
try {
platformMBeanServer.unregisterMBean(objectName);
} catch (Exception e) {
}
platformMBeanServer.registerMBean(this, objectName);
} catch (Exception e) {
throw new IllegalStateException("Problem during registration:" + e);
}
}
@Override
public long getMeanValue() {
...
}
...
}Now we can start the jconsole and query the exposed MXBean for the mean value:
Writing a small JMX client application that writes the sampled values for example into a CSV file, enables you to later on process these values and compare them with later measurements. This gives you an overview of the evolution of your application’s performance.
Conclusion
Adding dynamically through the deployment descriptor performance measurement capabilities to an existing Java EE application is with the use of interceptors easy. If you expose the measured values over JMX, you can apply further processing of the values afterwards.
| Reference: | Analysing the performance degradation/improvements of a Java EE application with interceptors from our JCG partner Martin Mois at the Martin’s Developer World blog. |
