item expiration

Grant Maxwell grant.maxwell at
Thu Jun 12 01:02:57 UTC 2008


I agree that in most cases the LRU is good enough. I thought I would  
input our scenario to help put the context where LRU does not suit.  
Chances are that lots of people do this and that Im not saying  
anything new but......


We have a high volume distributed application. Not as big as the bloke  
with ten 30 gig instances, but for us its big and getting bigger.  The  
application uses postgresql as a backend database and is designed as a  
"plugNprocess" environment. If the load gets too high we startup  
another blade, it connects and immediately starts sharing the load.

One of the challenges we face is the replication of data across  
multiple sites and database throughput. This is where memcached comes  
in. So far we have implemented memcached for all records which already  
naturally expire and so the LRU is a perfect fit and we get tremendous  
performance/overhead/throughput boost with cache hit rates being 40%+.

The next stage, where LRU does not fit, is the caching of an almost  
static dataset. We would do two lookups. One to see if the class of  
record is cached and then another to see if the record itself exists  
in cache.

	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.

So we need to know that if we add the class and it's records, they  
have to stay. Otherwise we could block actions because a record was  
not there - for whatever reason. The other event could be that the  
"class" record is lost and therefore the action will not be validated.  
This later scenario does not really matter so much as this validation  
is part of a bigger process, but the case where the class record  
exists but the data record does not, on its own is enough to refuse  
the action - and that is bad.

Now this particular set of records is used for every transaction, but  
some of the individual records may not be accessed for hours or days.

A "dont touch this" flag addition to the LRU would allow us to know  
that if we put a record there it will still be there.

I agree that this behavior may not be consistent with how memcached  
was designed, but I think it is consistent with the underlying  
philosophy of caching data to provide scalability. In our scenario the  
impact would be significant. We could probably grow our transactions  
by triple or more with NO additional database hits. Now THATS  
scalability :)


On 12/06/2008, at 9:32 AM, Reinis Rozitis wrote:

>> In most of the cases, LRU should be good enough. If the 'important'  
>> items are used very often, they will be naturally kept in cache.  
>> Locking some rarely-used items in cache, I cannot see the  
>> justification for the cost of discarding other often-used items and  
>> constantly re-creating them as they are referenced frequently.
> Yes and no. Looking at some real world cases (our) we have  
> experienced that objects without specified ttl (which kinda qualify  
> as permanent items) get evicted more/quicker rather than those with  
> expiration set (as they prolly fall in to the same slabs). At some  
> time we get to the point where a newly created item is pushed out  
> few moments after it is added. Well you can say it shows that  
> memcache needs more ram, but we are allready running on ten 30 gig  
> instances with zilion of items :)
> Running seperate servers with different settings is an option but  
> imho throws out the window whole idea about transparent horizontal  
> scaling/growing of memcached servers..
> Anyway my point here was just to give some hints to the initial  
> questions..
> As there have been answers to different proposals like full cache  
> dumps, replications, bdb backends and so on  (I have always liked  
> the responses to be superfast rather than feature-rich bloat) but  
> noone really has answered to Pauls mail it was an opurtunity to  
> throw it in again :)
> rr

More information about the memcached mailing list