Re: Bug#111879: apt-get: wishlist: random download order for better HTTP cache hit rate
On Mon, 10 Sep 2001, Zygo Blaxell wrote:
> and HTTP proxy cache logs for data to simulate an 'update'. In a
> nutshell, the solution you propose can be worse than using no cache
> at all. The solution I propose improves performance in some situations,
> regardless of the kind of cache used.
The question is not about raw performance but about a correctly behaving
cache. APT explicitly does not support parallel gets (and I don't really
care if it is one 1 machine or ten), and the arguments your present for
why it is so good hold for pretty much every other internet user.
Plain and simple fact is that your cache is broken. It should preserve
it's hit rate by responding before a fetch completes, and if it
desperately make sense, it should process all pending transactions in
parallel (APT actually issues 10 gets to the cache at once, the cache
could easially fetch them in parallel, it just can't respond out of order)
A better solution to your problem is a preditictive usage sensative
debian-specific cache. It could download off peak hours, at a
slower+kinder rate and have the new .debs prepared before the client
requests them.
Nobody has written such a cache (apt-proxy doesn't quite do it all), but I
think it would be incredibly handy for large orginizations such as yours.
Jason
Reply to: