Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through
Дата
Msg-id 19555.1139585881@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through  (Arnaud Lesauvage <thewild@freesurf.fr>)
Ответы Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through  (Arnaud Lesauvage <thewild@freesurf.fr>)
Список pgsql-odbc
Arnaud Lesauvage <thewild@freesurf.fr> writes:
> OK, but Magnus is affirmative that TCP_NO_DELAY is enabled on both
> the client and the server.
> So sending ACKs more frequently should not change the behaviour of
> the Nagle algorithm.

Yeah.  The speculations quoted in
http://archives.postgresql.org/pgsql-odbc/2006-02/msg00046.php
as to the server behavior were completely wrong: we do use NODELAY
and we don't have any weird zero-copy algorithm.  However, it is
true that we push out data in 8K bufferloads, which doesn't match
well to typical TCP MTU sizes.  I've occasionally wondered whether
we should not try to make the bufferload a multiple of the MTU
size when using a TCP connection, just so that no "short" packets
get sent unnecessarily.  (For a known MTU length, it'd be trivial
to change the hard-wired buffer size on the server side just to
experiment and see if there's any speedup.)

None of this explains why odbc is slow when psql isn't, though,
especially not if you are using one of the recent odbc releases
that relies on libpq.  The wire-level behavior certainly ought
to be the same for anything using libpq ...

            regards, tom lane

В списке pgsql-odbc по дате отправления:

Предыдущее
От: Shelby Cain
Дата:
Сообщение: Re: Problem using ODBC from .NET framework
Следующее
От: Arnaud Lesauvage
Дата:
Сообщение: Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through