Обсуждение: [pgadmin-support] "pgadmin4" - slow?
Is it just me or is “pgadmin4” just terribly slow?
I’m running it on a capable HP Laptop (it runs Postgres itself very well) but “pgadmin4” seems impossibly slow.
Connecting to my Postgres from the local machine doesn’t seem to be the bottleneck (I have a Laravel application that runs just as well with php’s pdo_pgsql as well as pdo_mysql).
Any ideas?
DSL
The test machine is a Windows 7 VirtualBox VM. The host has a 4GHz processor and an SSD. The host network connection uses an AC 1200 WiFi card. I believe I'm testing the desktop version of pgAdmin4 since I'm opening it from the Windows start button.
Starting pgAdmin4: 32 seconds to show "Servers" in the browser tree and show the opening page.
When I click the plus (+) sign next to servers it takes 5 seconds for my two local servers to show up. These are on two separate KVM Linux VMs.
It takes between 2 and 6 seconds to open each item in the database browser tree.
I opened a table of 16,000 rows by clicking on the View All Rows button. It took 3 seconds to open even though pgAdmin4 said it took only 1 second. In pgAdmin3 on the host machine it took about 1.5 seconds.
I opened a view that has almost 200,000 rows. In pgAdmin3 it takes 7 seconds. pgAdmin4 says it took 5 seconds but it really took 8 seconds. Overall, the time is comparable between the two versions.
This is very encouraging because when I first tried pgAdmin4 I found it to be too annoying to use. I will now give it another try.
Is it just me or is “pgadmin4” just terribly slow?
I’m running it on a capable HP Laptop (it runs Postgres itself very well) but “pgadmin4” seems impossibly slow.
Connecting to my Postgres from the local machine doesn’t seem to be the bottleneck (I have a Laravel application that runs just as well with php’s pdo_pgsql as well as pdo_mysql).
Any ideas?
DSL
A 32 second startup time and a 2-6 seconds to expand each node is encouraging?
From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Patrick Headley
Sent: 14 June 2017 01:23
To: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] "pgadmin4" - slow?
While I still wish pgAdmin4 was faster to start up I installed pgAdmin4 v1.5 today and performed some tests. Here's what I found.
The test machine is a Windows 7 VirtualBox VM. The host has a 4GHz processor and an SSD. The host network connection uses an AC 1200 WiFi card. I believe I'm testing the desktop version of pgAdmin4 since I'm opening it from the Windows start button.
Starting pgAdmin4: 32 seconds to show "Servers" in the browser tree and show the opening page.
When I click the plus (+) sign next to servers it takes 5 seconds for my two local servers to show up. These are on two separate KVM Linux VMs.
It takes between 2 and 6 seconds to open each item in the database browser tree.
I opened a table of 16,000 rows by clicking on the View All Rows button. It took 3 seconds to open even though pgAdmin4 said it took only 1 second. In pgAdmin3 on the host machine it took about 1.5 seconds.
I opened a view that has almost 200,000 rows. In pgAdmin3 it takes 7 seconds. pgAdmin4 says it took 5 seconds but it really took 8 seconds. Overall, the time is comparable between the two versions.
This is very encouraging because when I first tried pgAdmin4 I found it to be too annoying to use. I will now give it another try.
Patrick Headley
Linx Consulting, Inc.
pheadley@linxco-inc.com
(303) 916-5522
www.linxco-inc.com
On 06/13/2017 05:26 PM, David Lloyd wrote:
Is it just me or is “pgadmin4” just terribly slow?
I’m running it on a capable HP Laptop (it runs Postgres itself very well) but “pgadmin4” seems impossibly slow.
Connecting to my Postgres from the local machine doesn’t seem to be the bottleneck (I have a Laravel application that runs just as well with php’s pdo_pgsql as well as pdo_mysql).
Any ideas?
DSL
On Wed, Jun 14, 2017 at 8:29 AM, Mike Surcouf <mikes@surcouf.co.uk> wrote: > A 32 second startup time and a 2-6 seconds to expand each node is > encouraging? Unless you're on a slow connection, the node expansion time should be extremely quick the second and subsequent times in a session, and even then the delay should only occur for a small number of key nodes. That's because it's loading the code for them on first expansion. We're working on getting rid of that - whilst it works fine on non-Windows platforms (i.e. the initial delay is measured in fractions of a second, not seconds), clearly as we've found it's a problem on Windows. The work a number of people are currently doing involved making as much of the code static as possible (so it doesn't need to go through the templating engine), and then minimising and web packing it so it all loads at once. This will significantly reduce the number of round-trips between the browser and client, as well as the bandwidth required. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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. -----Original Message----- From: Dave Page [mailto:dpage@pgadmin.org] Sent: 14 June 2017 08:56 To: Mike Surcouf Cc: Patrick Headley; pgadmin-support@postgresql.org Subject: Re: [pgadmin-support] "pgadmin4" - slow? On Wed, Jun 14, 2017 at 8:29 AM, Mike Surcouf <mikes@surcouf.co.uk> wrote: > A 32 second startup time and a 2-6 seconds to expand each node is > encouraging? Unless you're on a slow connection, the node expansion time should be extremely quick the second and subsequent times ina session, and even then the delay should only occur for a small number of key nodes. That's because it's loading the code for them on first expansion. We're working on getting rid of that - whilst it works fine on non-Windows platforms (i.e. the initial delay is measuredin fractions of a second, not seconds), clearly as we've found it's a problem on Windows. The work a number of peopleare currently doing involved making as much of the code static as possible (so it doesn't need to go through the templatingengine), and then minimising and web packing it so it all loads at once. This will significantly reduce the numberof round-trips between the browser and client, as well as the bandwidth required. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
[Yes, I’m on Windows 10]
It does appear that the tool’s (or should I say those of the upstream browser kit / underlying platform) seem to resolve `localhost` very slowly; it seems about as slow as either a DNS resolver timeout or a network isn’t there. Others mention rewriting the host entry from `localhost` to `127.0.01` which I did and it does connect to the database faster.
To me this implies:
· DNS resolution is slow; or
· It’s resolved an IPv6 address, found that it can’ connect and then falls back to IPv4.
That said, it still takes at least a minute to even load the program. I can figure out which of the above two it is but it’s not pressing on my time now (because my alternative simply just works and quickly).
That said, it’s difficult to argue that a 30+ second start up time for the user interface to become responsive (as opposed to useful) is encouraging and whilst I’m no every day user and might be encouraged by such oddities to fall back on the faster, and some would arguably say more powerful, shell with `psql`, others might have simply not used the tool, i.e. pgadmin4, or worse concluded that Postgresql itself is the issue.
Does the tool expose any underlying http/web-like server (i.e. is the tool simply spawning some sort of web process and the GUI is just a web-browser in a window talking to it)? And more to the point, is there a way I can point another browser at it? Were this the case, one could explore another avenue by pointing some other browser with/without caching on to see if the GUI itself is the pain point?
DSL
From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Patrick Headley
Sent: Tuesday, 13 June 2017 8:23 PM
To: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] "pgadmin4" - slow?
While I still wish pgAdmin4 was faster to start up I installed pgAdmin4 v1.5 today and performed some tests. Here's what I found.
The test machine is a Windows 7 VirtualBox VM. The host has a 4GHz processor and an SSD. The host network connection uses an AC 1200 WiFi card. I believe I'm testing the desktop version of pgAdmin4 since I'm opening it from the Windows start button.
Starting pgAdmin4: 32 seconds to show "Servers" in the browser tree and show the opening page.
When I click the plus (+) sign next to servers it takes 5 seconds for my two local servers to show up. These are on two separate KVM Linux VMs.
It takes between 2 and 6 seconds to open each item in the database browser tree.
I opened a table of 16,000 rows by clicking on the View All Rows button. It took 3 seconds to open even though pgAdmin4 said it took only 1 second. In pgAdmin3 on the host machine it took about 1.5 seconds.
I opened a view that has almost 200,000 rows. In pgAdmin3 it takes 7 seconds. pgAdmin4 says it took 5 seconds but it really took 8 seconds. Overall, the time is comparable between the two versions.
This is very encouraging because when I first tried pgAdmin4 I found it to be too annoying to use. I will now give it another try.
Patrick Headley
Linx Consulting, Inc.
pheadley@linxco-inc.com
(303) 916-5522
www.linxco-inc.com
On 06/13/2017 05:26 PM, David Lloyd wrote:
Is it just me or is “pgadmin4” just terribly slow?
I’m running it on a capable HP Laptop (it runs Postgres itself very well) but “pgadmin4” seems impossibly slow.
Connecting to my Postgres from the local machine doesn’t seem to be the bottleneck (I have a Laravel application that runs just as well with php’s pdo_pgsql as well as pdo_mysql).
Any ideas?
DSL
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 :-) Python Flask upstream limits ? (Well they not alone in that case) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.chBareos Partner, openSUSE Member, fsfe fellowshipGPG KEY : D5C9B751C4653227irc:tigerfoot
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
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 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
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.
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
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
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
> 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
On Wed, Jun 14, 2017 at 4:05 PM, Mike Surcouf <mikes@surcouf.co.uk> wrote: >> 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 performanceproblem in QTWeb. Right; that's my hope as well. I don't think we ever envisaged that there would be that much when we started the project, but all the JS libraries needed for UI rendering and MVC etc. sure do add up. > 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 Yeah, that one is on my TODO to fix. > > > -----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 -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
A 32 second startup time and a 2-6 seconds to expand each node is encouraging?
From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Patrick Headley
Sent: 14 June 2017 01:23
To: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] "pgadmin4" - slow?
While I still wish pgAdmin4 was faster to start up I installed pgAdmin4 v1.5 today and performed some tests. Here's what I found.
The test machine is a Windows 7 VirtualBox VM. The host has a 4GHz processor and an SSD. The host network connection uses an AC 1200 WiFi card. I believe I'm testing the desktop version of pgAdmin4 since I'm opening it from the Windows start button.
Starting pgAdmin4: 32 seconds to show "Servers" in the browser tree and show the opening page.
When I click the plus (+) sign next to servers it takes 5 seconds for my two local servers to show up. These are on two separate KVM Linux VMs.
It takes between 2 and 6 seconds to open each item in the database browser tree.
I opened a table of 16,000 rows by clicking on the View All Rows button. It took 3 seconds to open even though pgAdmin4 said it took only 1 second. In pgAdmin3 on the host machine it took about 1.5 seconds.
I opened a view that has almost 200,000 rows. In pgAdmin3 it takes 7 seconds. pgAdmin4 says it took 5 seconds but it really took 8 seconds. Overall, the time is comparable between the two versions.
This is very encouraging because when I first tried pgAdmin4 I found it to be too annoying to use. I will now give it another try.Patrick Headley
Linx Consulting, Inc.
pheadley@linxco-inc.com
(303) 916-5522
www.linxco-inc.comOn 06/13/2017 05:26 PM, David Lloyd wrote:
Is it just me or is “pgadmin4” just terribly slow?
I’m running it on a capable HP Laptop (it runs Postgres itself very well) but “pgadmin4” seems impossibly slow.
Connecting to my Postgres from the local machine doesn’t seem to be the bottleneck (I have a Laravel application that runs just as well with php’s pdo_pgsql as well as pdo_mysql).
Any ideas?
DSL
Yes but it’s still too slow.
High request count on start up, un-cachable files resulting in rerading the same file over and over, un-minified js files, synchronous loading, some QtWeb issues all contributing.
There is plenty to work on and I am hopeful the pgadmin team can make some big improvements.
From: Patrick Headley [mailto:pheadley@linxco-inc.com]
Sent: 14 June 2017 16:57
To: Mike Surcouf; pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] "pgadmin4" - slow?
It used to take longer. Now, after starting up the times are comparable to pgAdmin3.
Patrick Headley
Linx Consulting, Inc.
pheadley@linxco-inc.com
(303) 916-5522
www.linxco-inc.com
On 06/14/2017 01:29 AM, Mike Surcouf wrote:
A 32 second startup time and a 2-6 seconds to expand each node is encouraging?
From: pgadmin-support-owner@postgresql.org [mailto:pgadmin-support-owner@postgresql.org] On Behalf Of Patrick Headley
Sent: 14 June 2017 01:23
To: pgadmin-support@postgresql.org
Subject: Re: [pgadmin-support] "pgadmin4" - slow?
While I still wish pgAdmin4 was faster to start up I installed pgAdmin4 v1.5 today and performed some tests. Here's what I found.
The test machine is a Windows 7 VirtualBox VM. The host has a 4GHz processor and an SSD. The host network connection uses an AC 1200 WiFi card. I believe I'm testing the desktop version of pgAdmin4 since I'm opening it from the Windows start button.
Starting pgAdmin4: 32 seconds to show "Servers" in the browser tree and show the opening page.
When I click the plus (+) sign next to servers it takes 5 seconds for my two local servers to show up. These are on two separate KVM Linux VMs.
It takes between 2 and 6 seconds to open each item in the database browser tree.
I opened a table of 16,000 rows by clicking on the View All Rows button. It took 3 seconds to open even though pgAdmin4 said it took only 1 second. In pgAdmin3 on the host machine it took about 1.5 seconds.
I opened a view that has almost 200,000 rows. In pgAdmin3 it takes 7 seconds. pgAdmin4 says it took 5 seconds but it really took 8 seconds. Overall, the time is comparable between the two versions.
This is very encouraging because when I first tried pgAdmin4 I found it to be too annoying to use. I will now give it another try.Patrick Headley
Linx Consulting, Inc.
pheadley@linxco-inc.com
(303) 916-5522
www.linxco-inc.comOn 06/13/2017 05:26 PM, David Lloyd wrote:
Is it just me or is “pgadmin4” just terribly slow?
I’m running it on a capable HP Laptop (it runs Postgres itself very well) but “pgadmin4” seems impossibly slow.
Connecting to my Postgres from the local machine doesn’t seem to be the bottleneck (I have a Laravel application that runs just as well with php’s pdo_pgsql as well as pdo_mysql).
Any ideas?
DSL
Now, we have 2019 - March. I'm running the latest version of OSX (10.14.3 (18D109)), Firefox 65.0.1 (64-Bit) I've got 4 dbs configured for pgAdmin, version 4.3 Opening a Server in a test network, 1 switch away, 1GB network takes more than 40 seconds (I stopped counting...) although the db has only the std schemas. To query for the list of schemas should not take as long as this... With every version I'm hoping... but... Sorry... -- Sent from: http://www.postgresql-archive.org/PostgreSQL-pgadmin-support-f2191615.html
Now, we have 2019 - March.
I'm running the latest version of OSX (10.14.3 (18D109)), Firefox 65.0.1
(64-Bit)
I've got 4 dbs configured for pgAdmin, version 4.3
Opening a Server in a test network, 1 switch away, 1GB network takes more
than 40 seconds (I stopped counting...) although the db has only the std
schemas. To query for the list of schemas should not take as long as this...
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company