Re: I-D Action: draft-nottingham-linked-cache-inv-00.txt

I am sure this will have pretty bad performance and I am not
convinced it will actually work as expected.

Whenever an object with "inv-by" is received, the cache is forced
to do a lookup of the target of that "inv-by" in order to establish
the necessary linkage (= a storage cost) to effect the dependent

This lookup+linkage must be done for each and every object with an
"inv-by" property, no matter how frequent or infrequent invalidations

(The only other way to implement this is to do a brute force scan
of the cache on each invalidation.)

Turning the linkage around, by setting "invalidates" on the nexus
object, is not as horrible, because it allows lazy evaluation without
storage overhead, which again means that the cost will only be borne
on actual invalidations.

In either case, a massively parallel multi-user cache, either has
to suffer a debilitating amount of locking for each invalidation,
or take a very relaxed view of the temporal relationship between
the objects associated by the Link: header.

The next thing that strikes me, is that all implementations will
have to contain some kind of loop-avoidance to avoid some really
stupid behaviour (A invalidates B, B invalidates C, C invalidates A)

I do not have a ready proposal for a better way of doing this,  that
does not involve either a mandatory "lazy ban" facility (like we
have in Varnish), or a mandatory secondary index in the cache.

This makes me suspect that this is an attempt to solve the wrong
problem the right place or the right problem the wrong place.

After all that negativity, let me point out constructively that
prototyping the "inv-by" and "invalidates" properties in Varnish,
can be used to make a sanity check (in the sense of "running code")
to see if this concept would actually work in practice.


Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Tuesday, 31 May 2011 17:53:56 UTC