axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Chiu <>
Subject Re: Axis performance
Date Thu, 17 Oct 2002 21:08:18 GMT
On Tue, 15 Oct 2002, Steve Loughran wrote:
> Interesting to see that FP to ascii conversion takes so long; one of my
> projects is very FP intensive. But this is an XML parser issue, not SOAP
> stack per-se. Maybe I should look at using a JNI to msxml bridge rather than
> xerces/J for the old xml parser. The proposal to use a binary representation
> of FP is interesting; there are the ISO standard representations after all,
> but it does go against the fundamentals of both XML and XML Schema.

A possible compromise which might be acceptable for
scientific computing is to send the double as text, but
include a hint which can be used to speed up the FP
conversion.  We haven't investigated this yet, though.

> ----- Original Message -----
> From: "Scott Nichol" <>
> To: <>
> Sent: Tuesday, October 15, 2002 9:03 AM
> Subject: Re: Axis performance
> > Something this paper does not touch upon that has been much discussed on
> > the Apache SOAP lists is disabling the Nagle algorithm, i.e. calling
> > setTcpNoDelay(true), on the client socket.  Basically, with the Nagle
> > algorithm enabled (the default), the client TCP/IP stack sends each data
> > packet after receiving the ACK for the previous packet.  This interacts
> > with the implementation of delayed ACK on the server.  Delayed ACK
> > withholds the ACK for a packet for typically 200 ms when either the
> > packet is not a full MAC frame or the preceeding packet is not a full
> > frame, although the delay is cancelled if the server has data to send to
> > the client, in which case the ACK is sent with the data.
> >
> > It had been my assumption that Nagling would have no effect on Apache
> > SOAP since it uses a buffered output stream, the size of which can be
> > set to be larger than a MAC frame.  My initial tests with a Linux server
> > seemed to confirm this, but I got different results running with a Win2k
> > server.  It turns out that in the Red Hat 7.3 build I was using, delayed
> > ACK is disabled.
> >
> > I had assumed using buffered output would suffice since with a buffer
> > size greater than the frame size, the buffering mechanism would always
> > send full frames until the final flush.  This is my recollection of how
> > it works in C.  This is *not* how it works in the Java libraries.  When
> > the data for a write operation will not fit in the current buffer, the
> > current buffer (which is *not* full) is written to the underlying
> > stream.  For Apache SOAP, the HTTP headers are written by the buffered
> > output stream in one write operation, then the data is written in
> > another.  This causes 2 or more writes to the underlying stream whenever
> > the buffer is not large enough to hold all the headers and data at once.
> > The first write is just the HTTP headers and is typically not a full
> > Ethernet frame.  The Nagle algorithm and delayed ACK combine to give an
> > unnecessary and unwanted 200 ms delay.
> hmm.
> >
> > I do not have an Axis setup to confirm this affects Axis, but based on
> > my research with Apache SOAP, I am confident that it does.
> >
> > Scott Nichol
> >

View raw message