apt-get update through apt-cacher is unreasonably slow

[Ken Sharp]

Binary package hint: apt-cacher

apt-get update takes a few seconds when the index files are downloaded directly, but through apt-cacher it takes minutes, and is an unreasonable amount of time to wait when updating several machines. CPU usage is fine with apt-cacher rarely using more than 1%.

Through apt-cacher:

real 5m18.952s
user 0m0.320s
sys 0m0.440s

Without apt-cacher:

real 0m12.762s
user 0m0.180s
sys 0m0.140s

Downloading packages is fine (apt-get install foo bar) - it does so at full speed, but it seems to struggle massively with updates.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: apt-cacher 1.6.10ubuntu2
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Wed Jul 7 14:03:27 2010
PackageArchitecture: all
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: apt-cacher

[Ken Sharp (kennybobs)]

OK, not strictly true. apt-get install is slow waiting for headers, downloading is fine but waiting for headers takes far too long.

I've added a tcpdump during an apt-get update. I don't know if it's any use, I can't see anything in there. Possibly needs to be more verbose.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Peter Maloney (peter-maloney)]

I confirm that it is very fast downloading files (less than a second each), but when a file does not exist on the remote server, it takes at least one second per file. This results in about 1-2 minutes wasted. Certainly that is not huge in absolute terms, but in relative terms that is 96% overhead. That is horribly unnecessary and sloppy.

One problem appears to be a performance problem in the fetcher. The fetcher is very slow at figuring out that the file doesn't exist (which means the local [nonexistent] copy is up to date).

The second problem is that there is no caching of the fact that the file does not exist. The check before fetching, to determine if a local copy matches the remote one, is fast (unless the documentation about expire_hours=0 is wrong and it is not actually comparing the fresh header). So one solution could be to not delete the /var/cache/apt-cacher/packages/de.archive.ubuntu.com_ubuntu_dists_natty_InRelease file when there is a 404 error, and instead just cache the http header of the 404 error, and on next run, check to see if it is "updated" using the fresh HTTP headers (not trying to fetch again).

#################################################
# Without apt-cacher
#################################################

# time apt-get update
Ign http://extras.ubuntu.com natty InRelease
Ign http://security.ubuntu.com natty-security InRelease
Ign http://archive.canonical.com natty InRelease
Ign http://us.archive.ubuntu.com natty InRelease
Ign http://us.archive.ubuntu.com natty-updates InRelease
Hit http://extras.ubuntu.com natty Release.gpg
Hit http://security.ubuntu.com natty-security Release.gpg
Hit http://archive.canonical.com natty Release.gpg
Hit http://us.archive.ubuntu.com natty Release.gpg
Hit http://extras.ubuntu.com natty Release
Hit http://us.archive.ubuntu.com natty-updates Release.gpg
Hit http://security.ubuntu.com natty-security Release
Hit http://archive.canonical.com natty Release
Hit http://us.archive.ubuntu.com natty Release
Hit http://us.archive.ubuntu.com natty-updates Release
Hit http://extras.ubuntu.com natty/main Sources ...