On Wed, 1 Jul 1998, Dax Kelson wrote:
> It was a huge performance hit for us, too. But URL-as-key is just broken.
> It does not matter to an end user whether the reason they got the wrong page
> (what you call a "low probability false hit") is because of Squid's memory
> usage profile.
The end user does _not_ receive a wrong page in case of a false hit. It just
takes a bit longer to receive the page.
One of the fundamental differences between Cache Digests and earlier peer
selection algorithms is that Cache Digests are optimized for "general" case
(~90%) and add [small] overhead in exceptional conditions (~10%). ICP and
alike incur overhead for both general and exceptional cases.
Note that with all the headers in requests and replies, there are still
scenarios where HTCP will cause a false hit. Thus, a proxy has to accommodate
those anyway... A probability of a false hit is probably a bit lower with
HTCP, but average response time with Cache Digests is better.
Also, Cache Digests rely on a simple distribution model. A more complex,
self-configuring, know-everything model may be better, but looks somewhat
scary to me. :)
> I'd like to learn more about Cache Digests. Is there an Internet Draft?
There is a Squid FAQ entry and a 3rd Caching Workshop paper. Both are
outdated by now. :( There is also a proposal by Pei Cao called "Summary
Cache" which utilizes similar data structure (Bloom filter based), but uses
a different distribution/update methods.
Alex.
Received on Wed Jul 01 1998 - 12:56:59 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:41:02 MST