Funny xmlrpc / linux problem

[Hans Müller]

Hello,

I found a timing problem while playing with the xmlrpx stuff.

I created a very simple server, running on a network node on windows.
The client runs on windows or linux. It runs a very simple test function on the server
which just echos a passed string. The trip time is beeing measured.
When I use a 1024 char test string I get a trip time in the 10-20ms range on windows and linux.
But for small arguments the trip time explodes - why on earth ?!

May be this problem is here off topic and tcp/ip stack related.

Here is the very very simply test server:

#!/usr/bin/python
# -*- coding: cp1250 -*-
# xmlrpc test server

import SimpleXMLRPCServer
import xmlrpclib
import time

# the test function - justs echos the argument
def RunTest(buffer):
return buffer


print "Starting RPC Server..."

# Create server
server = SimpleXMLRPCServer.SimpleXMLRPCServer(("node01", 10000))
server.register_function(RunTest)

# Run the server's main loop
server.serve_forever()


This is the test client:

#!/usr/bin/python
# -*- coding: cp1250 -*-
# Test for Roundtrip Time xmlrpc calls

import SimpleXMLRPCServer
import xmlrpclib
import datetime

print "started..."


s = xmlrpclib.ServerProxy('http://laptvm:10000') # place here your server address

for scale in (100240, 10240, 1024, 512, 256, 128, 64, 32, 16, 10, 1):
print "Checking with", scale
buffer = "0123456789" * scale
now = datetime.datetime.now()
for i in range(10):
res = s.RunTest(buffer)
if buffer != res:
print "data error"
later = datetime.datetime.now()
dt = later - now

print "time for 10 loops: %f" % (dt.seconds + (0.000001 * dt.microseconds))



Some results from my tests here:

started...
Checking with 100240
time for 10 loops: 3.282000
Checking with 10240
time for 10 loops: 0.360000
Checking with 1024
time for 10 loops: 0.078000
Checking with 512
time for 10 loops: 0.047000
Checking with 256
time for 10 loops: 0.046000
Checking with 128
time for 10 loops: 0.047000
Checking with 64
time for 10 loops: 1.985000 ' Whats this ?! - smaler packets, more time ?!
Checking with 32
time for 10 loops: 2.000000
Checking with 16
time for 10 loops: 2.000000
Checking with 10
time for 10 loops: 2.000000
Checking with 1
time for 10 loops: 2.000000



Tanks a lot,
Hans

 

[Hans Müller]

Small addition:

While tracing the network data I found the server to be the problem,
the answer to a request is beeing delayed by about 180ms - no idea why.

 

[Hans Müller]

Another addendum...

while running again the server code on a linux host,

the times are as expected.

started...
Checking with 100240
time for 10 loops: 2.844000
Checking with 10240
time for 10 loops: 0.390000
Checking with 1024
time for 10 loops: 0.078000
Checking with 512
time for 10 loops: 0.063000
Checking with 256
time for 10 loops: 0.063000
Checking with 128
time for 10 loops: 0.062000
Checking with 64
time for 10 loops: 0.063000
Checking with 32
time for 10 loops: 0.063000
Checking with 16
time for 10 loops: 0.062000
Checking with 10
time for 10 loops: 0.063000
Checking with 1
time for 10 loops: 0.063000


The problem seems to be on the windows side.

Any ideas ?

Thanks, greetings Hans

 

[Brian Quinlan]

Hey Hans,

Try reversing the list of numbers and see if anything changes.

Cheers,
Brian

 

[Richard Brodie]

Small addition:

While tracing the network data I found the server to be the problem,
the answer to a request is beeing delayed by about 180ms - no idea why.

Nagle's algorithm: you've unintentionally produced a textbook demonstration.

 

[Hans Müller]

Richard,

thanks a lot for your hint, that was completely new for me.
Nagle's optimisation is definitely a good idea in most cases.

By the way, do you have an idea how to access the underlying socket to modify the behavier
via the setsockopt function to disable Nagle's algorythm in my special case (i need speed for small
packets) ?

Thanks a lot

Hans

 

[Jeff McNeil]

Richard,

thanks a lot for your hint, that was completely new for me.
Nagle's optimisation is definitely a good idea in most cases.

By the way, do you have an idea how to access the underlying socket to modify the behavier
via the setsockopt function to disable Nagle's algorythm in my special case (i need speed for small
packets) ?

Thanks a lot

Hans

Something like this ought to work. SimpleXMLRPCServer uses
SocketServer.TCPServer to handle all of the network-layer stuff. Also,
ironically, see http://bugs.python.org/issue6192.

import socket
from SimpleXMLRPCServer import SimpleXMLRPCServer

class MyXMLServer(SimpleXMLRPCServer):
def server_bind(self):
self.socket.setsockopt(
socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
SimpleXMLRPCServer.server_bind(self)

s = MyXMLServer(('127.0.0.1', 8080))
print s.socket.getsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY)

HTH,

Jeff