Actually,
on looking at it there's little point (today). The mean object size is
already calculated and available to the user, and AFAICT we only initialize
the hash_buckets once (storeInit is called from mainInitialize).
so while we are keep the in memory state accurate, calculating the mean and
putting it somewhere won't do much :-]
If however, we do any reallocation based on the average object size during
run-time, then knowing the average of each store dir might be useful... and
for that I'd put the number of active objects in the *swapdir into the
_SwapDir struct - after that we could trivially calculate the per dir
average at need.
* or should I just use the number of filemap bits in use? (as that should =
the number of stored objects)
I still don't know the store stuff well.... so do we do any runtime
[re]allocations that are based on average object size?
Or should I just (put the object counter in, and some stats to show the per
store count & averages) do it anyway?
Rob
----- Original Message -----
From: "Adrian Chadd" <adrian@creative.net.au>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <squid-dev@squid-cache.org>
Sent: Monday, November 27, 2000 8:10 PM
Subject: Re: idea
> On Mon, Nov 27, 2000, Robert Collins wrote:
> > Any comments on this idea?
> >
> > -> have the storebackgroundcheck I've got going adjust the in memory
> > "store_avg_object_size" for each store_directory after it finishes a
check.
> > It could set it to the actual average rather than an estimate.
> >
> > I'm happy to code this up (and put it in the store_check branch?) but I
> > thought I'd get feedback first...
>
> Hrm, I like it. :-)
>
>
>
> Adrian
>
> --
> Adrian Chadd "God: Damn! I left pot everywhere!
> <adrian@creative.net.au> Now I'll have to create Republicans!"
> - Bill Hicks
>
Received on Mon Nov 27 2000 - 03:52:13 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:00 MST