DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30707>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30707

Bottleneck in ActionServlet

           Summary: Bottleneck in ActionServlet
           Product: Struts
           Version: 1.1 Final
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Standard Actions
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


The struts ActionServlet has a performance/scalability bottleneck.  Every
request calls the synchronized method getRequestProcessor( ModuleConfig config
), which does a lazy instantiation of the RequestProcessor for this module. 
This puts an overhead on each request to the module; an overhead which is really
only necessary for the first request.

When there are are large number of concurrent requests, they spend most of their
time queuing for this function.  I'll give that statement some figures:

I'm running a test with Tomcat, a nothing-special action , and 400 concurrent
threads.  I run a single request to check that everything along the chain has
been initialised, start a profiler, and then hit the server with 400 requests,
running in a continuous loop.  With the current 1.1 release it spends ~60% of
its time in the ActionServlet.process(...) method, queuing on
getRequestProcessor.  A patched version with the same test-run spends a
negligible amount of time in the process(...) method (<.01%).

I will attach a patch to this bug.  You guys will probably have a better
solution to the problem, but it's working well for me, and at least illustrates
what I'm getting at. I look forward to your thoughts... :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to