Perf bottleneck with the number of calls from PageFlowPageFilter to get
ActionServlet from ServletContext
---------------------------------------------------------------------------------------------------------
Key: BEEHIVE-1105
URL: http://issues.apache.org/jira/browse/BEEHIVE-1105
Project: Beehive
Type: Improvement
Components: NetUI
Versions: 1.0.1
Reporter: Carlin Rogers
Assigned to: Carlin Rogers
Fix For: v.next
Perf issue - for JSP not associated directly to a page flow, there are multiple
calls via the PageFlowPageFilter to get ActionServlet from ServletContext. Some
containers, implement the ServletContext getAttribute() method with
synchronization on the attribute object or the attributes map.
An application that includes common JSP not associated with a given page flow
(for look and feel, banners, headers, or footers) will experience a
synchronization bottleneck under heavy load. For example, a page flow action
may forward to a JSP which includes a few other JSP for a header and footer
(like... <jsp:include page="../common/header.jsp"/> where there's no associated
page flow or struts module config for the location of the common header JSP).
The JSP include will go through the PageFlowPageFilter. The filter now tries to
ensure a module config from a module path when initializing the module, getting
the shared flows for the request and trying to get the page flow for the
request. All these calls go through the InternalUtils.ensureModuleConfig(),
making a call to get the ActionServlet (the NetUI AutoRegisterActionServlet)
from the ServletContext attributes.
Note that this will happen on every include of this example header JSP for a
given request. If this file, and others like it are used in most of the pages
of the application and there are many users applying load, there will be a
bottleneck in the multiple calls to the ServletContext getAttribute() method
from each of the requests.
Note that his particular bug is just one aspect of performance improvements
that could be made for getting data associated with a given module path. Would
be great to implement some sort of caching layer to provide a central/common
way to access to module configs, shared flow information, etc. without having
to get the Netui AutoRegisterActionServlet directly. I will log a future
enhancement in JIRA to improve on any short term fixes in this bug.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
