Toshi, 

Thanks, I downloaded the source (1.1) late Friday but haven't had a chance
to look at it yet. What you're saying is definitely consistent with my
findings. Don't know if it's workable but I was going to look at using a
ThreadLocal to bypass synchronization but as I said I haven't looked at the
code yet.

The testing scenario definitely is a factor it was specifically designed to
trip over synchronization; I expected to find it in our App which is brand
new. I only discovered this issue because I started trying to isolate it
working in from the front (since I've never performance tuned Linux/Tomcat
before I felt I'd get a better feel for having got it right if I understood
how the various components behaved) rather than working back from our App.
Interestingly I saw a similar pattern just retrieving a gif from Tomcat,
albeit at 950 users with a 520mS response time, so perhaps the test was a
little too brutal.

Thanks

Ray Sutton
Systems Engineer

-----Original Message-----
From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 03, 2003 7:03 PM
To: '[EMAIL PROTECTED]'
Subject: RE: Axis Response Time appears linear with load

Hi Ray,

  It seems your problem is from a synchronized block
for a DocumentBuilderFactory. Axis is pooling parser
instances, however the current is using only one dbf
instance at least.

  But, I think also this bottle-neck might be caused
by your testing scenarios.I mean the neck might make
it hard to find out if you use a real implementation
of your business-logics as an end-point.

  Anyway, if you hope to clear the matter and also
you help us to fix it, we may provide a snapshot
patch for testing.

--
Toshi <[EMAIL PROTECTED]>

On Fri, 3 Oct 2003, Sutton, Ray wrote:

>
> To answer Toshi's comment, the configuration I was testing loop a response
> back in the method proxy, the test payload is an echo request so I was
able
> to simply instantiate our response object and move the payload without
> entering our application framework. The only non-Axis/infrastructure
> processing is instantiate, move object reference, return. I'll double
check
> the instantiate doesn't involve a synchronize though.
>
> The thread dump as requested, I've trimmed it to the lock holder and one
on
> the waiters, the other two were at the same location in code.
>
> "Thread-23" daemon prio=5 tid=0x03650408 nid=0xfd8 runnable
> [43df000..43dfd94]
>         at
>
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown
> Source)
>         at org.apache.axis.utils.XMLUtils.newDocument(XMLUtils.java:318)
>         - locked <0x10ac8688> (a
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl)
>         at


The information in this electronic mail message is sender's business
Confidential and may be legally privileged.  It is intended solely for the
addressee(s).  Access to this Internet electronic mail message by anyone
else is unauthorized.  If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken
in reliance on it is prohibited and may be unlawful. 
The sender believes that this E-mail and any attachments were free of any
virus, worm, Trojan horse, and/or malicious code when sent. This message and
its attachments could have been infected during  transmission. By reading
the message and opening any attachments, the recipient accepts full
responsibility for taking protective and remedial action about viruses and
other defects. Galileo International is not liable for any loss or damage
arising in any way from this message or its attachments.


Reply via email to