glassfish
  1. glassfish
  2. GLASSFISH-20540

PSR:PERF Implicit CDI causing 30% performance regression

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_b89_RC5
    • Fix Version/s: 4.1
    • Component/s: cdi
    • Labels:
      None

      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.

        Activity

        Scott Oaks created issue -
        Hide
        jjsnyder83 added a comment -

        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.

        Show
        jjsnyder83 added a comment - 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.
        jjsnyder83 made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Works as designed [ 7 ]
        Hide
        Scott Oaks added a comment -

        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)?

        Show
        Scott Oaks added a comment - 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)?
        Scott Oaks made changes -
        Resolution Works as designed [ 7 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee jjsnyder83 [ jjsnyder83 ] Scott Oaks [ sdo ]
        Hide
        jjsnyder83 added a comment -

        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 )

        Show
        jjsnyder83 added a comment - 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 )
        jjsnyder83 made changes -
        Fix Version/s 4.0.1 [ 16061 ]
        Hide
        phil.zampino added a comment -

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

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

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

        Show
        phil.zampino added a comment - The associated Weld issue is scheduled to be included in Weld 2.0.3.Final
        tlcksnyder made changes -
        Tags PSRBUG 4_0_1-review PSRBUG
        alan42 made changes -
        Tags 4_0_1-review PSRBUG PSRBUG
        alan42 made changes -
        Tags PSRBUG 4_0_1-reviewed PSRBUG
        Romain Grécourt made changes -
        Fix Version/s 4.1 [ 16387 ]
        Fix Version/s 4.0.1 [ 16061 ]
        Hide
        jjsnyder83 added a comment -

        Should be fixed by upgrade to Weld 2.2.10.SP1 which happened a few weeks ago.

        Show
        jjsnyder83 added a comment - Should be fixed by upgrade to Weld 2.2.10.SP1 which happened a few weeks ago.
        jjsnyder83 made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Scott Oaks
            Reporter:
            Scott Oaks
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: