item expiration

[Dustin Sallings]

On Jun 11, 2008, at 13:24, Josef Finsel wrote:

> I agree that this seems to conflict with the idea of how memcache is  
> generally used. But the suggestion your making still wouldn't  
> guarantee that the item would stay in cache since it could be that  
> there are no other lower priority LRU items to be dumped.


	I meant to imply that you could have a priority that means what the  
original request was -- to not have it be eligible for LRU eviction.

On Jun 11, 2008, at 13:30, dormando wrote:

> Thinking it through, I'm not actually entirely sure how priority  
> without a guarantee on evictions would be of much use. if an item is  
> that important, but not accessed very often, is it really that  
> important?

	Well, this was my initial thought, but frequency of access is  
relative.  The LRU can evict something that's accessed a couple times  
a second if you're flooding the thing with sets (which would otherwise  
be considered more eligible for LRU eviction).

> If the number of values are small, that smells more like a database  
> summary table entry with its own cache than a server modification.  
> That would be tolerant to any sort of cache failure (ie; upgrades).  
> Building in minor guarantees is asking for pain.

	I don't know that I could say that very broadly.  I know I've got  
items I'd rather have expire before others in an LRU.

	I do agree that overuse would mean people would start getting OOM  
errors again and would likely cause confusion.  More stats would need  
to accompany such a thing and you'd never really prevent someone from  
doing something dumb.

	Mixing instances with -M seems like it'd create a lot of overhead.  I  
think having something that's almost, but not entirely -M would be  
better.  Imagine adding a value to -M that allows you to specify how  
many items (per slab or whatever) could be escalated to a ``never LRU  
evict'' priority.

-- 
Dustin Sallings