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

> However, it's the resolver that's slow here.

Given the startup on my chrome browser generates 180 requests to the server side version  (I assume the QTweb version
wouldbe the same) I am also hopeful webpack in combination may help a lot.
 
180 requests is obviously not good for performance especially if each request is suffering from an inherent performance
problemin QTWeb.
 

I also see a warning about 
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's
experience.For more help, check https://xhr.spec.whatwg.org/.
 

look like your loading something via ajax with async:false


-----Original Message-----
From: Dave Page [mailto:dpage@pgadmin.org] 
Sent: 14 June 2017 14:44
To: Mike Surcouf
Cc: Bruno Friedmann; pgAdmin Support
Subject: 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 this is 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