[GLASSFISH-20540] PSR:PERF Implicit CDI causing 30% performance regression Created: 16/May/13  Updated: 19/Sep/14

Status: Reopened
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Scott Oaks Assignee: Scott Oaks
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-reviewed, PSRBUG

 Description   

Micro benchmarks on EJB local session beans have regressed by 30% in current build. This is because of implicit CDI; if I set cdi-enable-implicit=false, performance reverts to previous levels.

I suspect this is a new weld integration to fix for https://java.net/jira/browse/GLASSFISH-20474 – and the memory leak is fixed, but we are left with the new performance regression.

The WeldListnener is consuming about 30% of total CPU now, particularly in the WeldListener.requestDestroy() method.



 Comments   
Comment by jjsnyder83 [ 22/May/13 ]

I'm not sure there's much we can do about this. As you stated, when you disable implicit cdi you get the same results as before. With implicit cdi enabled cdi is getting involved with the ejbs and so additional processing is happening. If cdi is not required then it should be turned off for maximum performance.

Comment by Scott Oaks [ 22/May/13 ]

I don't think "work as intended" is an accurate description – I don't think the intention of enabling CDI by default is to introduce a 30% performance regression in EJB operations.

We need to look into and optimize the Weld implementation here. If we conclude that it cannot be improved on, then we can figure out next steps. But I suspect, given the size of the penalty, that there is some optimizing we can do. I'll get PSR staff to do some initial analysis (but also, can we check with the Weld implementors and see if they are aware of this, as they were already aware of the memory leak)?

Comment by jjsnyder83 [ 22/May/13 ]

Enabling CDI causes CDI to get involved in all EJB requests so if there's a lot of EJB "action" happening then there's going to be a performance hit when CDI is involved. I agree 30% seems drastic!

It's entirely possible that Weld can improve the implementation and I'll be glad to open a Weld Jira. It would be very helpful if I could provide some more information as well as an application that when run emphasizes the performance hit...Can the PSR staff provide that info?

(btw, The weld guys were not aware of the memory leak until we pointed it out )

Comment by phil.zampino [ 24/Jun/13 ]

After a brief exchange with the Weld lead, I've filed https://issues.jboss.org/browse/WELD-1443

Comment by phil.zampino [ 26/Jun/13 ]

The associated Weld issue is scheduled to be included in Weld 2.0.3.Final





Generated at Tue Mar 31 22:11:19 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.