A realization about cache entry lifetime and validation

May 6, 2011

In the process of some recent thinking about caches, I had one of those obvious realizations about the relationship between cache entry lifetimes and how correct you need to be with cache (in)validation.

Under many circumstances, there is an inverse relationship: the shorter your entries are potentially valid for, the looser and less guaranteed correct you can be with validating or invalidating them. Conversely, the longer the entries live the more careful you need to be with validation; the ultimate version of this is that entries never time out on their own so you need to be absolutely correct.

(And the ultimate version of short lifetimes is to have a very short lifetime and no (in)validation at all, where entries only vanish when they time out. This works very well in some situations.)

What this is about, of course, is how fast cached mistakes will get 'fixed' by the entry disappearing anyways. When they will disappear fast anyways, you can afford more mistakes than when they will disappear only slowly or not at all. Mistakes may be accidents or they may be things that are deliberately incomplete because being complete is too hard, too complex, or too time-consuming.

This relationship is not completely linear; at a certain point you hit an entry lifetime that is more or less functionally equivalent to 'forever'. Where this point is depends on your specific application and circumstances, including how picky your users are.

Written on 06 May 2011.
« Thinking about when not disabling iSCSI's InitialR2T matters
Email has two faces today »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri May 6 01:56:57 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.