HTTP keep-alive performance

Manuel Metz mmetz at
Tue Mar 4 16:10:25 CET 2008

Hi all,
I tried to use the HTTP keep-alive (HTTP/1.1) mechanism for an xmlrpc 
server/client session. This worked fine, after I found out how to fix 
the client, see:
   and also

Now, as I said, everything seems to work fine -- except: performance got 
very bad :-(

So, I captured the TCP traffic with wireshark (both, server and client 
are running on the same machine, 'http://localhost', so its not the 
network). What I found out is the following:

The first remote-call is executed very fast. Then the connection is kept 
open (I verified that it is closed for HTTP/1.0). But when it comes to 
the second call, the performance gets bad. The TCP ACK package is sent 
after ~40ms only, which took ~ < 1ms before for the first call, even for 
HTTP/1.1. Why is that?

So this is a sketch of what's going on:

client      server
----------  ----------
HEADER   -->
          <-- ACK       ~1ms
          <-- ACK       ~1ms
          <-- HEADER
ACK      -->           ~1ms
[...] response is submitted; connection is NOT closed [...]
HEADER   -->
          <-- ACK       ~40ms
          <-- ACK       ~1ms
          <-- HEADER
ACK      -->           ~40ms
[...] response data is submitted

It's just a rought timeline to show where the bottleneck is. Has anyone 
any idea why the acknowledgement messages take sooooo long to be sent???


More information about the Python-list mailing list