Need help understanding memcached stats

Steven Grimm sgrimm at
Tue Feb 13 05:52:56 UTC 2007

Scott Newman wrote:
> 1. It seems like a miss should result in a write, and indeed the
> numbers are very close. When would a miss not result in a write?

That is impossible for anyone but you to answer for certain; it depends 
completely on your application, since your application controls the 
circumstances under which "set" commands get sent. If your application 
uses a "look up in the cache, and if it's not there, look up in the 
database and store in the cache" model, then one possibility is that 
your application is attempting to look up objects that aren't in your 
database (so there's nothing to set.) But maybe you store a "not in the 
db" indicator in the cache in that case, in which case that explanation 
doesn't apply. You'll have to look at your code for that; memcached 
itself doesn't force the application to store anything.

> 2. What do current connections/total connections represent? (how is a
> connection defined - is it anything like a web server session?)

Current connections is the number of clients currently connected to the 
server. Often that will correspond to web server processes, but that 
also depends on your application (you might, for example, be using a 
connection pooling mechanism.) Total connections is the total number of 
connections that have been accepted since the server started; it goes up 
by one each time a new connection comes in, but doesn't go down when a 
connection is closed.

> 3. Similarly, what do current items/total items represent? I'm
> guessing that current items are items in cache that are not expired?
> Are total items minus current items the number of items in cache that
> are expired?

It's just like the connection counts: current items is the number of 
items currently in the cache, total items is the number of items that 
have ever been placed into the cache over the lifetime of the server. 
This will often be equal to the total number of set commands received 
(cmd_set statistic), but not always; if you're using some of the 
conditional variants on "set" (add, replace) they can fail if their 
conditions aren't met, in which case total_items won't go up but cmd_set 

memcached does lazy expiration, so there is actually no fast way for it 
to tell you exactly how many items have expired. It will expire an item 
(where "expire" means time-based expiration, not LRU ejection) when a 
client tries to fetch the item. From the client's point of view it makes 
no difference but internally it means memcached doesn't have to waste 
CPU cycles expiring items that no client ends up asking for anyway.


More information about the memcached mailing list