ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bill-s...@carpenter.ORG (WJCarpenter)
Subject persistent connections
Date Tue, 17 Sep 2002 22:09:19 GMT
I have done an implementation of SOAPTransport using the HTTPClient
v0.3-3 package from <>.
HTTPClient supports persistent connections (and many other cool

Are you wondering how much time you would save by using persistent
connections?  The easy way to find out is to run ping from your client
machine to your server machine.  You will save approximately that much
time.  If you're on a LAN, that might typically be under 1 ms, so
there's not much point.  If you're on a WAN, it will be something
larger.  For example, from home over DSL with VPN, I get ping times of
about 100 ms to hit servers on my office LAN.  My measured difference
in request/response RTT is also about 100 ms.

The savings is in the "3-way handshake" of connection establishment.
There is client SYN answered by server SYN.  The client also has to
ACK the server SYN, but that doesn't further delay the client from
sending request data.  The connection establishment and ping both
happen low in the stack, so one is a good approximation of the other.

A couple things to be aware of if you contemplate persistent
connections.  (I welcome comments on these.)  [[The server I talk to
is a piece of custom code that we run either as an IIS ISAPI extension
or as an Apache httpd module.  I mention that so that there is no
confusion about server-side toolkits of any stripe.  We're not using
one except for homegrown stuff.]]

When I talk to IIS with a persistent connection, IIS closes the server
after every request.  I haven't looked into this too much because it's
not that important in my scenarios, but I think it's because we don't
buffer everything up and tell IIS the content-length, nor do we take
the necessary application steps to do chunked encoding.  In such
circumstances, I believe that IIS will always behave the way I'm
seeing.  In other words, IIS doesn't implicitly do chunked encoding
nor does it buffer up application writes and compute the
content-length.  So, whether you will see persistent connections
actually, uh, persist when IIS is the server actually depends on
server toolkit behavior (about which I know very little).  You don't
actually lose any ground in trying persistent connections; you just
don't gain anything if they get closed every time.

When I talk to Apache httpd (2.0.40) with a persistent connection, I
get a chunked response.  HTTPClient handles that just fine.  Again,
our server side software doesn't do anything about that, so I believe
Apache is automatically doing the chunking (based roughly on writes
from our module).  Unfortunately, there is often an effect which kills
performance when talking to Apache.  I believe it is Nagle's algorithm
on the server combined with delayed ACK on the client.  In the first
packet of the response, Apache sends the HTTP headers and the payload
(if it fits).  The (entire) payload is one HTTP "chunk".  It does not
send the second packet containing only the zero-length final HTTP
"chunk" until it gets an ACK for the first packet.  Due to delayed
ACK, the client doesn't ACK the first packet until a 200 ms timer

I think this is Nagle's algorithm on the server (even though Apache
seems to disable Nagle's algorithm) because it follows a classic
odd/even packet count pattern.  If the payload spills over into a
second packet, TCP sends both packets immediately and they get ACK'd
immediately by the client, which in turn lets TCP send the final
packet with the final zero-length chunk.  (Nagle's algorithm doesn't
care how many full packets are involved.  It only cares about partial
packets and will only let you have one non-ACK'd partial packet.)  I
also think this is not TCP slow start because the pattern repeats if I
do multiple identical requests with the same persistent connection (if
it were slow start, I would expect the delay to evaporate after 1 or 2

Of course, I could be wrong and it could be some completely different
mechanism delaying the final zero-length chunk.  It does always come
immediately after the ACK of the first packet, though, which leads me
to think it's the server's TCP and not something in Apache.  (In case
you are wondering, I'm looking at packet data from tcpdump.)

Since there are lots of short responses in the land of SOAP requests
(and in any event, it's hard to structure your request with the aim of
forcing an even or odd number of packet responses :-), this is likely
to be a big problem with persistent connections hitting Apache
servers.  I would be really happy to have my nose rubbed in some
obvious fix or workaround for this.
bill@carpenter.ORG (WJCarpenter)    PGP 0x91865119
38 95 1B 69 C9 C6 3D 25    73 46 32 04 69 D6 ED F3

View raw message