glassfish
  1. glassfish
  2. GLASSFISH-18693

[PERF] regression in startup/deployment benchmark

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 4.0_b01
    • Fix Version/s: 4.0_b87_RC3
    • Component/s: performance
    • Labels:
      None

      Description

      Startup & deployment show 12% regression from the very beginning of GF 4.0. Collector analyzer profiles indicate GF 4.0 loads more classes now.
      Recently regression increased to 18%, we have found that when we remove modules/org.apache.felix.bundlerepository.jar regression dips back to 12%.

        Issue Links

          Activity

          Hide
          Tom Mueller added a comment -

          This issue represents the overall work that is being done to reduce the regression in the devx_web benchmark for the 4.0 release. Here is a summary of the accomplishments that have been achieved:

          Feb 18, regression is about 50%
          Mar 1, asadmin client rewrite to not use Jersey client, regression down to about 38%
          Mar 5, StartupConfigBeanOverrider removed (19719, rev 60061), regression down to 36%
          Mar 7, asadmin hk2 bypass (issue 19778, rev 60182), regression down to 30%
          Mar 11, enhancement to hk2 bypass to limit CLICommand JAR files (rev 60355), regression at 30%
          Mar 14, hk2 fix for 19718, uptake of felix 4.2.1, regression down to 22%
          Mar 26, admin-cli.jar not activated, regression down to 21%
          Apr 5, delay concurrent initialization until used rather than at startup, regression down to 20%
          Apr 9, delete monitoring initialization, regression down to 18%
          Apr 14, eliminated extra domain.xml writes, regression still at 18%
          Apr 15, multi-threaded service startup, regression down to 15%
          Apr 23, setting server startup threading to single threaded, regression back to 17.5%

          Any final work on devx_web improvements will be done with more specific issues. Look for the devx_web tag on the issues.

          Marking this issue as resolved for 4.0.

          Show
          Tom Mueller added a comment - This issue represents the overall work that is being done to reduce the regression in the devx_web benchmark for the 4.0 release. Here is a summary of the accomplishments that have been achieved: Feb 18, regression is about 50% Mar 1, asadmin client rewrite to not use Jersey client, regression down to about 38% Mar 5, StartupConfigBeanOverrider removed (19719, rev 60061), regression down to 36% Mar 7, asadmin hk2 bypass (issue 19778, rev 60182), regression down to 30% Mar 11, enhancement to hk2 bypass to limit CLICommand JAR files (rev 60355), regression at 30% Mar 14, hk2 fix for 19718, uptake of felix 4.2.1, regression down to 22% Mar 26, admin-cli.jar not activated, regression down to 21% Apr 5, delay concurrent initialization until used rather than at startup, regression down to 20% Apr 9, delete monitoring initialization, regression down to 18% Apr 14, eliminated extra domain.xml writes, regression still at 18% Apr 15, multi-threaded service startup, regression down to 15% Apr 23, setting server startup threading to single threaded, regression back to 17.5% Any final work on devx_web improvements will be done with more specific issues. Look for the devx_web tag on the issues. Marking this issue as resolved for 4.0.
          Hide
          Tom Mueller added a comment -

          MonitoringBootstrap changes committed to the trunk in revision 61250.

          Show
          Tom Mueller added a comment - MonitoringBootstrap changes committed to the trunk in revision 61250.
          Hide
          michael.y.chen added a comment -

          The dev perf benchmark is one of the release criteria, so this bug is approved.
          It doesn't mean all issues with devx_web are approved, other issues will be evaluated before approval.

          Show
          michael.y.chen added a comment - The dev perf benchmark is one of the release criteria, so this bug is approved. It doesn't mean all issues with devx_web are approved, other issues will be evaluated before approval.
          Hide
          Tom Mueller added a comment -
          • What is the impact on the customer of the bug?

          How likely is it that a customer will see the bug and how serious is the bug?
          Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
          What CTS failures are caused by this bug?

          This is a regression from the 3.x release and this is a PRD release criteria.

          • What is the cost/risk of fixing the bug?

          How risky is the fix? How much work is the fix? Is the fix complicated?

          Potentially very risking and very costly. See this analysis page for details:
          http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Developer+Scenario+Performance+Analysis (internal link)

          • Is there an impact on documentation or message strings?
            No
          • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
            Pretty much everything as these performance fixes could touch all area.
          • Which is the targeted build of 4.0 for this fix?
            Every build until the regression is addressed.
          • If this an integration of a new version of a component from another project,
            what are the changes that are being brought in? This might be list of
            Jira issues from that project or a list of revision messages.
            n/a.

          Note: this bug is primarily an umbrella bug for the overall effort to address the performance issue. So many changes will be made using other issues tagged with the devx_web tag.

          Show
          Tom Mueller added a comment - What is the impact on the customer of the bug? How likely is it that a customer will see the bug and how serious is the bug? Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)? What CTS failures are caused by this bug? This is a regression from the 3.x release and this is a PRD release criteria. What is the cost/risk of fixing the bug? How risky is the fix? How much work is the fix? Is the fix complicated? Potentially very risking and very costly. See this analysis page for details: http://aseng-wiki.us.oracle.com/asengwiki/display/GlassFish/Developer+Scenario+Performance+Analysis (internal link) Is there an impact on documentation or message strings? No Which tests should QA (re)run to verify the fix did not destabilize GlassFish? Pretty much everything as these performance fixes could touch all area. Which is the targeted build of 4.0 for this fix? Every build until the regression is addressed. If this an integration of a new version of a component from another project, what are the changes that are being brought in? This might be list of Jira issues from that project or a list of revision messages. n/a. Note: this bug is primarily an umbrella bug for the overall effort to address the performance issue. So many changes will be made using other issues tagged with the devx_web tag.

            People

            • Assignee:
              Tom Mueller
              Reporter:
              amitagarwal
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: