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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
