Re: storeGet() -> storeGetPublic() ?

On Mon, Jan 08, 2001, Duane Wessels wrote:

> I'm worried that you're heading down a one-way path.
>
> It seems to me your goal is to reduce the memory footprint,
> and in order to do that you want to change storeGet().

Nope. I'm not aiming to reduce the footprint. I'm aiming
to allow different types of filesystems to be implemented.

> Such a change is going to have an effect on performance.
> Not keeping some of the StoreEntry bits in memory means it
> will be slower to access them. You're trading space for time.

Only if your FS goes out to disk to get the object information.
For example, there isn't anything stopping someone from having
a "ufs" filesystem which keeps the index in memory, and just
populates StoreEntry's when they're needed?

The problem is that squid isn't flexible enough to support some
of the "alternate" object storage mechanisms. Why not try
them out?

> Some current Squid users may not appreciate being forced
> into that tradeoff. For them, its better to have
> a Squid that can serve 10,000 ICP queries per second
> (and pay the memory costs) than it is to be stingy with
> memory.

Yup, I totally agree. Once I've completed my coding we can see
what the results are. I'm hoping to be able to sustain at least
that 10,000 ICP requests per second. :)

Remember: I'm not forcing anyone to *just* use a disk based index.
I'm simply trying to make things more flexible.

Adrian

-- 
Adrian Chadd			"Sex Change: a simple job of inside
<adrian@creative.net.au>	  to outside plumbing."
				    - Some random movie