From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Mike Surcouf <mikes(at)surcouf(dot)co(dot)uk> |
Cc: | Patrick Headley <pheadley(at)linxco-inc(dot)com>, "pgadmin-support(at)postgresql(dot)org" <pgadmin-support(at)postgresql(dot)org> |
Subject: | Re: "pgadmin4" - slow? |
Date: | 2017-06-14 08:13:44 |
Message-ID: | CA+OCxowEMMQP0Gr=YMoY_odhquZFRyx6qvVnwPPFDO_fwqrCNg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
On Wed, Jun 14, 2017 at 9:07 AM, Mike Surcouf <mikes(at)surcouf(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2017-06-14 08:40:03 | Re: Serious feedback and questions about the future of pgAdmin. |
Previous Message | Mike Surcouf | 2017-06-14 08:07:23 | Re: "pgadmin4" - slow? |