I do like the indiana work on the perf of XML based communications protocols. Its good to have people looking at this rigorously, even with the bias of scientific grid computing (hence the concerns with floats, rather than say date/time conversion)
Regarding nagling, HTTP1.0 is so aggressively sub-optimal that it is always tempting to turn it off, yet TCP_NODELAY on long haul links is both anti-social and often counter-productive. Maybe clients should decide dynamically whether to delay or not depending on whether or not the endpoint is local subnet or not -or even on the experience of the latest call. The indiana paper used HTTP1.1 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. ----- 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 >
