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