Issue #45 new

Update Expiration time on get

sontek
created an issue

We would like our expiration time to re-update on get(), so that actively used items don't fall out of cache or get evicted. I think this would need to update the expiration in both metadata do something like .touch() in memcached.

Probably not the most efficient thing since its going to have to do get->set, so maybe have it as a setting that can be passed?

Comments (4)

  1. Mike Bayer repo owner

    OK let's walk through what's happening here:

    1. when a get() is called, the expiration time is bumped.

    2. the way dogpile.cache's expiration works is that we check expiration time on get().

    3. therefore, if you are looking to bump expiration on get, the entire expiration time feature of dogpile, as well as the whole "dogpile lock" idea, is not used at all. Basically set expiration time to zero (no expiration), same thing.

    4. What you're really looking for is a LRU cache. In this system, cache values are always bumped with the last access timestamp, and some mechanism is used to clear out values with old timestamps. this mechanism has to be either an asynchronous process in the background, or a "clean out other records on get" kind of thing, which will slow down your gets to some degree.

    5. I checked out "memcache LRU" and memcached's API is exactly LRU already: http://code.google.com/p/memcached/wiki/NewOverview#Forgetting_Data_is_a_Feature - "Memcached is, by default, a Least Recently Used cache." though I'd want to read more to get more specifics on that.

    6. so at least as far as memcached, if you just use memcached as is, set the expiration time to zero on the dogpile side, you're done. the cache will grow as big as it can and use LRU to evict old items.

    7. this is not to say that an LRU cache algorithm wouldn't be nice to have on the Python side as well, as an alternative to Memcached's system or for use with other backends, but my hunch is that maybe this is more like dogpile.cache has a pluggable system. A backend proxy that subclasses ProxyBackend to add this additional metadata to the payload and handle setting the last get time, and some system to clean out old items would be how to do it. But not sure if you need this right now for LRU behavior with memcached.

    8. or

  2. sontek reporter

    1-4. What we were really looking for is dogpile + LRU. So if it gets and it is expired, then it should return the stale and re-run the generator. BUT if it isn't expired, it should just update the expiration time and metadata so that it can continue to live for a little bit longer.

  3. Mike Bayer repo owner

    I think ProxyBackend subclass is how you should start with this, get something that works for you then we can consider if it's of general use.

  4. jvanasco

    if you end up getting this to work, please share the code. This could be of use to me.

    If this were implemented though, I think you'd also have to support it to track two times -- the origin and a current expiry ( or a current expiry + a max expiry ). Otherwise, if something hits your service every minute , an item would never go stale.

    Your settings would also need 3 values too:

    cache_expiry = 600
    cache_expiry_bump = 300
    cache_expiry_max = 1500
    
  5. Log in to comment