You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2015/03/28 00:56:10 UTC
[Bug 57773] New: performance problems when using scopeless optional
attributes
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.pohl@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #10 from balusc <ba...@gmail.com> ---
This is fixed in a related issue
https://bz.apache.org/bugzilla/show_bug.cgi?id=57583
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #7 from Mark Thomas <ma...@apache.org> ---
(In reply to Woonsan Ko from comment #5)
> How about introducing a whitelist filter attribute in context configuration?
> e.g, elStaticAccessFilter="^[a-z].*$".
There is no easy way to configure this since the problematic code is in a
specification defined class and we can not change the API.
It might be possible to (ab)use the ELContext.putContext() method to set some
special value but even then we'd have to make sure every ELContext created had
the special value set on it.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #6 from Woonsan Ko <wo...@yahoo.com> ---
It should be a "filter", not "whitelist" above.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |WONTFIX
Status|NEW |RESOLVED
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
I don't think there is anything we can do about this.
Supporting EL 3.0 means JSP 3.0 has to check the identifier to see if it is an
imported class or field. Class lookups are slow - largely due to the
ClassNotFoundException that is triggered when it fails.
We can avoid the CNFE by looking up the InputStream for the class rather than
trying to load the class. On the plus side this makes lookups when the
identifier is not a class ~4 times faster. The downside is it makes valid
lookups ~25% slower. I don't think this is a viable option.
I've added some information to the Tomcat 8 migration guide to explain this
issue and to recommend the work-around you are already applying.
We could add a Tomcat specific option to skip the class/field lookup in the
ScopedAttributeELResolver. I'm not a fan of this because:
- it would be Tomcat specific
- it would have to be a system property since this is a spec class
- it could not be applied per application - it would impact all applications
running on that instance
It this turns out to affect large numbers of users then the Tomcat specific
option is probably the answer but for now this is WONTFIX.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #11 from Woonsan Ko <wo...@apache.org> ---
Hooray! Thanks a lot!
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #8 from Bernhard Frauendienst <ap...@nospam.obeliks.de> ---
This issue hit us quite hard when trying to upgrade from 8.0.15. An optional
attribute in a very frequently used tag caused performance to drop massively
(especially combined with the default non-parallel WebappClassLoader).
Even though I finally found the root of the problem, it seems very hard to
contain. Any developer could easily trigger the issue, and might decrease
performance slowly one step at a time, without even noticing, yet causing a
massive performance hit in the long run.
I understand that the situation is tricky due to spec requirements, but any
solution to make this behaviour more controllable would be most welcome.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #5 from Woonsan Ko <wo...@yahoo.com> ---
Hi @markt and @donnchadh,
How about introducing a whitelist filter attribute in context configuration?
e.g, elStaticAccessFilter="^[a-z].*$".
Like containerSciFilter attribute, it can be set to a regular expression
specifying which static access expression should be filtered out in class
lookup step.
Considering the concerns (spec not giving enough choices, caching approach is
too impactful, etc.), this solution might be effective in practice, avoiding
potential issues.
When upgrading to tomcat8, people should validate/update a lot of JSP files or
meet a big performance degrade as reported here.
To avoid this costly situation or performance issue, if we support that simple
static accessor filter attribute in context configuration, most issues should
be covered I believe.
People tend to use attribute name in camel case, and static access expression
should be in pascal case in most cases. So the filter expression above could
solve problems in most cases if set optionally by the users.
Kind regards,
Woonsan
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #3 from donnchadh <do...@gmail.com> ---
I'm seeing a dramatic dramatic impact due to this (in conjunction with the
global lock on WebAppClassLoader).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |janusz.parfieniuk@gmail.com
--- Comment #4 from Mark Thomas <ma...@apache.org> ---
*** Bug 58328 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #9 from Woonsan Ko <wo...@apache.org> ---
(In reply to Mark Thomas from comment #7)
> There is no easy way to configure this since the problematic code is in a
> specification defined class and we can not change the API.
>
> It might be possible to (ab)use the ELContext.putContext() method to set
> some special value but even then we'd have to make sure every ELContext
> created had the special value set on it.
Maybe we can introduce a servlet context event listener which can be enabled in
conf/web.xml like JspServlet.
The listener may retrieve javax.servlet.jsp.JspApplicationContext
(JspFactory.getDefaultFactory().getJspApplicationContext(servletContext)) and
can probably register an ELContextListener. Then we will probably have a chance
to put some special value on every ELContext.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
--- Comment #2 from Christopher Schultz <ch...@christopherschultz.net> ---
I'm sorry, I haven't looked at the code for this, but ...
Are we caching class-lookup failures? If not, could we cache them for a short
period of time? Maybe as long as 5 seconds or so? That would certainly improve
performance quite a bit for this use-case.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
Woonsan Ko <wo...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |woonsan@apache.org
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 57773] performance problems when using scopeless optional
attributes
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=57773
Bernhard Frauendienst <ap...@nospam.obeliks.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |apache@nospam.obeliks.de
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org