A brief note on pipelines
A brief note on pipelines
I found a site which talks a little bit about the (not so good?) pipelining feature
pipelines do marginally reduce queuing time, but not by a heck of a lot in practice. (~65% of transactions are sent within 50ms using straight HTTP, ~75% with pipelining enabled)
http://bitsup.blogspot.de/2012/11/a-bri ... refox.html
pipelines do marginally reduce queuing time, but not by a heck of a lot in practice. (~65% of transactions are sent within 50ms using straight HTTP, ~75% with pipelining enabled)
http://bitsup.blogspot.de/2012/11/a-bri ... refox.html
-
- Pale Moon guru
- Posts: 35640
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: A brief note on pipelines
This is why Pale Moon also uses a few other optimized networking settings.
This results in 2 different network approaches for the browsers:
Firefox: maximize concurrent connections per server. This gives good results on a fast network with fast switches/routers, and pipelining will not see much difference. This is not nice for slower routers or networks, in general, or shared high-traffic networks (Firefox will cause aggressive use of networking resources and can e.g. fill up NAT tables as a result).
Pale Moon: focus on using fewer concurrent connections with more enforced use of pipelining queues. This gives good results on any network and especially slower/wireless ones, because the number of connections is kept low and are used more efficiently. Pale Moon also keeps pipelining off for proxies - reducing issues with intermediaries.
Pipelining is awesome, IMHO. But you have to set up more than just the one switch to properly use it.
(moving this to tech chat)
This results in 2 different network approaches for the browsers:
Firefox: maximize concurrent connections per server. This gives good results on a fast network with fast switches/routers, and pipelining will not see much difference. This is not nice for slower routers or networks, in general, or shared high-traffic networks (Firefox will cause aggressive use of networking resources and can e.g. fill up NAT tables as a result).
Pale Moon: focus on using fewer concurrent connections with more enforced use of pipelining queues. This gives good results on any network and especially slower/wireless ones, because the number of connections is kept low and are used more efficiently. Pale Moon also keeps pipelining off for proxies - reducing issues with intermediaries.
Pipelining is awesome, IMHO. But you have to set up more than just the one switch to properly use it.
(moving this to tech chat)
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A brief note on pipelines
Please give us all of the relevant settings to check for. I previously had altered some of mine in Freezefox and then imported them into PM. I also have a somewhat slow connection( for the time being) of 1.5- and often times lower. Based on that environment what would be the correct settings?
-
- Pale Moon guru
- Posts: 35640
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: A brief note on pipelines
The default settings for Pale Moon are recommended for almost all setups. I'll give a quick listing of them:Apollo702 wrote:Please give us all of the relevant settings to check for. I previously had altered some of mine in Freezefox and then imported them into PM. I also have a somewhat slow connection( for the time being) of 1.5- and often times lower. Based on that environment what would be the correct settings?
Code: Select all
network.prefetch-next false //prefetching engine off by default
network.http.pipelining true //pipelining on by default
network.http.pipelining.ssl true
network.http.proxy.pipelining false // don't pipeline proxy requests - breaks some proxies + AV
network.http.pipelining.maxrequests 12 // Max number of requests in the pipeline
network.http.max-connections 48 // Don't saturate the network layer (FF=256)
network.http.max-connections-per-server 8 // With pipelining, this should be low (FF=15)
network.http.max-persistent-connections-per-proxy 8
network.http.max-persistent-connections-per-server 6
network.dns.disablePrefetch true //Disable DNS prefetching to prevent router hangups
network.dnsCacheEntries 1024 //cache 1024 instead of 20
network.dnsCacheExpiration 3600 //TTL 1 hour
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A brief note on pipelines
Thank you!
Edit- Most of them were already correct. That was good to know.
Edit- Most of them were already correct. That was good to know.
Re: A brief note on pipelines
This is too low IMO.Moonchild wrote:network.http.max-connections 48 // Don't saturate the network layer (FF=256)
Sites have connections to img servers, ads.... so by visiting one site you open more than only one connections.
If you open more tabs ...then you might get "blank" tabs...
I set mine to 256 - Opera has this set to 64 and 16-per-server
and i use user_pref("network.http.request.max-start-delay", 1);
don't fix network problems with application settings.
Many OS and routers don't use proper ICMP firewall-settings and PMTU - http://en.wikipedia.org/wiki/Path_MTU_Discovery
for a quick fix/test in windows - http://www.speedguide.net/downloads.php
but please read the guide first.
-
- Pale Moon guru
- Posts: 35640
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: A brief note on pipelines
It's not too low. 48 for network.http.max-connections is concurrent HTTP connections.greebo wrote:This is too low IMO.Moonchild wrote:network.http.max-connections 48 // Don't saturate the network layer (FF=256)
Sites have connections to img servers, ads.... so by visiting one site you open more than only one connections.
If you open more tabs ...then you might get "blank" tabs...
I set mine to 256 - Opera has this set to 64 and 16-per-server
If you open a separate connection for each request (not using pipelining or keep-alive connections) then you may have a potential issue (getting delays) if you request a lot of pages at once, but normal HTTP traffic (HTTP1.1 by default, and HTTP1.0 by adding a keep-alive header) uses persistent connections (keep-alive) and not one connection per element. Even if you connect to subdomains for different elements (e.g. using a server cluster or CDN) you'd still not connect to more than a small handful of different servers. Pale Moon also does not load all tabs at once, but loads a fixed (configurable) number of simultaneous tabs to prevent further congestion this would otherwise cause.
From a browser point of view, letting the browser connect with as many concurrent connections as possible may be "giving yourself maximum headroom" but concurrent connections are expensive for the O.S. networking layer, especially on Windows, and will slow things down over e.g. wireless connections and can even hang up low-cost residential routers completely, especially if multiple people are browsing from different PCs at once. Keeping the maximum low forces the networking to more efficiently use the room available, and therefore more efficiently use persistent connections (and therefore pipelining that runs over those persistent connections).
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A brief note on pipelines
10 tabs and each connects to 5 different SERVERs (not elements) = 5 x 10 connections = 50Moonchild wrote:It's not too low. 48 for network.http.max-connections is concurrent HTTP connections.
...
, but normal HTTP traffic uses HTTP_persistent_connection] and not one connection per element.
...
Even if you connect to subdomains for different elements (e.g. using a server cluster or CDN) you'd still not connect to more than a small handful of different servers.
and that is higher than 48. or am i wrong?
and i have browser.sessionstore.restore_on_demand set to false
sux for ppl with "right" (expensive) equipment.Moonchild wrote:connections are expensive for the O.S. networking layer, especially on Windows, and will slow things down over e.g. wireless connections and can even hang up low-cost ...
that the theory - like http://en.wikipedia.org/wiki/Explicit_C ... tificationKeeping the maximum low forces the networking to more efficiently use the room available, and therefore more efficiently use persistent connections (and therefore pipelining that runs over those persistent connections).
unless you have some kind of QoS or big pipe - there will always be someone who will "hog" the pipe...
-
- Pale Moon guru
- Posts: 35640
- Joined: 2011-08-28, 17:27
- Location: Motala, SE
Re: A brief note on pipelines
No you're not wrong, but Pale Moon doesn't load 10 tabs concurrently. It will queue the tabs up for loading (if you do not use "Don't load tabs until selected") and loads a maximum of 3 concurrent tabs (= 15 concurrent servers in your scenario) at any time. Previously (< v8) you could "tweak" this value, but this was removed:greebo wrote:10 tabs and each connects to 5 different SERVERs (not elements) = 5 x 10 connections = 50
and that is higher than 48. or am i wrong?
..., browser.sessionstore.max_concurrent_tabs is no more. We’re no longer allowing you to specify a specific number of tabs to restore concurrently. Instead we now allow you to either restore on demand, or use the hard-coded 3 tabs at a time value.
No, it doesn'tgreebo wrote:sux for ppl with "right" (expensive) equipment.
Your own "right" equipment isn't the only equipment involved. The connections made to servers impact every hop from your system to the server. Using persistence/pipelining more efficiently will still speed things up (TCP handshaking takes time, especially if retransmissions are required for a high-latency connection to a distant server).
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite
Re: A brief note on pipelines
but it sux to be the only one playing "nice".Moonchild wrote:Your own "right" equipment isn't the only equipment involved.
Chrome* is very aggresive on connections, prefetching and such.
It does bloody fsk** show on resource monitor, but the "browsing" experience is