Обсуждение: Re: TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through

Hi,

Why don't you use tcpdump, or another sniffer, in order to check that, and
post the result here?

-----Message d'origine-----
De : pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org] De la part de Arnaud Lesauvage
Envoyé : vendredi, 10. février 2006 17:01
À : Tom Lane
Cc : pgsql-odbc@postgresql.org
Objet : Re: [ODBC] TCP_NO_DELAY & TcpAckFrequency (Re: Slow query through

Tom Lane a écrit :
> 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 ...

Yes.
I am trying to figure out what the difference is between an ODBC call and a
"direct" call, from another application...
The issue might be at a higher level, but I have no clue right now...

Regards
--
Arnaud


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Philippe Lang a écrit :
> Why don't you use tcpdump, or another sniffer, in order to check that, and post the result here?

Hi,

Sure !
Here are the two dumps.
http://tehwild.free.fr/divers/dumps.zip
One is a TCP dump of the query through pgAdmin, the other one
through psqlODBC.
The first obvious difference is that the window size is not the
same, but I don't know how to interpret that.


Regards
--
Arnaud

Arnaud Lesauvage <thewild@freesurf.fr> writes:
>
> Sure !
> Here are the two dumps.
> http://tehwild.free.fr/divers/dumps.zip
> One is a TCP dump of the query through pgAdmin, the other one
> through psqlODBC.
> The first obvious difference is that the window size is not the same,
> but I don't know how to interpret that.

The best free tools I know to analyze such issues is tcptrace + xplot

<http://www.tcptrace.org/>

Arnaud Lesauvage <thewild@freesurf.fr> writes: 

Sure !
Here are the two dumps.
http://tehwild.free.fr/divers/dumps.zip
One is a TCP dump of the query through pgAdmin, the other one
through psqlODBC.
The first obvious difference is that the window size is not the same,
but I don't know how to interpret that.   

The best free tools I know to analyze such issues is tcptrace + xplot

<http://www.tcptrace.org/>




---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to      choose an index scan if your joining column's datatypes do not      match

 

O B a écrit :
> You may try "ethereal" which can give you more details than the TCP
> dumps with a structured view of packets and protocol layers.

The included dumps *are* ethereal dumps, actually.
There must be a reason why psqlODBC sets a different RWIN than the
other frontends (psql and pgAdmin), but I don't know which one.

Regards
--
Arnaud

O B <ob@kselnet.com> writes:

> You may try "ethereal" which can give you more details than the TCP
> dumps with a structured view of packets and protocol layers.

ethereal is a great general-purpose tool but is not good at analyzing
TCP performance issues, because you only get numbers.  With
tcptrace/xplot you get graphical timelines of sequence numbers and of
window sizes; I don't think ethereal can't match that. It's the same
difference between an excel spreadsheet and the corresponding graph.

Of course you have to be sure that your performance issue is somewhat
related to TCP parameters, else there is no need to go into tcptrace.

Arnaud Lesauvage <thewild@freesurf.fr> writes:

> O B a écrit :
>> You may try "ethereal" which can give you more details than the TCP
>> dumps with a structured view of packets and protocol layers.
>
> The included dumps *are* ethereal dumps, actually.

I think Olivier was talking about ethereal the browser, not about
ethereal the capture front-end.


> There must be a reason why psqlODBC sets a different RWIN than the
> other frontends (psql and pgAdmin), but I don't know which one.

By the way this is the receive buffer size on the _client_, right? (I
would be surprised that this indirectly changes server settings...)


On linux you can trace/check all modifications of the buffer sizes
like this:

 strace -e trace=setsockopt testcode

Marc Herbert a écrit :
> Arnaud Lesauvage <thewild@freesurf.fr> writes:
>> The included dumps *are* ethereal dumps, actually.
>
> I think Olivier was talking about ethereal the browser, not about
> ethereal the capture front-end.

OK, sorry for that, I did not know there was another ethereal.

>> There must be a reason why psqlODBC sets a different RWIN than the
>> other frontends (psql and pgAdmin), but I don't know which one.
>
> By the way this is the receive buffer size on the _client_, right? (I
> would be surprised that this indirectly changes server settings...)

Yes. As I wrote in my previous post, I don't know how to interpret
the logs.
BTW, I just realized that the URL to download the logs was
incorrect. The correct URL is http://thewild.free.fr/Divers/dumps.zip

> On linux you can trace/check all modifications of the buffer sizes
> like this:
>
>  strace -e trace=setsockopt testcode

I am on a WinXP box. It is pretty bad for debugging purposes of
course...

Reagards
--
Arnaud