FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

On Thu, 3 Aug 2000, Rusty Conover wrote:

> 
> 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

This is a feature of the protocol, specifically MS SQL 7.0 doesn't seem to
handle one big packet with multiple blocks in it.  I'm afraid we have to
work with it, Sybase doesn't seem to suffer this limitation.

Brian

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