April 0.2 Application Performance Framework

April (Application Performance Framework) is a super-light application framework based on Spring, featuring:

• An Aspect Oriennted Programing Performance Monitor, which try to increase performance on the fly
• A super-light XML-RPC communication framework

April first commitment is "be lite, be pluggable" and do not re-invent the wheel. I am happy to describe here how it works the Beta 0.2, called "Fat Cat" by friends.

Getting Started with April

April is a self-contained package, you can download here:

[download id="3"]

April project has been developed under Eclipse Ganymede, which is higly recommended. Anyway an ant build script is provided.

The project binary results in a webapp (war) you can deploy under your preferred application server.

How it works

The april demo is composed of a FileMonitor utility used to monitor file changes across a file system.

The core of April is the PerformanceMonitor, which is an aspect configured via Spring: take a look to the aopMonitor.xml located under april/war/WEB-INF/spring/ folder.

The performance monitor will start measuring the performance of every methods defined in the pointcut. When one method is too slow, the Performance Monitor will check if the method belongs to a class implementing the "AutoTune" interface.

If the AutoTune interface is implemented, the PerformanceMonitor will ask to the object if it can be opttimized via a call to

[java]public boolean canBeOptimized();[/java]

If the method returns true, Performance Monitor will begin the optimization phase.

The optimization phase

The Performance monitor will invoke the following method of the AutoTune interface

[java]public Runnable split() throws Exception[/java]

Is up to the implementation to return a new runnable object, which will do a part of the work. The returned object need not to be of the same type of the AutoTune implementor  (ATI).

The idea behind

The idea is to find bottleneck based on how much time a method takes to run. The monitor then asks to a slow instance to spawn another thread.

This approach cannot solve every issue, but it seems effective on some scenarios, because it can "follow"  the bottlenecks when they change position.

The call is performed before the return statement of the "slow" method, and a global lock is used to guarantee only one spawn request at the time.

The post-optimization phase (speculation)

This phase is fired via the AutoTune method

public void mergeWith(AutoTune candidate2);

but it is still unfinished and unstable, so it is disabled for the meantime. I am evaluting different approaches, and every comment is welcome.

Do you like April? Do you have an idea for improving it? Leave a comment below!

Release History

• April 0.2 is the first full english release.
• April 0.1 was a "request for comments" release, published in this italian article. It was released on April 8th , 2009