Re: [squid-users] Re: is there a squid "cache rank" value available for statistics?

From: Gavin McCullagh <gavin.mccullagh_at_gcd.ie>
Date: Thu, 23 Apr 2009 10:09:13 +0100

Hi,

On Mon, 20 Apr 2009, RW wrote:

> On Sun, 19 Apr 2009 19:03:36 +0100
> Gavin McCullagh <gavin.mccullagh_at_gcd.ie> wrote:
>
> > With a heap, things are more complex. I guess you could give an
> > indication of the depth in the heap but there would be so many
> > objects on the lowest levels, I don't suppose this would be a great
> > guide. Is there some better value available, such as the key used in
> > the heap maybe?

> You could probably do this with a modified version of heap LRU, using a
> counter rather than a timestamp as a key. You could then work-out the
> relative position in the queue, from the key value, the current counter
> value, and the key value at the top of the heap.

That's an interesting thought. So if you changed to a counter one could
use:
        <heapkey> - <minheapkey>

as an indicator of how far from the top of the heap you are. I presume
heap lru uses seconds since epoch or seconds since process start or some
such as the existing key? I guess even using the timestamp difference
or something like

           <heapkey> - <minheapkey>
        -----------------------------
         <maxheapkey> - <minheapkey>

might be a rough guide. Maxheapkey is probably just the current timestamp
on any reasonably busy squid install. The above is probably a bit
misleading though as the density of objects in time would vary pretty
wildly.

I'd like to find something that would work across all the removal methods
(currently we're using LFUDA). I'll try and make time to look at the code
and see what the keys are in each one.

On Mon, 20 Apr 2009, RW wrote:

> I should add that since heap key values don't persist over a restart,
> the heap would not initially be in LRU order, so you would have to wait
> for the normal LRU reference age before any statistics are meaningful
> -or start with an empty cache.

I see, thanks.

Gavin
Received on Thu Apr 23 2009 - 09:09:23 MDT

This archive was generated by hypermail 2.2.0 : Thu Apr 23 2009 - 12:00:01 MDT