Expiration Behavior

Gavin M. Roy gmr at myyearbook.com
Mon May 7 18:40:56 UTC 2007


That covers it, my point was I was watching the cache grow when I was
expecting it to stay relatively flat, due to expiration.  The lazy
expiration covers it!

Thanks,

Gavin

On 5/7/07, Jehiah Czebotar <jehiah at gmail.com> wrote:
>
> On 5/7/07, Gavin M. Roy <gmr at myyearbook.com> wrote:
> > Hello,
> >
> > Am running memcached in production on a fairly large site and am
> noticing
> > that while I'm putting in expirations, the size of the utilization is
> > growing disproportionately with the expected growth of the cache based
> upon
> > what we implemented it for.  By some testing, it seems that items that
> are
> > expired from the cache are only removed when the get request is
> sent.  Is
> > our interpretation of this behavior correct, or does content in the
> cache
> > expire based upon the timestamp through some internal stack?  If it's
> the
> > later how often does the daemon run through to get rid of expired
> content?
> >
> > TIA,
> >
> > Gavin
> >
>
> I'm not sure what you mean when you say utilization is growing
> disproportionately... but i can answer the second half of the question
>
> memcached uses a lazy expiration, which means it uses no extra cpu
> expiring items. When an item is requested (a get request) it checks
> the expiration time to see if the item is still valid before returning
> it to the client.
>
> similarly when adding a new item to the cache, if the cache is full,
> it will look at for expired items to replace before replacing the
> least used items in the cache.
>
> --
> Jehiah
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20070507/ec83651d/attachment.htm


More information about the memcached mailing list