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. 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 ----- Original Message ----- From: "Douglas Bitting" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 15, 2002 11:02 AM Subject: Axis performance > Just FYI, here is a report that doesn't paint Axis in a very good light, performance-wise. Like any benchmark, one has to take it with a grain of > salt since the benchmark methodology may have nothing to do with how one uses the software in question. So, FWIW... > > http://www.extreme.indiana.edu/xgws/papers/soap-hpdc2002/soap-hpdc2002.p df > > Cheers, > --Doug > > Doug Bitting > Agile Software > 1 Almaden Blvd > San Jose, CA 95113 > (408) 999-7120 > > >
