While I agree with most of your thesis, I can't see how GC is against the
LRU.
I agree, that often accessed keys with short TTL seem strange, and so do
rarely accessed keys with long TTL. But there are lots of perfect reasons to
have such situation, and we do.
GC does not work against the LRU (at
I tried.
Try the engine branch?
On Fri, 23 Jul 2010, Jakub Łopuszański wrote:
While I agree with most of your thesis, I can't see how GC is against the LRU.
I agree, that often accessed keys with short TTL seem strange, and so do
rarely accessed keys with long TTL. But there are lots of
On Fri, Jul 23, 2010 at 8:47 AM, dormando dorma...@rydia.net wrote:
I tried.
Try the engine branch?
I guess, I'll have to at some point.
Just wanted to say, that LRU was designed as an algorithm for a uniform cost
model, where all elements are almost equally important (have the same cost
of
That client library is old and hasn't been under active development for
years. Have you tried with a better client such as
http://code.google.com/p/beitmemcached/ or Enyim?
I have a vague memory of getting that error when the client didn't handle
some commands correctly.
/Henrik
On Fri, Jul
There are alternatives to LRU, which is generally chosen for being extremely
simple to implement, fast, and has a reasonable hit rate. The
Greedy-Dual-Size-Frequency policy may be more appropriate for memcached as it
accounts a value's weight. I doubt that there's a lot of value of changing the
On Jul 23, 11:31 am, Ben Manes ben_ma...@yahoo.com wrote:
There are alternatives to LRU, which is generally chosen for being extremely
simple to implement, fast, and has a reasonable hit rate. The
Greedy-Dual-Size-Frequency policy may be more appropriate for memcached as it
accounts a value's
