hate to say it, but I almost like this alternative. We already have the
option to disable evictions entirely. Mixing those into the cache means
they at least need to be promoted to the head when an eviction is called.
Mixing them into general caches might tend to cause more bugs as the
effective temporary cache size shrinks over time.
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? 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.
-Dormando
Josef Finsel wrote:
Dustin,
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.
The only way to really lock something into memcached is to set up a
separate server and load the important items into it and not use it for
the other caches.
Josef
"If you see a whole thing - it seems that it's always beautiful.
Planets, lives... But up close a world's all dirt and rocks. And day to
day, life's a hard job, you get tired, you lose the pattern."
Ursula K. Le Guin
On Wed, Jun 11, 2008 at 12:30 PM, Dustin Sallings <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
IMO, the idea does conflict a bit with the idea of a cache, at
least as I understand it.
Implementation-wise, it seems like another command to flag an
existing record as one that should specify LRU priority.
I can imagine if you have items you want to not be removed by LRU
that you perhaps also have items you consider cheaper than others
and would prefer these other items discarded before more expensive
items to recreate.
Likewise, it doesn't unreasonable to have items you want to expire
at a particular point in time, but not before it.
If you can imagine communicating a cost of invalidation to
memcached, you could see how careful use of such a thing could
potentially make for more efficient systems. For a finite list of
priorities, it could be inplemented quite easily and efficiently.
--
Dustin Sallings (mobile)
On Jun 11, 2008, at 5:48, "Reinis Rozitis" <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
RR the patch you pointed to sounds exactly what I'm looking
for. If you would not mind posting your latest version
patch please.
This is not my patch (all credits go to Paul G) but just a bit
tweaked to apply for current (1.2.5) release.
http://roze.lv/memcached-permitems.patch
As to answering few of Brads comments:
I think Paul wanted to show just some quick working concept of
the feature which in real world situations is pretty usefull
rather than push the patch directly into source. Ram is cheap,
but in some cases you still can't deploy enough to satisfy all
the web-coder needs so instead of cycling the cache all the time
give some logic and decision possibilities to (client) software
which data is more important.
It sure needs love to cope with the current code-style, but the
question is whether the current developers are fine with the
idea/option at all.
rr
