Am 25.04.2017 um 23:29 schrieb Jim Weill:
> I have been experiencing a problem with web pages refusing to load for
> more than 60 seconds in some cases since updating to the newest version
> of the 52.x track.  My office internet is a 1Gbps incoming line, of
> which I usually get no less than 10Mbps when there is high traffic on
> the line.
> 
> I am finding that such disparate sites as google, facebook, and other
> high-reliability sites sit and spin at random times throughout the day. 
> If I open a command line and ping that site, I get a ping time of 3-10ms
> and very little deviation from the time on a continuous ping (i.e. no
> single ping taking more than the time specified, or nslookup errors,
> etc).  Yet the site sits and spins for far too long before eventually
> loading correctly. Is there a preference I have set wrong that's causing
> this, or is this behavior also being noticed by anyone else on this
> release track?

We had very slow page loads over https with some uplink proxies behind
our Squid proxy, specially when those uplink proxies broke up https.
This happened with both FF ESR versions, 45 and 52.

Speed improved significantly after we disabled pipelining for these
cases, setting network.http.pipelining to false. Seems that some
commercial firewalls use proxy software that has issues with pipelining.
Maybe FF or Squid do something unusual in these cases, although our
Squid only forwards the https connection with CONNECT to the uplink proxy.

As our clusters store home dirs on CephFS, we also had problems with the
excessive use of fsync() calls in the Firefox configuration interface.
fsync() is slow on network mounts. With a simple preloaded wrapper lib
we enforced the use of fdatasync() instead of fsync(), this improved
reaction time from several seconds (!) per key pressed to a fraction of
a second. Interestingly, this also seems to improve page loading time,
probably related to history storage in sqlite databases, which also use
fsync().

Finally, some customer DNS forwarders do not support EDNS, switching
EDNS off in our internal DNS forwarder also improved loading complex
pages with their many DNS lookups.

Hope this helps...


Amon Ott
-- 
Dr. Amon Ott
m-privacy GmbH           Tel: +49 30 24342334
Werner-Voß-Damm 62       Fax: +49 30 99296856
12101 Berlin             http://www.m-privacy.de

Amtsgericht Charlottenburg, HRB 84946

Geschäftsführer:
 Dipl.-Kfm. Holger Maczkowsky,
 Roman Maczkowsky

GnuPG-Key-ID: 0x2DD3A649

_______________________________________________
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Reply via email to