Re: Size of cache-digests ...

On Sun, 11 Oct 1998, Henny Bekker wrote:

> Yep.. The cache digest of the sibling-hosts need to be in RAM because of
> performance reasons.. I was uncertain for the local cache digest but it's
> obvious they should be locked into RAM also..
> So the RAM utillisation will become dependend on the number of sibling hosts
> which have cache digest enbabled and their cache sizes...

True. When the number of peers grows,
        [ICP] - memory is constant, but
          peer selection response time increases (probably exponentially)
        [CD] - memory grows (linearly), but
          peer selection response time is constant (~zero)

> The size of our local cache digest is 969500 bytes.. When all our 8 sibling
> hosts does have cache digest enabled and their caches approximately are the
> same size, we'll need another 8-Mbyte of RAM...
>
> [Not much, but we'll have to know it when determining the size of the Cache
> in relation with the size of the available RAM..]

Exactly. In most cases paying 1MB of RAM per peer is much better than waiting
for ICP_MISS replies from your peers.

> Out of the CacheManagers interface:
> Local Digest:
> store digest: size: 969500 bytes
> entries: count: 640256 capacity: 1551200 util: 41%
> deletion attempts: 0
> bits: per entry: 5 on: 2180427 capacity: 7756000 util: 28%
> bit-seq: count: 3133854 avg.len: 2.47
> added: 640256 rejected: 988421 ( 60.69 %) del-ed: 0
> collisions: on add: 0.15 % on rej: 0.14 %

Note that if your caches are already filled, you may be able to reduce the
digest size by factor close to two. Your stats show only 28% bit-utilization
while ideal utilization is 50%. You can decrease hard-coded bits_per_entry
parameter or, better, fiddle with the size calculation algorithm in Squid;
see storeDigestCalcCap().
 
Interestingly, more than half (60%) of your entries were not digested
(rejected: count). Either you have a lot of soon-to-be stale entries or
refreshWhen() function is seriously out-of-sync with refreshCheck() (the
latter is our fault).

Alex.
Received on Mon Oct 12 1998 - 08:07:14 MDT