tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David kerber <dcker...@verizon.net>
Subject Re: Performance with many small requests
Date Fri, 08 May 2009 15:57:58 GMT
Peter Crowther wrote:
>> From: David kerber [mailto:dckerber@verizon.net]
>> Now that I've got a thread dump, what am I looking for?
>>     
>
> You found it first time :-).  Now the hard part - fixing it.
>   
Yeah, that's what I figured!

>> I've got a
>> bunch of sections like this, pretty much all of which are waiting to
>> lock <0x057c73e0>.  Is there any way to figure out what that
>> object is?
>> I imagine it's the disk write, but can't figure out how to
>> tell for sure.
>>     
>
> It's the sync at the start of your method.
>
>   
>> [2009-05-08 10:43:24] [info] waiting for monitor entry
>> [2009-05-08 10:43:24] [info] [0x2739f000..0x2739fb64]
>> [2009-05-08 10:43:24] [info]     at
>> eddsrv.EddRcvr.doPost(EddRcvr.java:70)
>> [2009-05-08 10:43:24] [info]     - waiting to lock <0x057c73e0> (a
>> eddsrv.EddRcvr)
>>     
I also have quite a few blocks like this:

[2009-05-08 10:43:23] [info] "http-1024-Processor10"
[2009-05-08 10:43:23] [info] daemon
[2009-05-08 10:43:23] [info] prio=6 tid=0x271f1418
[2009-05-08 10:43:23] [info] nid=0xa74
[2009-05-08 10:43:23] [info] in Object.wait()
[2009-05-08 10:43:23] [info] [0x275df000..0x275dfae4]
[2009-05-08 10:43:23] [info]     at java.lang.Object.wait(Native Method)
[2009-05-08 10:43:23] [info]     at java.lang.Object.wait(Unknown Source)
[2009-05-08 10:43:23] [info]     at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:656)
[2009-05-08 10:43:23] [info]     - locked <0x0510e6e0> (a 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable)
[2009-05-08 10:43:23] [info]     at java.lang.Thread.run(Unknown Source)
[2009-05-08 10:43:23] [info]

I assume these are just threads waiting for something to do (waiting for 
a request)?

>
> ... so they're all waiting to get the monitor on a eddsrv.EddRcvr, which is what the
"synchronized" on your doPost method will lock on.
>   
Until you said that, I didn't even notice that I had what appear to be 
"double" synchronizations, making the method synchronized, and also 
having synchronized{} blocks inside it.  I assume I've been 
double-screwing myself all this time??

    protected synchronized void doPost(HttpServletRequest request, 
HttpServletResponse response )
            throws ServletException, IOException {
        synchronized ( criticalProcess ) {
            totalReqCount++;
            dailyReqCount++;
            processRequest( request, response, false );
        }
    }                


> If you say pretty much all are stuck there, then you have massive contention on that
monitor.  Time to move to some finer-grained locking!  As a first step, I'd remove the synchronized
from the method; I'd replace it with one lock around the counter updates (locked on one object)
and another lock in your decrypt/log/respond code that's purely around the logging section
(locked on a different object).  Then I'd re-evaluate - run, take another thread dump and
see where the bottlenecks are now.  If they're anywhere, I'll bet they're around the logging
code.
>   
Thanks!


D



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message