TCP Sockets - Limiting one write at a time is harming performance (at least on windows)

[Leon Finker]

Yes, short-writes will cause a problem, but on windows with IOCP/overlapped
model short-writes are not observed in practice (unless resources are
depleted; in that case connection probably should be closed/cleaned up
anyway). Not sure about other platforms. 

Have you ever seen (with latest jdk build) that ByteBuffer#hasRemaining is
true in write's completed() on windows under stress (more likely to happen
on pre-Vista due to easier non-paged pool resource depletion)? Even though
Platform SDK IOCP sample does handle this case, I have not seen it being
handled in other production frameworks. Anyhow, something to ponder on. The
data throughput is definitely much better.

There are many posts on this, but here is one:
http://www.lenholgate.com/archives/000570.html


-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM] 
Sent: Tuesday, June 02, 2009 1:19 PM
To: Leon Finker
Cc: nio-dev at openjdk.java.net
Subject: Re: TCP Sockets - Limiting one write at a time is harming
performance (at least on windows)

Leon Finker wrote:
> Hi,
>
> I did some more testing on what seems to be the best combination on
multiple
> simultaneous outstanding writes/reads. I find that at least on windows the
> best option for writes is to set SO_SNDBUF size to 0 and schedule writes
as
> many as possible and not wait for single write to complete before
scheduling
> next one. It doesn't mean that application should schedule writes
non-stop.
> There can be a policy that application code can enforce. The data
throughput
> increase is 2x-3x in my tests.
>   
If you queue writes to a stream connection then a short-write will 
corrupt your stream.

-Alan.