Dustin: Is there not a step like, ``if it's not cached, we need to look it up?'' If not, then it seems like you want something more along the lines of dynamo/chubby/zookeeper for these items.

Dustin In this particular case to do that would completely negate the benefit of the cache because better than 99% would fail in the cache lookup AND the database lookup. In effect we would be using the cache as a virtual table and only refer to the database on startup. There is method in our "madness" uhahaha. The number of "rogue" actions requested that would be blocked may only represent 10% of our total action requests, but would reduce server load significantly.

I take the point of some folk who have suggested running a 2nd instance of memcached and I am thinking about that. The single downside is calculation of the memory requirement and getting it right so that we don't lose entries and don't waste memory.

I've not heard of dynamo etc and will look into them.


regards
Grant




On 12/06/2008, at 2:37 PM, Dustin Sallings wrote:


On Jun 11, 2008, at 18:02, Grant Maxwell wrote:

If the class is cached and the record exists then we allow the action to proceed.
        If the class is not cached then we just allow the action to proceed
if the class is cached but the record does not exist then the action is denied.

Is there not a step like, ``if it's not cached, we need to look it up?'' If not, then it seems like you want something more along the lines of dynamo/chubby/zookeeper for these items.

The proposals that make sense to me around LRU policies are more for QoS kinds of things. That is, you can rate something between ``this is a little cheaper than recomputing it, but whatever'' to ``for the love of [deity] do not uncache this before the expiration date.'' Even in the latter case, you must accept that the value *may* not be where you think it is and will need to be recomputed.

The only time I really see making a business decision based on what value is in the cache is if you're under a heavy load scenario and are really trying to walk on eggshells around your centralized resource. e.g. you might give an HTTP 503 kind of response, but definitely nothing in the 400s.

--
Dustin Sallings




Reply via email to