Re: modules

On Mon, 31 May 1999, Terence Kelly wrote:

> Define "significant". :)

At least 10% difference. Everything else tends, in general, to be wiped out
by real life variations and exceptions. This is my personal rule of thumb,
no more. AFAIK, many commercial vendors would kill each other (and
themselves) for 1% (to find out later that their competitor gained 20% by
optimizing the right thing). :-/

> If algorithm X consistently outperforms
> algorithm Y and isn't much harder to implement correctly and
> efficiently, why shouldn't we prefer X?

Because Y is implemented.

That's why modules are so great. We can tell people like yourself to get an
RA to implement your algorithm in a module instead of debating if we should
change Y to X in Squid...

> I don't yet have a good feel
> for the kinds of implementation issues & constraints that real cache
> developers face. Could you provide a list of good & bad qualities
> for removal policies, for the benefit of researchers?
>
> For instance, does it matter whether a replacement policy operates in
> O(N) or O(log N) time? Is it feasible for an LFU-like policy to
> store referene counts on URLs even after they are evicted?

Think in terms of real resources relative to current usage rather than
abstract and absolute terms. Extra memory used, CPU time wasted per
request, etc. I would not care if it is O(N*N) if it takes less than 0.1%
of current request processing time.
 
> The data I reported above is from the SD site, 1-28 March 1999.

Do not use UC and SD. They have weird local peers that screw all traces
and statistics.

> I know this isn't realistic, but until something like
> an MD5 hash of URL data is included in log entries, it won't be
> possible to establish with certainty whether the "foo.com" requested
> this time is the same one requested last time based on the logs.

Squid does not compute MD5 over HTTP entities (message bodies) and I doubt
it will in the nearest future. It is simply not needed for current Squid
operation.

Alex.
Received on Tue Jul 29 2003 - 13:15:58 MDT