On Wed, 15 Mar 2006 20:13:01 -0800
Skunk Worx <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've taken a performance hit over localhost between kernels 2.6.14 and
> 2.6.15 in my client/server application.
>
> I'm trying to gut things down to a simple test case, in the meantime,
> this is what I've been discussing with the people at the fedora test list :
>
> This is only over localhost (lo). Two machines running client/server
> 2.6.15 over ether seem fine, as was 2.6.14.
>
> 2.6.14 : about one or two recv() calls out of 48,000 take nearly 40 ms.
> (no big deal--might add 80 ms. to a 20 second operation).
>
> 2.6.15 : about 3,000 recv() calls out of 48,000 take nearly 40 ms. (adds
> almost two minutes)
>
> 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.
>
This came up with java debugging already. The problem is when the sender
writes a message in separate write() system calls, each one becomes
a separate packet. In 2.6.15 we do a new thing called Appropriate Byte
Count and that penalizes stupid applications, but provides better fairness
over the internet by accounting for packets better.
If the application does:
write(socket, "<xml version =\", ...)
write(socket, "1.0", ...
write(socket, "\" encoding = ", ...
then finally
read(socket, response)
then after the second write system call, the next write will wait
until a TCP ack comes back. If the application was smart and used
writev() to do scatter gather, or buffering if using stdio; then the
data goes out in nice big chunks and there will be no problem.
-
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
