From: ktm@rice.edu <ktm@rice.edu>
To: belal hamed <belalhamed@gmail.com>
Cc: Richard Neill <rn214@richardneill.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL over internet
Date: Sun, 27 Jan 2013 11:33:28 -0600
Message-ID: <20130127173328.GA21220@aart.rice.edu> (raw)
In-Reply-To: <CAHsqH1zscRc6tQ32L-TPhZgqNqrE=rbL=onzi_5cNiF+M3R9Ew@mail.gmail.com>
References: <CAHsqH1zQUj5po-1eHK7j_z7k+VdHWNWBK7XfbCxuRskkAj5LSQ@mail.gmail.com>
<20130127024505.GA12423@aart.rice.edu>
<5104C570.2030001@richardneill.org>
<CAHsqH1zscRc6tQ32L-TPhZgqNqrE=rbL=onzi_5cNiF+M3R9Ew@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ktm@rice.edu, belalhamed@gmail.com, rn214@richardneill.org
Subject: Re: PostgreSQL over internet
In-Reply-To: <20130127173328.GA21220@aart.rice.edu>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox