Skunk Worx wrote:
Rick Jones wrote:
From strace :
15:27:04.568800 recv(3, "<?xml version=\"1.0\" encoding=\"UT"...,
555, ) = 555 <0.000121>
vs.
15:18:24.515891 recv(3, "<?xml version=\"1.0\" encoding=\"UT"...,
566, ) = 566 <0.038414>
Will watch replies and post more when I know more. Kinda new at this.
Do you have the strace from the sending side?
Yes...I hope I'm not posting too much info but here goes. It's worth
mentioning that this data is never on the internet, only isolated lan or
loopback. We are using an older version of the GSOAP toolkit (a
sourceforge project) and are in the process of porting to their latest
version.
In addition to the straces below, I have ethereal screencaps in jpeg
format if anyone wants to see those...2 x ~400k. ea.
Thanks everyone for pondering this. I tried to get the socket setup and
several full transactions from each side of loopback.
---
John
Server side:
15:15:11.267781 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 <0.000033>
15:15:11.267885 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
<0.000015>
15:15:11.267970 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
<0.000014>
15:15:11.268051 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
<0.000014>
15:15:11.268133 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000016>
Sigh, still another application abusing TCP_NODELAY. Quelle surprise.
15:15:11.268216 bind(3, {sa_family=AF_INET, sin_port=htons(8080),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0 <0.000020>
15:15:11.268318 listen(3, 100) = 0 <0.000043>
15:15:11.268433 getsockname(3, {sa_family=AF_INET, sin_port=htons(8080),
sin_addr=inet_addr("0.0.0.0")}, [16]) = 0 <0.000015>
<snip>
15:18:23.624649 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) <0.000014>
15:18:23.624724 fcntl64(3, F_SETFL, O_RDWR) = 0 <0.000013>
15:18:23.624799 accept(3, {sa_family=AF_INET, sin_port=htons(57058),
sin_addr=inet_addr("127.0.0.1")}, [16]) = 4 <0.000023>
15:18:23.624939 setsockopt(4, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
<0.000015>
15:18:23.625021 setsockopt(4, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
<0.000014>
15:18:23.625101 setsockopt(4, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
<0.000014>
15:18:23.625180 setsockopt(4, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000014>
I wonder how many of those previous four setsockopts could have been
inherited from the listen socket?
15:18:23.625316 recv(4, "POST / HTTP/1.1\r\nHost: localhost"..., 32768,
0) = 593 <0.000018>
15:18:23.625542 send(4, "HTTP/1.1 200 OK\r\nServer: gSOAP/2"..., 129, 0)
= 129 <0.000114>
15:18:23.625787 send(4, "236\r\n", 5, 0) = 5 <0.000076>
15:18:23.625937 send(4, "<?xml version=\"1.0\" encoding=\"UT"..., 566,
0) = 566 <0.000117>
15:18:23.626133 send(4, "\r\n0\r\n\r\n", 7, 0) = 7 <0.000167>
And there you have it - four separate sends for logically associated
data, when there should have been just the one sendmsg or writev call.
Given the sizes involved, that is roughly three to four times as much
CPU consumed to send that data is should have been - for "small" packets
you can handwave that the CPU cost is "per-packet" rather than
"per-byte" (OK, not _strictly_ true for say that 566 byte chunk, but for
the rest basically true)
Client side :
15:16:05.012862 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 <0.000029>
15:16:05.012960 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [32768], 4) = 0
<0.000016>
15:16:05.013045 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [32768], 4) = 0
<0.000015>
15:16:05.013125 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0 <0.000017>
<snip>
15:16:05.019312 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) <0.000014>
15:16:05.019388 fcntl64(3, F_SETFL, O_RDWR) = 0 <0.000014>
15:16:05.019463 connect(3, {sa_family=AF_INET, sin_port=htons(8080),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0 <0.000815>
<snip>
15:18:23.624100 send(3, "POST / HTTP/1.1\r\nHost: localhost"..., 593, 0)
= 593 <0.000087>
At least the client is doing the right thing with its requests.
15:18:23.624313 recv(3, "HTTP/1.1 200 OK\r\nServer: gSOAP/2"..., 32768,
0) = 129 <0.002025>
15:18:23.626445 recv(3, "236\r\n<?xml version=\"1.0\" encodin"...,
32768, 0) = 578 <0.000020>
That would have been just the one recv() call had the sender been doing
things properly...
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
