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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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 > > > >
