Adam Bien's Weblog

Tuesday Dec 13, 2011

What Is The @Interceptors Overhead?

The RESTful EJB 3.1 InterceptedHelloService:


@Path("intercepted")
@Interceptors({LoggingInterceptor.class,AnotherInterceptor.class})
@Stateless
@Produces(MediaType.TEXT_PLAIN)
public class InterceptedHelloService {
    @GET
    public String call(){
        return System.currentTimeMillis() + " ";
    }    
}

is intercepted with two, empty, interceptors:

public class AnotherInterceptor {
    @AroundInvoke
    public Object intercept(InvocationContext ic) throws Exception{
        return ic.proceed();
    }
}

public class LoggingInterceptor {
    @AroundInvoke
    public Object intercept(InvocationContext ic) throws Exception{
        return ic.proceed();
    }
}


The execution overhead is compared to a plain EJB 3.1 without any interception:

@Path("plain")
@Stateless
@Produces(MediaType.TEXT_PLAIN)
public class PlainHelloService {
    @GET
    public String call(){
        return System.currentTimeMillis() + " ";
    }
}

…and the results are:
TypeAverageMinMaxTransactions/Sec
Plain EJB 3.11082833.66
Intercepted EJB 3.11092818.88

Even applying two interceptors on a @Stateless EJB 3.1 does not make a significant performance impact. In worst case the performance difference is 1 ms and so negligible.

The tests were performed with JDK 1.6.0_29-b11 and Glassfishv3.1.1 without any modifications.The project InterceptorOverhead together with JMeter load script was pushed into: http://kenai.com/projects/javaee-patterns/


NEW workshop: Microservices with Java EE 7 and Java 8, January 26th, 2015, Airport Munich

A book about rethinking Java EE Patterns

Comments:

I assume you did the load test with JMeter issuing HTTP GET. Then the majority of the time will be spent in the network stack and HTTP protocol. Considering this the overhead is small. If you compare just the method call you will find a significant performance impact. That is why I would not recommend these approaches for domain objects for example that are called much more frequently. For transactions, security, services and coarse grained objects the approach is fine, of course.

Posted by Eberhard Wolff on December 13, 2011 at 01:24 PM CET #

Adam, is it not possible that a good compiler/runtime could recognise that there is no body in the interceptor and thus remove it.

Bought the two books last month; very impressive.

Posted by Steve Lindsey on December 13, 2011 at 01:33 PM CET #

Some time ago I did Interceptor benchmark (Weld, EJB and no interceptor).

The results:
https://issues.jboss.org/brows/WELD-864

Posted by wojtask9 on December 19, 2011 at 02:42 PM CET #

wojtask9, your link is broken.

Posted by Anton Lisovenko on December 20, 2011 at 11:52 PM CET #

sorry.
https://issues.jboss.org/browse/WELD-864

i missed one letter :/

Posted by wojtask9 on December 23, 2011 at 02:02 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
License