Tuesday, July 06, 2010


I moved this blog to a new location.


Thanks for visiting!

Friday, February 10, 2006

J2EE Lite with Spring Framework - Performance

When I submitted this post to JDJ for publication, the editor was a bit charry about posting my performance analyisis that followed the article logically. So I thought, this may be a good place to continue that discussion.

First.. Here is the article that is available on the JDJ website:
And here is a downloadable webapp that is a standalone Spring application. (Click on the link titled "Additional Code II" for the complete downloadable artifact).

Just as a tickler tho'... the webapp (made2order) shows the following services built using Spring IoC and AOP:

The webapp is (almost) completetly self contained, in that it will work when deployed to a webapp server (like Tomcat); the only external system properties that need to be supplied are database driver, url, user and password.
The source code for this application is also available in the zip.

Now that we have seperated infrastructure code from business code, we can look at what is the price paid for interjecting the same services using EJBs, if any.
So I created an Stateless Session EJB that provided transactional semantics via declarative transaction management and CMT.
Similarly I created a Transactional Spring Proxy. I facaded the same business method (that UPDATEd a database table) with both the Spring proxy and the SLSB.
Then I accessed that SLSB via a JNDI lookup and looped the remote instance 300 times.
Compared that with the Spring Proxy and similarly iterated 300 times.

For 300 iterations of the UPDATE, here are the results:

The results of the test shows that the proxy out-performs EJB every time although, not by much. Note that the proxy has more interceptors than just Transactions (5 others) whereas the EJB is only providing us Transaction Services (in this use case). Also note that when the SLSB was accessed via a Spring Bean Factory, and the same test was run, there was no significant difference in the results.

Performance of Hard-coded Logging statements vs Logging via and Advised Proxy:
The following test was executed to see the slow down in performance of a proxied logging advice versus hard-coded Log statements.

It was seen that for 300 iterations, the advised methods took 6 to 9 milliseconds longer to produce the same output. While the proxy is certainly slower, we have to take into consideration the benefits of a declarative approach compared to relying on developer discipline to code the Log statements.

Those are just the facts, (ma'am :)) The rest is interpretation.. I'll leave that to more experienced folks to comment on..