[GLASSFISH-18021] [PERF]jsp / el integration causes performance regression in startup benchmark Created: 15/Dec/11 Updated: 03/Dec/12
|Reporter:||Joe Di Pol||Assignee:||kchung|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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
This seems to indicate the following check-in caused the regression:
|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."
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."
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"
"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 ->
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