nelz9999 at gmail.com
Thu Jun 12 05:34:57 UTC 2008
What you're talking about here sounds a heck of a lot like one of the
use cases I've heard about GigaSpaces/OpenSpaces... (Where everything
gets slurped into JVM space on startup, and the DB is only used as a
starting point and backup location...) You might wanna look into that.
On Wed, Jun 11, 2008 at 9:59 PM, Grant Maxwell
<grant.maxwell at maxan.com.au> wrote:
> 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.
> 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
>>> 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
>> Dustin Sallings
More information about the memcached