[GLASSFISH-18021] [PERF]jsp / el integration causes performance regression in startup benchmark Created: 15/Dec/11  Updated: 03/Dec/12

Status: Open
Project: glassfish
Component/s: web_container
Affects Version/s: 3.1.2_b13
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Joe Di Pol Assignee: kchung
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: performance


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

Log Message:
Integrate jsp and el.  Remove javaee-api/javax.servlet.jsp

Comment by kchung [ 11/Jan/12 ]

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


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."

Comment by Joe Di Pol [ 24/Jan/12 ]

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.

Generated at Fri Oct 28 12:31:36 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.