Basic command and advice for memcached

Storage Commands

set

Most common command. Store this data, possibly overwriting any existing data. New items are at the top of the LRU.

add

Store this data, only if it does not already exist. New items are at the top of the LRU. If an item already exists and an add fails, it promotes the item to the front of the LRU anyway.

replace

Store this data, but only if the data already exists. Almost never used, and exists for protocol completeness (set, add, replace, etc)

append

Add this data after the last byte in an existing item. This does not allow you to extend past the item limit. Useful for managing lists.

prepend

Same as append, but adding new data before existing data.

cas

Check And Set (or Compare And Swap). An operation that stores data, but only if no one else has updated the data since you read it last. Useful for resolving race conditions on updating cache data.

Retrieval Commands

get

Command for retrieving data. Takes one or more keys and returns all found items.

gets

An alternative get command for using with CAS. Returns a CAS identifier (a unique 64bit number) with the item. Return this value with the cas command. If the item's CAS value has changed since you gets'ed it, it will not be stored.

delete

Removes an item from the cache, if it exists.

incr/decr

Increment and Decrement. If an item stored is the string representation of a 64bit integer, you may run incr or decr commands to modify that number. You may only incr by positive values, or decr by positive values. They does not accept negative values.

If a value does not already exist, incr/decr will fail.

Statistics

There're a handful of commands that return counters and settings of the memcached server. These can be inspected via a large array of tools or simply by telnet or netcat. These are further explained in the protocol docs.

stats

ye 'ole basic stats command.

stats items

Returns some information, broken down by slab, about items stored in memcached.

stats slabs

Returns more information, broken down by slab, about items stored in memcached. More centered to performance of a slab rather than counts of particular items.

stats sizes

A special command that shows you how items would be distributed if slabs were broken into 32byte buckets instead of your current number of slabs. Useful for determining how efficient your slab sizing is.

WARNING this is a development command. As of 1.4 it is still the only command which will lock your memcached instance for some time. If you have many millions of stored items, it can become unresponsive for several minutes. Run this at your own risk. It is roadmapped to either make this feature optional or at least speed it up.

flush_all

Invalidate all existing cache items. Optionally takes a parameter, which means to invalidate all items after N seconds have passed.

This command does not pause the server, as it returns immediately. It does not free up or flush memory at all, it just causes all items to expire.

Expiration in memcached

Expiration in memcached is lazy. In general, an item cannot be known to be expired until something looks at it.

If you fetch an expired item, memcached will find the item, notice that it's expired, and free its memory. This gives you the common case of normal cache churn reusing its own memory.

Think of it this way: You can add billions of items to memcached that all expire at the exact same second, but no additional work is performed during that second by memcached itself. Only as you attempt to retrieve (or update) those items will memcached ever notice that they shouldn't be there. At this point, curr_items will be decremented by each item it has seen expired.

We may also notice expired items while searching for memory for new items, though this isn't likely to create an observable difference in curr_items because we'll be replacing it with a new item anyway.

Storing sets or lists

Storing lists of data into memcached can mean either storing a single item with a serialized array, or trying to manipulate a huge "collection" of data by adding, removing items without operating on the whole set. Both should be possible.

One thing to keep in mind is memcached's 1 megabyte limit on item size, so storing the whole collection (ids, data) into memcached might not be the best idea.

Steven Grimm explains a better approach on the mailing list: http://lists.danga.com/pipermail/memcached/2007-July/004578.html

Chris Hondl and Paul Stacey detail alternative approaches to the same ideal: http://lists.danga.com/pipermail/memcached/2007-July/004581.html

A combination of both would make for very scalable lists. IDs between a range are stored in separate keys, and data is strewn about using individual keys.

Reference

Click for more detail about memcached

• https://github.com/memcached/memcached/wiki/ProgrammingTricks

Recommend to Read

• https://github.com/memcached/memcached/wiki/UserInternals