M
Manuel Metz
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:
http://mail.python.org/pipermail/python-list/2004-April/256360.html
and also
http://mail.python.org/pipermail/python-list/2007-May/442541.html
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
CONTENT -->
<-- ACK ~1ms
<-- HEADER
ACK --> ~1ms
[...] response is submitted; connection is NOT closed [...]
HEADER -->
<-- ACK ~40ms
CONTENT -->
<-- 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???
Manuel
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:
http://mail.python.org/pipermail/python-list/2004-April/256360.html
and also
http://mail.python.org/pipermail/python-list/2007-May/442541.html
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
CONTENT -->
<-- ACK ~1ms
<-- HEADER
ACK --> ~1ms
[...] response is submitted; connection is NOT closed [...]
HEADER -->
<-- ACK ~40ms
CONTENT -->
<-- 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???
Manuel