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

From Mike Surcouf
Subject Re: [pgadmin-support] "pgadmin4" - slow?
Date
Msg-id 2197768425D7F5479A0FFB3FEC212F7FF5E8AD86@aesmail.surcouf.local
Whole thread Raw
In response to Re: [pgadmin-support] "pgadmin4" - slow?  (Dave Page <dpage@pgadmin.org>)
List pgadmin-support
Are you listening on ipv6?
Because as mentioned that will create problems as the dns resolver always returns ::1 on windows 
Would it not be better to listen on both version of ip

-----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
isthat 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

pgadmin-support by date:

Previous
From: Dave Page
Date:
Subject: Re: [pgadmin-support] "pgadmin4" - slow?
Next
From: Dave Page
Date:
Subject: Re: [pgadmin-support] "pgadmin4" - slow?