Re: [pgadmin-support] "pgadmin4" - slow?

On Wed, Jun 14, 2017 at 2:37 PM, Mike Surcouf <mikes@surcouf.co.uk> wrote:
> Are you listening on ipv6?

No, as mentioned it listens on 127.0.0.1.

> Because as mentioned that will create problems as the dns resolver always returns ::1 on windows

Yes.

> Would it not be better to listen on both version of ip

Probably, if we can come up with a reliable way of detecting which
protocols are available so early in the startup sequence.

However, it's the resolver that's slow here. Other users (of QtWebKit)
have noted the same problem, e.g.
https://stackoverflow.com/questions/3054060/very-slow-remote-page-load-performance-in-qtwebkit-windows

>
> -----Original Message-----
> From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Dave Page
> Sent: 14 June 2017 14:17
> To: Bruno Friedmann
> Cc: pgAdmin Support
> Subject: Re: [pgadmin-support] "pgadmin4" - slow?
>
> On Wed, Jun 14, 2017 at 1:55 PM, Bruno Friedmann <bruno@ioda-net.ch> wrote:
>> On mercredi, 14 juin 2017 10.13:44 h CEST Dave Page wrote:
>>> On Wed, Jun 14, 2017 at 9:07 AM, Mike Surcouf <mikes@surcouf.co.uk> wrote:
>>> > Static resources will be good for caching :-)  I would expect to
>>> > see performance gains when using remotely via a browser.  Thankyou.
>>> > I'm not sure whether QtWeb will benefit as much as its local
>>> > traffic so round trips should be pretty instantaneous. Unless QtWeb
>>> > is horribly inefficient in which case I hope it helps.
>>> Right - and on Windows, I think that is actually the problem which is
>>> why users have reported that running the server separately and using
>>> a regular browser makes a big difference.
>>>
>>> FYI, when I was testing on Windows over the weekend, in my test VM,
>>> simply changing "localhost" as the connection target in the runtime
>>> to "127.0.0.1" took the startup time from ~34 seconds to ~24. I lost
>>> count of how many times I tested that, but it was pretty consistent.
>>> That hints to me that the network side is what is less performant -
>>> obviously the resolver, but I suspect also connection setup which is
>>> why I have high hopes for web packing.
>>
>> Is this doesn't linked to the fact that localhost on modern system is
>> mapped to ::1 (the ipv6 loopback) and 127.0.0.1 the old ipv4 one.
>>
>> By default ipv6 is called first, then ipv4 the problem is the python
>> api is listening only on ipv4 :-)
>
> I don't think so - previously both the server and client were using 'localhost', so should have defaulted to either
127.0.0.1or ::1 depending on the system config.
 
>
> Now, both are using '127.0.0.1', which is what gained the 10 seconds I mentioned above. Of course, the downside of
thisis that it requires
 
> IPv4 on the users machine, but practically speaking I don't think that's likely to be an issue - is anyone really
runningIPv6 only?
 
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgadmin-support



-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company