Rick Jones wrote:
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?
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)
We're kind of stuck using gsoap. We like the toolkit and have a lot of
code using it. Fortunately, none of our packets will be going on the
internet.
The same problem exists using the latest version of gsoap, so they are
still utilizing small packets. I am planning on mentioning this to them
occasionally on their list.
We noticed an interesting dynamic in the way the TCP ACK delay is
applied to our transactions. The gsoap toolkit has an internal
"keep_alive" variable that regulates the number of transactions a client
can make to the server on a given connection. We've always used the
default of 100.
In the tcpdump, we see that the first 40 ms. ACK delay is applied just
after the TCP window ramps up on a new connection. We get additional ACK
delays applied for the next 22 transactions, then it stops--no more
delays are seen in the remaining 77 transactions. Then the keep_alive
has counted to zero, and the client is forced to reconnect to the
server, and the process repeats--23 ACK delays, then 77 unmolested
transactions.
Changing the keep_alive to 10,000 (we write all our clients, not worried
about abuse) drops the ACK delay count to about 27/13,000 transactions,
much better than the 3000 delays originally seen. Another option is to
sysctl tcp_abc off, if we have to.
I wonder if client applications are being charged for the initial SYN
packets, or something else odd is happening in the ABC algorithm as the
TCP window is growing?
---
John
-
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
