A brief note on pipelines

General discussion and chat (archived)
dark_moon

A brief note on pipelines

Unread post by dark_moon » 2012-11-15, 19:44

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

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35640
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: A brief note on pipelines

Unread post by Moonchild » 2012-11-15, 20:23

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)
"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

dark_moon

Re: A brief note on pipelines

Unread post by dark_moon » 2012-11-16, 15:59

Thanks for your informations :)

Apollo702

Re: A brief note on pipelines

Unread post by Apollo702 » 2012-11-17, 23:34

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?


User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35640
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: A brief note on pipelines

Unread post by Moonchild » 2012-11-18, 04:00

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?
The default settings for Pale Moon are recommended for almost all setups. I'll give a quick listing of them:

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

Apollo702

Re: A brief note on pipelines

Unread post by Apollo702 » 2012-11-19, 02:14

Thank you!

Edit- Most of them were already correct. That was good to know.

greebo

Re: A brief note on pipelines

Unread post by greebo » 2012-11-19, 11:19

Moonchild wrote:network.http.max-connections 48 // Don't saturate the network layer (FF=256)
This is too low IMO.

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); :geek:


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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35640
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: A brief note on pipelines

Unread post by Moonchild » 2012-11-19, 13:22

greebo wrote:
Moonchild wrote:network.http.max-connections 48 // Don't saturate the network layer (FF=256)
This is too low IMO.

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
It's not too low. 48 for network.http.max-connections is concurrent HTTP connections.
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

greebo

Re: A brief note on pipelines

Unread post by greebo » 2012-11-21, 09:06

Moonchild 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.
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?

and i have browser.sessionstore.restore_on_demand set to false ;)
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 ...
sux for ppl with "right" (expensive) equipment.
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).
that the theory - like http://en.wikipedia.org/wiki/Explicit_C ... tification

unless you have some kind of QoS or big pipe - there will always be someone who will "hog" the pipe...

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35640
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: A brief note on pipelines

Unread post by Moonchild » 2012-11-21, 09:53

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?
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:
..., 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.

greebo wrote:sux for ppl with "right" (expensive) equipment.
No, it doesn't ;)
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

greebo

Re: A brief note on pipelines

Unread post by greebo » 2012-11-21, 11:42

Moonchild wrote:Your own "right" equipment isn't the only equipment involved.
but it sux to be the only one playing "nice". :|
Chrome* is very aggresive on connections, prefetching and such.

It does bloody fsk** show on resource monitor, but the "browsing" experience is :)