On mercredi, 14 juin 2017 10.13:44 h CEST Dave Page wrote: > On Wed, Jun 14, 2017 at 9:07 AM, Mike Surcouf <mi...@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.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
