| 2010-02-11 05:08:44 |
Martin Pool |
description |
This is actually debian bug 396227:
From: Roland Mas <lolando@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: bzr: Very network-unfriendly
Date: Mon, 30 Oct 2006 18:20:02 +0100
Package: bzr
Version: 0.11-1
Severity: normal
bzr seems to deliberately eat my bandwidth. The following two
invocations of bzr have been run in a row, after the $http_proxy and
$HTTP_PROXY environment variables have been set up to point to a
(working) squid proxy/cache. As you can see, there's no gain in using
a cache:
,----
| roland@mirexpress:/tmp$ time bzr branch http://bazaar-ng.org/bzr/bzr.dev
| Bzrtools is not up to date with installed bzr version 0.11.0.
| There should be a newer version available, e.g. 0.11.
| Branched 2100 revision(s).
|
| real 23m28.351s
| user 0m31.538s
| sys 0m1.880s
| roland@mirexpress:/tmp$ mv bzr.dev/ bzr.dev.bak
| roland@mirexpress:/tmp$ time bzr branch http://bazaar-ng.org/bzr/bzr.dev
| Bzrtools is not up to date with installed bzr version 0.11.0.
| There should be a newer version available, e.g. 0.11.
| Branched 2100 revision(s).
|
| real 23m58.854s
| user 0m32.130s
| sys 0m1.740s
| roland@mirexpress:/tmp$
`----
The Squid logs lots of TCP_MISS and TCP_CLIENT_REFRESH_MISS entries.
According to the Squid documentation, this means that "The client
issued a "no-cache" pragma, or some analogous cache control command
along with the request. Thus, the cache has to refetch the object."
Bzr is slow enough already, bypassing proxy-caches is not good. One
could, with lots of goodwill, argue the case for initial branching,
but re-fetching more than a megabyte afterwards for each bzr pull (one
in each branch) is stretching it. |
Transport.get (and readv, etc) should take a flag indicating the the requested file is cacheable. This should pass through to the http client, and it should be set when reading pack and index files.
----
This is actually debian bug 396227:
From: Roland Mas <lolando@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: bzr: Very network-unfriendly
Date: Mon, 30 Oct 2006 18:20:02 +0100
Package: bzr
Version: 0.11-1
Severity: normal
bzr seems to deliberately eat my bandwidth. The following two
invocations of bzr have been run in a row, after the $http_proxy and
$HTTP_PROXY environment variables have been set up to point to a
(working) squid proxy/cache. As you can see, there's no gain in using
a cache:
,----
| roland@mirexpress:/tmp$ time bzr branch http://bazaar-ng.org/bzr/bzr.dev
| Bzrtools is not up to date with installed bzr version 0.11.0.
| There should be a newer version available, e.g. 0.11.
| Branched 2100 revision(s).
|
| real 23m28.351s
| user 0m31.538s
| sys 0m1.880s
| roland@mirexpress:/tmp$ mv bzr.dev/ bzr.dev.bak
| roland@mirexpress:/tmp$ time bzr branch http://bazaar-ng.org/bzr/bzr.dev
| Bzrtools is not up to date with installed bzr version 0.11.0.
| There should be a newer version available, e.g. 0.11.
| Branched 2100 revision(s).
|
| real 23m58.854s
| user 0m32.130s
| sys 0m1.740s
| roland@mirexpress:/tmp$
`----
The Squid logs lots of TCP_MISS and TCP_CLIENT_REFRESH_MISS entries.
According to the Squid documentation, this means that "The client
issued a "no-cache" pragma, or some analogous cache control command
along with the request. Thus, the cache has to refetch the object."
Bzr is slow enough already, bypassing proxy-caches is not good. One
could, with lots of goodwill, argue the case for initial branching,
but re-fetching more than a megabyte afterwards for each bzr pull (one
in each branch) is stretching it.
|
|
