Need help understanding memcached stats
sgrimm at facebook.com
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