FreeTDS Development Group

["ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>]

> 
> >I recently run into lag issue for queries that splited on 
> more then one 
> >packet.
> 
> >Here is the full descrption: 
> >http://moshe.i-com-it.com/issues/mssql.html
> 
> >From looking at your web page, I'd say that this sounds like 
> the kind 
> >of
> problem that the TCP_NODELAY socket option is supposed to solve.
> 
> I'm not familiar with the FreeTDS code -- I'm mostly a lurker 
> here. I don't know if FreeTDS has an option to set that or 
> not.  (Or even if it would be FreeTDS' responsibility -- that 
> might be something that would need to be set on the server end.)
> 
> What do packet traces of similar queries look like when 
> Microsoft tools are used?
> 
> Craig Jackson
> Craig.Jackson AT thomson.com
> The Gale Group, a unit of Thomson Corp 

I did some tests with TCP_NODELAY and 512 as packet size. Below are
results

Enabled
$ time ./utf8_2

real    0m1.202s
user    0m0.330s
sys     0m0.060s

Disabled
$ time ./utf8_2

real    0m52.626s
user    0m0.260s
sys     0m0.070s

Disabled, calling fsync after tds_write_packet
$ time ./utf8_2

real    0m39.315s
user    0m0.330s
sys     0m0.050s

similar result using sync(2) and fdatasync(2)

It's a very interesting option! However I don't know all disavantage it
can take. Anyone know a way to "flush" socket correctly?
By the way... attached a patch to enable TCP_NODELAY.

freddy77

Attachment: vedi.diff.gz
Description: vedi.diff.gz