Re: [pgadmin-support] "pgadmin4" - slow? - Mailing list pgadmin-support
Regardless of the upcoming problem resolution regarding slow start times, or any of the multitude of Reddit reports, I think PgAdmin developers should consider this a lesson learned and test on ALL platforms (IE:Mac, Windows, Linux) before releasing a new version.
Melvin Davidson 🎸
Cell 720-320-0155
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
www.youtube.com/unusedhero/videos
Folk Alley - All Folk - 24 Hours a day
www.folkalley.com
Cell 720-320-0155
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
www.youtube.com/unusedhero/videos
Folk Alley - All Folk - 24 Hours a day
www.folkalley.com
On Wednesday, June 14, 2017, 9:17:49 AM EDT, Dave Page <dpage@pgadmin.org> wrote:
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.1 or ::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 running IPv6 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
> 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.1 or ::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 running IPv6 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: