Board index » delphi » SOAP client slow to receive large data packets

2008-01-11 08:14:00 AM
delphi208
I'm using a SOAP connection to a 3rd party server and it functionally
working fine. I imported the wsdl and built a test panel. While it's
working, it is very slow. Delphi 2007 Enterprise.
The object is extremely simple: Send a data payload, get one back. The
payload is XML itself which, when you see it on the line is neutered into a
big string by using >, < and friends. Bottom line is that the SOAP
conversation is sending a little string, receiving a big string.
All works well except the speed. I initially thought the server was just
slow (30 seconds typical on one response that sends about 300 bytes and
receives about 170k bytes). However, when I hooked up ethereal I find that
the server response starts very quickly (subsecond to a couple of seconds).
All the rest of the time is spent receiving the response packet.
Typical of the cycle on the line is to get a packet from the server and Ack
it, get another packet from the server, etc. Straightforward enough, but
the delay between getting a packet from the server and the Ack being sent
back is between 150 and 200 milliseconds! What the heck is going on during
that time? Contrast that with the server response... from the time the ack
is sent to receiving the next packet with a 1.5k payload from the remote
server is maybe 10 milliseconds.
The end result is that receiving 170k of data takes 30 seconds, almost all
of it being spent by the client machine.
I've tinkered with the mtu (I'm also seeing "reassembled PDU" messages),
having changed to to various values even as low as 150, but this delay seems
to actually be some processing by the client.
Is there some setting I am missing?
Thoughts?
Thanks,
Dan
 

Hello Dan,
30 secs. to receive 170K of data sounds like there's definitely something
wrong. it is true that the data coming off the wire is copied more than once
and if you use WideString instead of AnsiString (i.e. String), there's even
more of an overhead because it is not ref-counted. However, I can not imagine
this being the issue.
I would suggest the following:
Take out the SOAP/serialization component and try out just the
HTTP/Transport. There's a sample included with the product (earlier versions
of Delphi might not have it but I am happy to post/email a copy of that
project if necessary) called PostTool. This sample allows you to POST a SOAP
request and get the response XML.
In case you need some help with the request XML, you can handle the
OnBeforeExecute event on the HTTPRIO component to see what the request XML
looks like.
My goal is to identify whether the problem is at the transport level or at
the XML-DOM handling+Deserialization.
You can also add SOAPHTTPTrans.pas to your project and set a breakpoint on
the receive method. There's a repeat/until loop in there where we basically
call 'InternetReadFile' to read the response after a POST of the request. If
the time is spent there, then it is a transport issue - which could mean
several things from WinInet, throughput, etc. If it is past that point,
that's the area where we have the most control and I would like to better
understand and hopefully find a fix.
Cheers,
Bruneau.
 

Thanks Bruneau,
We've done a little more testing and are leaning toward it
likely involving the transport somehow. We've built
straight TCP connectors to send xml back and forth to
simulate the client and get the same result. However, we'd
used Indy for that so it wasn't out of the picture.
Monitoring the packets (Ethereal) it appears that the
packets are being whacked somewhere along the line. We're
getting "reassembled PDU" messages in the sniffer. We'll
try to get the correct network folks involved (it traverses
several). That definitely could cause a slowdown.
The puzzling part is that when looking at the packet timing,
the dead time appears to be waiting on the client machine to
respond in the conversation. Noting that fact, I was
initially fairly confident that something in the soap client
was involved.
However, today we had a capture that showed the same timing
behavior on another machine using straight web pages from
that same server. The only thing in common there would be
the IP stack and the network routing. No SOAP client and no
Indy there (unless MS... well... nevermind<g>).
We'll be heads down on another project for the next few days
but may get a chance to look at this critter again "by
accident".
Dan
"Jean-Marie Babet" <XXXX@XXXXX.COM>writes

On Thu, 17 Jan 2008 03:45:54 +0100, Dan Barclay <XXXX@XXXXX.COM>writes:
our customers with it: You don't happen to use Norton Internet Security?
The other thing that comes to my mind when I read your message is an old
issue we had years ago. Network traffic was sometimes so unbearably slow
on some machines that you could use a (human) carrier network instead and
be faster...
The solution was to configure the network cards "properly". They were all
set to auto-negotiate the connection. With 10MBit or 100MBit everything
worked fine. It was certainly a drver issue, but you could try it anyway.
Stefan
 

Hi Stefan, thanks for the response.
We're not using Norton, and other network traffic is fast.
This server is at a remote site connected via routing across
several network segments. In the network monitor we're
seeing "reassembled pdu" messages. I am guessing that means
one of the off site segments is not honoring the maximum
segment size, possibly going through a vpn or other link.
That would cause it to break packets apart and {*word*88} some
things down. Just a guess.
I tried cutting my mtu down as low as possible and the
segment sizes didn't change. I am not a network expert so
I'll just have to get one involved. it is more of a
nuiscence than anything at the moment. We're programming
for functionality right now, and we're confident we won't
have the response problems in a production environment.
Dan
"Stefan M. Huber" <XXXX@XXXXX.COM>writes

Bruneau,
I think we've figured this thing out. It appears it is slow
because, well, it is slow.
One of the links between us and the server is 56k. Sending
175k over that slow link from the math comes to 56kbits/sec
= 7kbytes/sec. About 25 seconds without accounting for
overhead and such.
Our previous traffic over that route has been small packet
(50 to 1000 bytes).
Thanks for the response, but this has nothing to do with
SOAP other than the big axx data this service requires.
Dan
"Jean-Marie Babet" <XXXX@XXXXX.COM>writes

Thanks for the follow-up post! Glad to read that the issue is understood.
Your post prompted me to think of adding timing measurements to our unit
tests - something we don't currently have.
Cheers,
Bruneau.
 

By the way, one of the things that initially pointed
(misdirected) me to the client machine response was packet
timing info in Ethereal. I am going to have to track down
what's going on there when I get time.
The way we read the trace, using "time between packets", the
client machine was slow to respond. Given that there is a
slow link it should have appeared that the server was slow
to respond (the sniffer is on the client end). I am not
sure what caused the timing info to show up as it did.
So... if someone is tracking something like this down they
may want to confirm what's going on with the trace timing
before drawing any conclusions.
Dan
"Jean-Marie Babet" <XXXX@XXXXX.COM>writes