FreeTDS Development Group

[Rusty Conover <rconover AT zootweb.com>]

On Thu, 03 Aug 2000 00:06:51 James Cameron wrote:
> Rusty Conover wrote:
> > Hey, if you come up with a better solution let me know, but TCP_NODELAY
> > does serve a purpose here to get the SQL query sent to the server as
> > quickly as possible.  I'd rather not wait for data coming from the
> > server when I'm serving a web page.  Essentially this argument is six
> > and one half dozen the other.
> 
> No, not really.  TCP_NODELAY has knock-on effects that can be really bad
> for your network.  Sure, use it to fix the problem, but understand
> please that it can make things suck badly.  If you have spare network
> capacity, and the link is local, I would not worry.
> 
> Turning it on just for the duration of a query, rather than for the
> duration of a connection should reduce the impact significantly.
> 
> Having to turn on TCP_NODELAY to fix a protocol problem almost always
> hints at a failure to follow the protocol properly by one end or the
> other, or a failure to allow for aggregation and splitting of the
> stream. This means that even with TCP_NODELAY set, it may not fix the
> problem every time!
> 
> http://www.cs.ruu.nl/wais/html/na-dir/unix-faq/socket.html

Ok well after throughly reading the diatribe, I've come up with what I think 
it
as the heart of the problem.  The default packet size is locked at 512 bytes,
which means that write() will be called at every 512 bytes.  That sucks cause
when the data to be sent if 513 byte write gets called first for 512 bytes 
then
again with 1 byte, which will probably wait for more data before sendings.  
The TDS
code in write.c should send 513 bytes with one write() call rather then
building up to 512 bytes then sending.

So I think that if we fix the problem of sending 512 byte chunks at a time the
issue should be resolved, by eliminating the excessive calls to write().  
Still
for a quick fix I've found that TCP_NODELAY works on 100 Mbit ethernet quite
nicely.  But feel free to let me know if this problem analysis is incorrect or
not.

Rusty
-- 
---------------------------------------------
Rusty Conover        | rusty AT zootweb.com 
Systems Programmer   | 406-586-5050 x226
Zoot Enterprises     | http://www.zootweb.com
---------------------------------------------