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
