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
