Agree with Tim. The way Memcache evicts items is on an LRU - least recently used - basis.
Are you familiar with the concept of a "working set"? The idea is that the majority of your data reads for a given window will go to a small minority of your total dataset. This is why caching in general works so well. Faster caches have less storage, but are faster and cost more, but because you only ever work with a very small part of your entire dataset most of the time, it doesn't matter. With an LRU based cache, if something is retrieved, it is *usually* likely that object will be used again in the near future, and you gain the benefits of caching. It sounds like in your scenario, this is what will happen. If someone comes and requests some data that isn't frequently accessed, you win because you rarely pay that cost of hitting the datastore. If someone comes and requests data that is frequently accessed, again, you win because that data will, in an overwhelming majority of cases, be served from the cache. Where you lose is when your data access is totally random. So I guess my advice is this: build it first, use caching, graph everything and watch cache hits over time. When it's a problem, it's a problem and you can deal with it then, but my intuition tells me that it probably won't be for a while. -- Ikai Lan Developer Programs Engineer, Google App Engine plus.ikailan.com | twitter.com/ikai On Fri, Aug 5, 2011 at 5:31 PM, Tim Hoffman <[email protected]> wrote: > Basically you can't tell. > > Also you memcache capacity is finite so you by stuffing it with stuff in > case you need it, will inevitably evict something else. > > You basic design pattern needs to be > > Check in memcache > if not their fetch from the datastore > if you think the data will be re-used stick it in memcache > > Various scenarios may lend them selves to preloading the cache (but note > the point at the top) > If you can identity a users requirements specifically, when they log in > you could fire of a task in the background which could pre-load the cache > with stuff you think they will look at shortly, but > you still have to deal with cache misses. > > I dont think running your own mechanism in the backend would be > particularly useful unless you can guarantee a huge cache hit rate > as it is a finite resource. > > Also think about how you can fetch the data from the datastore more > efficiently. Getting data by key > can be very fast. Given the client will only fetch the data once, and you > don't know when they will do it > keeping the data hot in memcache seems an expensive excercise, especially > if you can optimize the > data in the datastore for the client so they can fetch it with a single > db.get() > > How are detecting the data change that triggers the notification? > > Just my 2c > > Rgds > > Tim > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-appengine/-/QQMA5FBKJWMJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
