RE: Squid memory footprint (was: MemPools rewrite)

WRT [1]:
Besides, if we get an ICP query and we hit, there is a reasonable
chance that we will get shortly a full-fledged query for that same
object. So keeping an in-core cache of the most recently
ICP-queried objects will save us a fair percentage of the overhead.

-----Original Message-----
From: Henrik Nordstrom
To: Andres Kroonmaa
Cc: squid-dev@squid-cache.org
Sent: 11/3/00 11:00 PM
Subject: Re: Squid memory footprint (was: MemPools rewrite)

Andres Kroonmaa wrote:

> I expect FS meta hitrate be low - it is increasingly easy to build
boxes
> that have disk/ram ratio of 200 and more (200G disk, 1G ram).
> There's been lots of talk about reqiserfs, which by all means sounds
good,
> but I've not seen any mention of it being supported on any other OS
but
> Linux or BSD. Even if we can implement it within squid, I see several
> cases that makes me worry about dependance on disk access for lookups.

Agree on most aspects, except the first.

Yes, a general purpose FS with general purpose tuning will have a way to
low hit rate, and this is partly experienced in the reiserfs-raw
approach (all-misses being a worse load to handle than all-hits), but
still I think they have proven the concept.

> ICP - shouldn't ever touch disks to return hit/miss. 2 boxes with
equal
> load and average hitrate of 30% would see 3 times more ICP traffic
than
> actual fetches from peers. We'd rather not allow this to touch disks.

Well, usually I do not consider ICP as an useable option, and thake the
freedom not to consider it's requirements when thinking about store
implementation. It should be possible to implement ICP with reasonable
performance if the normal cache operations can be implemented with good
performance.

[1]
Received on Sun Nov 05 2000 - 03:55:44 MST