glassfish
  1. glassfish
  2. GLASSFISH-18021

[PERF]jsp / el integration causes performance regression in startup benchmark

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2_b13
    • Fix Version/s: None
    • Component/s: web_container
    • Labels:
      None

      Description

      The performance team noticed that B13 showed a ~2% performance regression from B12 in the web profile startup benchmark.

      Testing on a number of intermediate builds indicated the following:

      Revision 51201: 8.12 secs
      Revision 51203: 8.31 secs
      (51202 was a trunk revision)

      This seems to indicate the following check-in caused the regression:

      Project:    glassfish
      Repository: svn
      Revision:   51203
      Author:     kchung
      Date:       2011-11-30 17:33:36 UTC
      Link:       
      
      Log Message:
      ------------
      Integrate jsp and el.  Remove javaee-api/javax.servlet.jsp
      

        Activity

        Hide
        kchung added a comment -

        Scott Oaks commented on 12/17/2011:

        "I would guess that the compilation itself is not the issue, because we only see a regression for the first deployment and access – when we redeploy and access, the times are the same before and after the JSP integration."

        Kin-man commented on 12/28/2011:

        "The only thing I can think of is that jsp api and el api classes were repackaged into one jar file, but now they remain as two separate jars."

        Scott 12/28/2011:
        "Yes; it is additional disk access and parsing of a manifest plus dependencies. Maybe not enough to account for the entire regression, but at least part of it (and the entire regression we're tracking down here is only a few hundred milliseconds...)

        How easy would it be for you to package the module back as one jar file so we can drop it into build 15 and test the difference? Then we'd know if it is that, or something else."

        Kin-man 1/5/2012:
        "Dhiru and I agreed that it'll make more sense to keep jsp api and el api separate, but instead, to combine the api with the corresponding implementations. I've used the same group and artifact id, so the new jars can be dropped into<GF>/modules directory.

        Attached are the 3 new jars. Please drop them into the modules directory (replacing the ones in it). Also remove the following jars from modules

        javax.el-api.jar
        javax.servlet.jsp-api.jar
        javax.servlet.jsp.jstl-api.jar

        If the benchmark shows improvement, I'll commit the changes, and publish the new artifacts and integrate them into glassfish."

        Amit Agarwal 1/6/2012:

        "I don't see any improvement with these jar files."

        Dhiru on 1/6/2012:

        "Can we then infer that the cause of regression was not because of the increase in the number of jar files, because with this change there are 3 less jar files in the modules directory"

        Scott 1/6/2012:

        "So if it isn't the packaging itself, something else has changed. One thing we discovered in the profile is that web container startup performance has regressed through this path (for deploying a simple hello-world JSP immediately after startup):

        ApplicationLifecycle.setupContainerInfos -> ApplicationLifecycle.startContainers -> EnginINfo.getContainer ->
        AbstractInhabitantImpl.get -> EventPublishingInhabitant.get -> SingletonInhabitant.get -> AbstractCreatorImpl.get -> ConstructorCreator.initialize -> AbstractCreatorImpl.inject -> InjectionManager.inject -> InjectInjectionResolver.getValue.

        In 3.1.2, that last getValue method calls InjectInjectionResolver.getArrayInjectValue; in 3.1.1 it called InjectInjectionResolver.getServiceInjectValue. There is a significant difference in those calls, which makes sense because getArrayInjectValue has to convert a list to an array.

        What does it mean that getContainer is now returning an array? Are there actually multiple containers? That would also explain why we see more classes now, which is one reason why we are recommending setting PermSize=64m by default."

        Show
        kchung added a comment - Scott Oaks commented on 12/17/2011: "I would guess that the compilation itself is not the issue, because we only see a regression for the first deployment and access – when we redeploy and access, the times are the same before and after the JSP integration." Kin-man commented on 12/28/2011: "The only thing I can think of is that jsp api and el api classes were repackaged into one jar file, but now they remain as two separate jars." Scott 12/28/2011: "Yes; it is additional disk access and parsing of a manifest plus dependencies. Maybe not enough to account for the entire regression, but at least part of it (and the entire regression we're tracking down here is only a few hundred milliseconds...) How easy would it be for you to package the module back as one jar file so we can drop it into build 15 and test the difference? Then we'd know if it is that, or something else." Kin-man 1/5/2012: "Dhiru and I agreed that it'll make more sense to keep jsp api and el api separate, but instead, to combine the api with the corresponding implementations. I've used the same group and artifact id, so the new jars can be dropped into<GF>/modules directory. Attached are the 3 new jars. Please drop them into the modules directory (replacing the ones in it). Also remove the following jars from modules javax.el-api.jar javax.servlet.jsp-api.jar javax.servlet.jsp.jstl-api.jar If the benchmark shows improvement, I'll commit the changes, and publish the new artifacts and integrate them into glassfish." Amit Agarwal 1/6/2012: "I don't see any improvement with these jar files." Dhiru on 1/6/2012: "Can we then infer that the cause of regression was not because of the increase in the number of jar files, because with this change there are 3 less jar files in the modules directory" Scott 1/6/2012: "So if it isn't the packaging itself, something else has changed. One thing we discovered in the profile is that web container startup performance has regressed through this path (for deploying a simple hello-world JSP immediately after startup): ApplicationLifecycle.setupContainerInfos -> ApplicationLifecycle.startContainers -> EnginINfo.getContainer -> AbstractInhabitantImpl.get -> EventPublishingInhabitant.get -> SingletonInhabitant.get -> AbstractCreatorImpl.get -> ConstructorCreator.initialize -> AbstractCreatorImpl.inject -> InjectionManager.inject -> InjectInjectionResolver.getValue. In 3.1.2, that last getValue method calls InjectInjectionResolver.getArrayInjectValue; in 3.1.1 it called InjectInjectionResolver.getServiceInjectValue. There is a significant difference in those calls, which makes sense because getArrayInjectValue has to convert a list to an array. What does it mean that getContainer is now returning an array? Are there actually multiple containers? That would also explain why we see more classes now, which is one reason why we are recommending setting PermSize=64m by default."
        Hide
        Joe Di Pol added a comment -

        We've mitigated the impact of this on 3.1.2 by configuring a PermSize
        setting so that the regression is ~150ms. At this point I don't expect us to have any further JSP/EL integrations, so I'm lowering the priority of this bug and removing it from the 3.1.2 review list.

        Show
        Joe Di Pol added a comment - We've mitigated the impact of this on 3.1.2 by configuring a PermSize setting so that the regression is ~150ms. At this point I don't expect us to have any further JSP/EL integrations, so I'm lowering the priority of this bug and removing it from the 3.1.2 review list.

          People

          • Assignee:
            kchung
            Reporter:
            Joe Di Pol
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: