[Bug 996151] Re: disable apt http pipelining in quantal

[David Kalnischkies]

per links can only be concluded that a ever-growing amount of webservers
and proxies prefer to violate a must requirement in the HTTP/1.1 spec
(rfc2616 section "8.1.2.2 Pipelining" second sentence: "A server MUST
send its responses to those requests in the same order that the requests
were received."), nothing else.

The link to the debian bts includes also the agreement of the squid-
proxy maintainer that squid should support a pipelining client hence a
still open bugreport against squid (which is not the same as supporting
pipelining! squid doesn't need to pipeline its own requests, it just
needs to ensure that it's responses are in the correct order). And while
i haven't tested it, the internet beliefs that newer squid versions
supports pipelining clients (and even pipelining for itself!).


As already said in the uds session (and after it) it's rather meaningless to perform a test on a single machine with a low-latency network connection. Obviously pipelining has only a benefit for the client if the connection is flaky/high-latency (like e.g. my phone). For the network in-between and the server it might be that it has to handle fewer packages including requests and the server can deal with the requests faster and therefore being done with serving faster, ready to handle another client. (My preferred realworld example is: Consider a shopping list, do you shop and pay for each item individual or are you packing everything in your cart and pay for all in one go? Congrats, you pipelined your shopping!)

For the record: The opera webbrowser has it enabled since ever, chromium
enabled it a bit more than 2 weeks ago in their dev-branch
(http://codereview.chromium.org/10170044). Both might try harder to work
around buggy servers through (before someone asks: yes if the server
would close the connection, apt would fallback to none-pipelining as the
spec recommends). Other browsers have it disabled for "the web is a
buggy hell"-reasons or concerns about Head-of-line blocking (handling
request A is slow - e.g. because it needs to be generated dynamically -
so that B - e.g. a static file - could be already sent & done, if we
wouldn't need to wait to finish A first…), which doesn't apply to
repositories through so isn't an argument here. The "solution" in most
clients is just to open a few more connections instead of working with
one efficiently (realworld analogy: Oh, a traffic jam! Lets split our
car into two cars to get two cars through the jam in the same amount of
time…). Googles SPDY and HTTP/2.0 (will) try to fix all these "the web
feels sooo slow!" with multiplexing and (drum-roll) pipelining…

So we are back at square one: the web is a buggy mess. Lets just hope that Google will force the web once again (after they fixed there own repository to work with their own browser [reductio ad absurdum]) to be more standard conform and disable it until then by default as i don't have the energy to defend it like previous contributors did (which is the only real conclusion to be taken from the previously mentioned threads) and will just enable it on all my machines.
(And now hands up, who imagined such an outcome after reading the previous four paragraphs? I just needed a reference to point people complaining about the new default to…)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/996151

Title:
  disable apt http pipelining in quantal

Status in “apt” package in Ubuntu:
  Confirmed
Status in “apt” package in Debian:
  New

Bug description:
  Per UDS session on Apt improvements, it has been proposed to remove
  apt http pipelining

  The reasons:
  1. HTTP Pipelining has issue with certain proxy implementation
  2. Some new object stores, like S3, or Google's APT repositories have problems with HTTP Pipelining

  Running a test shows that disabling apt-pipelining has no perceptable
  diffferenvce, and disabling apt pipeling actually performed slightly
  better with an average of 31.899s versuses 32.456s. I tested an "apt-
  get -y update" with and without apt HTTP pipelining turned on.

  For more information on apt-pipelining, here are 2 threads to read:
   http://old.nabble.com/APT-do-not-work-with-Squid-as-a-proxy-because-of-pipelining-default-td28579596.html
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565555

  
  Pipelining on (apt-get -y upgrade):
  33.92
  31.37
  31.64
  31.63
  33.29
  33.08
  32.92
  32.88
  31.73
  31.98
  32.01
  32.96
  31.51
  32.68
  33.25

  Pipelining off (apt-get -o Acquire::http::Pipeline-Depth="0" -y upgrade):
  31.66
  31.59
  31.24
  31.30
  31.29
  32.85
  32.75
  31.50
  31.18
  32.26
  31.43
  33.28
  31.67
  32.45
  32.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/996151/+subscriptions