Hi Katherine,

I've created a tracking issue for this - WELD-1931.

I suppose that your application is not publicly available, is it? It would be great if we can analyze the entire HTTP request lifecycle and the application setup.

Hi Katherine,

What container do you use? Recently, we've made some improvements in this area but it did not make a big difference compared to the overall overhead of HTTP requests processing (our test container was WildFly).

Hi Martin/Jozef,

You might be interested in knowing the performance testing among different application servers.

Just in case the performance problem we reported is to do with the application server Liberty Profile.

We downloaded eebench (https://github.com/struberg/eebench) and compared Glassfish 4.1, Wildfly 8.2 (Weld) to TomEE (OWB). As a matter of fact, Liberty profile performs a lot of better than Glassfish and Wildfly but it is not as fast as TomEE.

(with Oracle JDK)

TomEE 1.7.2                      1079

Glassfish 4.1                      151   - 86%

Wildfly 8.2                           167  -84%

------------

This seems to be taking a big chunk of time in WELD:

Hope this information can help you identify the bottleneck.

Hi Emily,

thanks for your tips. It would be nice if you add some description to the numbers you provided (and better formatting would help as well). With regard to eebench - first of all, the test for CDI also involves other EE technologies (JSF, EL, etc.). So the results are more relevant to the performance of the JSF/CDI stack. It's also also targeted for one feature only - bean invocation. E.g. it does not test events, bean instance construction, producers, etc. And also remember that you should warmup JVM before you run the test.

Hi Martin,

Sorry for the slow response due to holidays! To answer your questions:

1. This test was done with a warmup JVM

2. eebench does test other stuff, but the profiles clearly show CDI is the issue here.

3.  

This java profile numbers below how much time (in percentage) the following methods are taking during a run of the eebench benchmark.

The method org/jboss/weld/bean/proxy/ProxyMethodHandler.getInstance() (and methods it calls) are taking 21.97% of the time. The ProxyMethodHandler.getInstance() method itself is taking 11.86% of the time, and its childs methods take ~10.11% of the time.

Parent 0 0.03 0.03 6 6 J:org/apacheextras/eebench/cdibench/beans/MethodInterceptedBean$Proxy$_$$_WeldClientProxy.getMeaningOfLife()Ljava/lang/Integer;

  Parent 0 0.05 0.05 9 9 J:org/apacheextras/eebench/cdibench/beans/ClassInterceptedBean$Proxy$_$$_WeldClientProxy.getMeaningOfLife()Ljava/lang/Integer;

  Parent 0 2.48 2.48 428 428 J:org/apacheextras/eebench/cdibench/beans/SimpleApplicationScopedBeanWithoutInterceptor$Proxy$_$$_WeldClientProxy.theMeaningOfLife()I

  Parent 0 5.69 5.69 984 984 J:org/apacheextras/eebench/cdibench/beans/MethodInterceptedBean$Proxy$_$$_WeldClientProxy.getMeaningOfHalfLife()Ljava/lang/Integer;

  Parent 0 3.60 13.72 622 2370 J:org/apacheextras/eebench/cdibench/beans/SimpleRequestScopedBeanWithoutInterceptor$Proxy$_$$_WeldClientProxy.theMeaningOfLife()I

  Self 0  11.86 21.97 2049 3797 J:org/jboss/weld/bean/proxy/ProxyMethodHandler.getInstance()Ljava/lang/Object;

  Child 0 1.39 10.12 241 1748 J:org/jboss/weld/bean/proxy/ContextBeanInstance.getInstance()Ljava/lang/Object;

Thanks,

Emily

Ok Emily, thanks for info. I tried to run the "benchmark" on WildFly master and I can see a little bit different numbers. First of all, the most consuming part is JSF, namely javax.faces.webapp.FacesServlet.service() (self time) and com.sun.faces.application.view.FaceletViewHandlingStrategy.getSession() - note that a new HTTP session is created for every HTTP request made by jmeter. CdiBenchBean.getState() logically also takes a lot of time, namely intercepted methods ClassInterceptedBean.getMeaningOfLife() and MethodInterceptedBean.getMeaningOfLife() or the interceptor stack itself respectively. We did a lot of optimizations in this area but we have limited possibilities due to the way Weld implements client proxies - i.e. subclassing. Anyways, thanks for sharing your findings!

Thank you Martin for your quick response! I understand the subclassing is the thing to be blamed. If we cannot improve subclassing performance, how about exploring ASM?

how about exploring ASM?

Emily, what exactly do you mean?

I was commenting on your comments:

"We did a lot of optimizations in this area but we have limited possibilities due to the way Weld implements client proxies - i.e. subclassing."

As Weld uses its own subclassing approach to create client proxies, do you think it will improve if the client proxy was generated by using ASM?

Weld is using jboss-classfilewriter to generete the bytecode, a tool similar to ASM. However, subclassing is rather a question of concept or implementation design. It would require a massive refactoring and I'm not so sure it's worth it.