On Sun, Jan 27, 2013 at 03:09:55PM +0300, belal hamed wrote:
> >Here is your "problem". You need to understand the performance
> >characteristics of your communication channel. ADSL is a VERY
> >asymmetric communications channel. Down is usually much faster
> >than up.
>
> How it could be ADSL problem when it's the same in tow tests ?
> beside data transferred when using tunnel is much bigger (about 10KB) than
> direct connection (400B)
> so it should be slower when using tunnel but the result shows it was faster
> !!!!
>
Due to the asymmetric communication, a bigger data output in a single
packet (the result of using compression on the tunnel) will get sent
without waiting. A smaller packet will delay a bit waiting for some
additional data, which in your case does not come. You may want to
check out this document describing some of what I believe is causing
your observed behavior:
http://www.faqs.org/docs/Linux-HOWTO/ADSL-Bandwidth-Management-HOWTO.html#BACKGROUND
> >When you wrap the communication channel in an IP tunnel, you are
> >collapsing much of the syn-ack of the libpq protocol. You can see
> >the same effect trying to run any sort of X windows application.
>
> If that so, why these is not same option in Postgresql, Is it necessary to
> use IP tunnel to do that and perform fast fetch?
>
>
> >Try creating a simple SSH tunnel
> my server is windows 7
>
> >It should be possible to distinguish between:
> > - slowness caused by the database query itself
> > - slowness caused by the network fundamentally.
> > - slowness caused by the postgresql/libpq.
>
> I run the same query on same network connection so I eliminate the
> slowness caused by the database query and network fundamentally,
> nothing left but postgresql/libpq
>
> not anyone consider there may be a bug when connection to a remote server
> over internet in libpq
> the only different when I used the tunnel is I connect to localhost
> instead of server IP or domain name (I try both)
You would find that if you log in to your DB server and use libpq
to it over a localhost connection that the performance is good which
points to your network as the problem.
Regards,
Ken