https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
Bug ID: 57773
Summary: performance problems when using scopeless optional
attributes
Product: Tomcat 8
Version: 8.0.21
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: EL
Assignee: dev@tomcat.apache.org
Reporter: m.p...@gmx.de
hi,
i discovered a performance problem in EL implementation of recent tomcat 8
versions. we have some jsp based products, which are running fine on
tomcat7/java8. while migrating to tomcat8 i discovered severe performance
problems.
"ab" performance against localhost (same machine with identical webapp)
TOMCAT 7.0.59 / Java 1.8.0_40
Requests per second: 96.12 [#/sec] (mean)
Time per request: 10.404 [ms] (mean)
TOMCAT 8.0.20 / Java 1.8.0_40
Requests per second: 2.41 [#/sec] (mean)
Time per request: 414.429 [ms] (mean)
i realized that this could be related to bug #57583 and waited for 8.0.21.
8.0.21 is better, but also far away from tomcat 7
TOMCAT 8.0.21 / Java 1.8.0_40
Requests per second: 4.97 [#/sec] (mean)
Time per request: 201.270 [ms] (mean)
so i take some further investigations. we are using jsp-files as reusable
templates. because of reuse in different contexts there are some optional
request attributes.
page.jsp
...
<c:forEach var="video" items="${videolist}">
<c:set var="teaser" value="${video}" scope="request" />
<jsp:include page="teaser.jsp" />
</c:forEach>
...
teaser.jsp
...
<c:if test="${teaserLarge}">
...
</c:if>
..
the problem occurs when teaserLarge is not defined. in this case the c:if line
ends in a time consuming call of javax.el.ImportHandler.resolveClass() for
"teaserLarge". and it seems that the bugfix for #57583 does not help in this
situation because each teaser is rendered in its own pagecontext.
interestingly this does not occur if we access the optional attributes via the
requestScope. when we use
<c:when test="${requestScope.teaserLarge}">
the performance in the undefined case is much better. we now are in process of
rewriting our statements to requestScope, but i think that the performance of
the scopeless access should also be fixed.
regards
marc
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
