curr_items never decreases
Brian Moon
brianm at dealnews.com
Thu May 18 14:46:12 UTC 2006
> There shouldn't be a significant performance penalty for keeping this
> value properly up to date though...
Yes, there is. What has to happen to keep it up to date? memcached has
to go through its cache and count expired items. When does it do this?
The only time memcached looks at a piece of cache is when it is asked
to. Other than that, its just a chunk of memory. Adding a process to
cycle through the cache and do housekeeping would add an unwanted
performance hit.
I am always curious when people ask this question. I have seen similar
questions about the expired cache off and on since I joined this list.
I don't mean to come off like a smart ass, but what is it that makes you
feel you need to know the raw number of unexpired items in your cache?
our cache has 727,929 items spread across 8 servers. I only have that
stat on a stats page because it is available to me. Perhaps if I
understood more what is driving this quest for this knowledge, we can
all better help future people that will ask this question.
For me, the key is in our hit/miss and cache free numbers:
Hits: 641,417,353
Misses: 9,052,475
Cache Free: 198.82M
We have free cache, so that means that we are not rolling stuff off
before its expiring. Our hit/miss ratio tells me that we are not
creating lots of unique keys that will never get hit again. So, IMO,
our cache is healthy. Those servers have been running since 4/25
without a flush. We only had to flush them then because we made a
change to something and wanted the cache out sooner than the expire time.
(Heh, 71:1 hit/miss ratio. What did I say before? 900? sorry. that is
what happens when you pull numbers off the top of your head.)
--
Brian Moon
-------------
http://dealnews.com/
Its good to be cheap =)
More information about the memcached
mailing list