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.
- Nelz On Wed, Jun 11, 2008 at 9:59 PM, Grant Maxwell <[EMAIL PROTECTED]> 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. > > > 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 >> >> >> > >
