glassfish
  1. glassfish
  2. GLASSFISH-16355

startup and footprint of larger size application deployment to 3.x

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: not determined
    • Component/s: performance
    • Labels:
      None

      Description

      Refer to this blog for description of the problem: http://ktschmidt.blogspot.com/2011/04/is-glassfish-v3-slower-and-bigger.html

      Scott Oaks confirmed that the startup time issue is valid.

      Also refer to this forum thread: http://forums.java.net/node/798503

        Issue Links

          Activity

          Hide
          Hong Zhang added a comment -

          Assign the umbrella issue to Tom. The deployment could have a sub issue of the umbrella issue.

          Show
          Hong Zhang added a comment - Assign the umbrella issue to Tom. The deployment could have a sub issue of the umbrella issue.
          Hide
          Tom Mueller added a comment -

          Not sure why this is an admin issue. Assigning it to performance.

          Show
          Tom Mueller added a comment - Not sure why this is an admin issue. Assigning it to performance.
          Hide
          Nazrul added a comment -

          Adding 3_1-next tag. We need a fix for this during 3.1.1.

          Show
          Nazrul added a comment - Adding 3_1-next tag. We need a fix for this during 3.1.1.
          Hide
          Tim Quinn added a comment -

          Linking the apparent MQ start-up regression to this more-or-less umbrella issue.

          Show
          Tim Quinn added a comment - Linking the apparent MQ start-up regression to this more-or-less umbrella issue.
          Hide
          Scott Oaks added a comment -

          Remaining different in heap usage after startup is attributable to retained gmbal-related references.

          Show
          Scott Oaks added a comment - Remaining different in heap usage after startup is attributable to retained gmbal-related references.
          Hide
          Scott Oaks added a comment -

          We are tracking a new set of tests for this in 3.1.2.

          In this set of tests (which includes one large app with multiple jars and wars, including EJBs, JSPs, MDB, etc., and one smaller web app), the heap after starting with the apps deployed in 2.1.1 consumes 41.2MB; in 3.1.2 it consumes 59.7MB. This is before an ORB is started, and hence does not include the gmbal-related references. [So that earlier comment about everything being related to gmbal is in error.] There is no load generated in this test, so lazily-initialized things will benefit the test, which may or may not be a good thing (but it follows the scenario in the posting that drives this bug).

          Where does that 18.5MB come from? Here is the short answer:
          Additional classes: 4MB
          HK2: 4MB
          Felix: 5MB
          Grizzly: 3MB
          Stats Provider: 2MB

          In a scenario like this where a significant part of the EE modules are loaded, one place we lose out is in the infrastructure for modularization. In simple terms of classes loaded, 3.1.2 is loading 11% more classes (10K vs 9K), and the class objects themselves consume 50% more heap (12M vs 8M). That is a reflection of the added features as well as the added modularization, of course.

          Then there is the memory consumed by instances of the classes. The single instance of org.jvnet.jk2.component.Habitat consumes 1.6MB of heap. However, there are are other habitats (subclasses) as well, and they are consuming at least another 1.2MB of heap (for their MultiMap) and a significant amount of memory for the LazyInhabitant objects. Total consumed by HK2 is in excess of 3.9MB.

          Instances of Felix classes consume at least 4MB of heap (not including the classes held by the Felix ModuleClassLoader). The big amounts of memory there are held by Felix ModuleImpls (again not including the inner classloader objects); memory here is consumed by CapabilityImpl, RequirementImpl, and ResolverState. I realize there is overlap between some of those classes, but the 4MB calculation in the tool will have removed that overlap, and in particular the 1.2MB of heap consumed by ResolverState appears independent of the CapabilityImpl/RequirementImpl. So without understanding the code better, I can just say that it heap usage is between 4 and 5.2MB (or bigger).

          Grizzly processorTasks consume 3.1MB more heap.
          In 2.1.1, the three processor tasks queues consume 2.25MB of heap
          In 3.1.2, the there five processor tasks queues consuming 5.3MB of heap
          This is a default-configured domain

          Stats Provider Registry consumes 2MB of heap

          Show
          Scott Oaks added a comment - We are tracking a new set of tests for this in 3.1.2. In this set of tests (which includes one large app with multiple jars and wars, including EJBs, JSPs, MDB, etc., and one smaller web app), the heap after starting with the apps deployed in 2.1.1 consumes 41.2MB; in 3.1.2 it consumes 59.7MB. This is before an ORB is started, and hence does not include the gmbal-related references. [So that earlier comment about everything being related to gmbal is in error.] There is no load generated in this test, so lazily-initialized things will benefit the test, which may or may not be a good thing (but it follows the scenario in the posting that drives this bug). Where does that 18.5MB come from? Here is the short answer: Additional classes: 4MB HK2: 4MB Felix: 5MB Grizzly: 3MB Stats Provider: 2MB In a scenario like this where a significant part of the EE modules are loaded, one place we lose out is in the infrastructure for modularization. In simple terms of classes loaded, 3.1.2 is loading 11% more classes (10K vs 9K), and the class objects themselves consume 50% more heap (12M vs 8M). That is a reflection of the added features as well as the added modularization, of course. Then there is the memory consumed by instances of the classes. The single instance of org.jvnet.jk2.component.Habitat consumes 1.6MB of heap. However, there are are other habitats (subclasses) as well, and they are consuming at least another 1.2MB of heap (for their MultiMap) and a significant amount of memory for the LazyInhabitant objects. Total consumed by HK2 is in excess of 3.9MB. Instances of Felix classes consume at least 4MB of heap (not including the classes held by the Felix ModuleClassLoader). The big amounts of memory there are held by Felix ModuleImpls (again not including the inner classloader objects); memory here is consumed by CapabilityImpl, RequirementImpl, and ResolverState. I realize there is overlap between some of those classes, but the 4MB calculation in the tool will have removed that overlap, and in particular the 1.2MB of heap consumed by ResolverState appears independent of the CapabilityImpl/RequirementImpl. So without understanding the code better, I can just say that it heap usage is between 4 and 5.2MB (or bigger). Grizzly processorTasks consume 3.1MB more heap. In 2.1.1, the three processor tasks queues consume 2.25MB of heap In 3.1.2, the there five processor tasks queues consuming 5.3MB of heap This is a default-configured domain Stats Provider Registry consumes 2MB of heap
          Hide
          Scott Oaks added a comment -

          The extra classes contribute as well to the regression in the time to restart the server: they cause a few expansions of the perm gen as it fills up with the extra classes.

          In 2.1.1, a server restart with the EJB apps deployed goes through one resizing of permgen on my laptop; in 3.1.2, there are three or four. If we increase the initial size of perm gen (keeping the max size at 192m), we can improve the server restart in this scenario by 11%. But that will affect the footprint of other smaller deployments, so some discussion on the trade-offs here needs to occur.

          Show
          Scott Oaks added a comment - The extra classes contribute as well to the regression in the time to restart the server: they cause a few expansions of the perm gen as it fills up with the extra classes. In 2.1.1, a server restart with the EJB apps deployed goes through one resizing of permgen on my laptop; in 3.1.2, there are three or four. If we increase the initial size of perm gen (keeping the max size at 192m), we can improve the server restart in this scenario by 11%. But that will affect the footprint of other smaller deployments, so some discussion on the trade-offs here needs to occur.
          Hide
          Joe Di Pol added a comment -

          We won't be making any more progress on this for 3.1.2 so I'm excluding from the release. We did get a gmbal fix into Metro that helps WS applications, but not EJB. The ORB fix has proven more difficult (see linked gmbal bug).

          Show
          Joe Di Pol added a comment - We won't be making any more progress on this for 3.1.2 so I'm excluding from the release. We did get a gmbal fix into Metro that helps WS applications, but not EJB. The ORB fix has proven more difficult (see linked gmbal bug).
          Hide
          Tom Mueller added a comment -

          Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          Show
          Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

            People

            • Assignee:
              Scott Oaks
              Reporter:
              Nazrul
            • Votes:
              6 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: