Memcached - Memcached - Eli : Memcached

Release notes from official site :

Overview

Feature and bugfix release. New Touch commands, counters, and a change to connection limit functionality. Included is an important bugfix for binary protocol users. The binary get command was not activating the LRU algorithm. Fetching an item would not prevent it from getting expired early.

Fixes

• Fix to write correct pid from start-memcached
• Fix to enable LRU when using binary protocol
• Upgrade stats items counters to 64bit
• Add new stats expired_unfetched, evicted_unfetched
• Allow setting initial size of the hash table
• Expose stats for the internal hash table
• Issue 220 : incr would sometimes return the previous item's CAS
• Fixed bug on multi get processing
• Experimental maxconns_fast option
• Add an ASCII touch command
• Add binary GATK/GATKQ
• Backport binary TOUCH/GAT/GATQ commands
• Issue 221 : Increment treats leading spaces as 0
• Fix compile error on OS X

New Features

Touch Commands

Binary Touch/GAT commands were backported from 1.6. New GATK/GATKQ commands were added for completeness. Finally, an Ascii protocol touch command was also added.

Touch commands are used to update the expiration time of an existing item without fetching it. Say you have a counter set to expire in five minutes, but you may want to push back the expiration time by five more minutes, or change it to 15 minutes. With touch, you can do that.

The binary protocol also adds GAT commands (Get And Touch), which allow you to fetch an item and simultaneously update its expiration time.

Fast Connection Limit Handling

A new option, -o, has appeared! With -o new, experimental, or highly specific options are given full names. The first of which is maxconns_fast

$ memcached -o maxconns_fast

This option changes the way the maximum connection limit is handled. By default, when memcached runs out of file descriptors, it stops listening for new connections. When this happens, connections will sit in the listen backlog (defaulting to 1024, and adjustable with the -b option). Once some connections close off, memcached will starts accepting new connections again and they will be served.

This is undesireable as it can cause clients to delay or timeout for a long period of time. Long enough that it may be quicker to treat the items as a cache miss.

When a client connects and memcached is configured with maxconns_fast, it writes an error to the client and immediately closes the connection. This is similar to how MySQL operates, whereas the default is similar to Apache.

It is experimental as it is unknown how clients will handle this change. Please help test and report any issues to upstream client maintainers!

Internal Hash Table

STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0

Now it's possible to see how much memory the hash table itself uses. This can be useful for deciding on RAM limits for very large instances.

There is also a new option for setting the size of the hash table on startup:

$ memcached -o hashpower=20

If you run instances with many millions of items, and items are added very rapidly on a restart, it may be desireable to presize the hash table. Normally memcached will dynamically grow the hash table as needed, and this operation is generally very low overhead. If you put decals on your '96 Mazda grapefruit shootermobile, you may like this option.

Just examine the hash_power_level before restarting your instances, and adjust the startup command.

expired_unfetched, evicted_unfetched

The two stats represent items which expired and memory was reused, and valid items which were evicted, but never touched by get/incr/append/etc operations in the meantime. Useful for seeing how many wasted items are being set and then rolling out through the bottom of the LRU's.

If these counters are high, you may consider auditing what is being put into the cache.

You can download it from : http://memcached.googlecode.com/files/memcached-1.4.8.tar.gz

I post on this blog an interesting mail posted on Memcached Mailing List (http://groups.google.com/group/memcached) by Trond Norbye, check the original message here

We've done a lot of work since the latest 1.4.x release, but most of it has been invisible to most users. To catch up those who haven't been actively watching development, we're going to ease you into how it affects different segments of users, starting with general cache users.

We don't expect much to have changed from the perspective of the typical memcached user. The purpose of most of the work is to turn memcached into an extensible platform on top of which users can experiment with new storage mechanisms, extending with new commands, changing logging, adding instrumentation, etc...
This is mostly a reaction to mailing lists posts where someone wants to do something that someone else doesn't want done. We've gone out of our way to ensure that both can have what they want (and nobody has to fork).

The biggest change is that the code is no longer one blob, but instead a set of modules the user may enable based upon their preference. This enables others to create their own backing store, and still use the same command parser and core protocol handling as everyone else.

Another change users may like is that the logging mechanism is another module, so that you can get all of the output to syslog (or windows event log if you like). We now have official support for Microsoft Windows !
We're compiling the source on Microsoft Windows every day, so we find and fix bugs there at the same time as we do on the UNIX versions. The automatic testing isn't as good as what we've got on UNIX, but believe me: we're working on it!

Part of the point of going to modular components means that they are easier to test in a test program without having to "fork()" and test everything "over the wire". We have tests that cover specific internals that can run very quickly.

There are a number of new stats introduced in the next release. The key supplied in the status command is passed to the storage engine to allow the storage engine to add extra information to the existing stats commands, and to create their own stat commands.

Stats returned by the default stats command

libevent

Over the time we've seen a lot of bugs around people using an old version of libevent. That's part of the reason why we bundle a well known version of libevent in the release distribution. Memcached checks the libevent version during startup, and will refuse to start if the one used is too old. Since most operating systems use shared libraries these days, you might be using another version than the one you originally used when you first built memcached. In order for us to see which library people are using we decided to put it into the stats as well.

rejected_conns

The number of times a connection attempt was refused (due when we're hitting the maximum number of connections).

topkeys

You may get information about the most popular keys in memcached by exporting the environment variable MEMCACHED_TOP_KEYS to the number of keys you would want memcached to keep track of.
There is no such thing as a free lunch, so enabling this will have an impact on memory and speed. We've decided to _disable_ this by default for now, So you need to export this variable to enable the feature.

me@localhost:> MEMCACHED_TOP_KEYS=10 ./memcached

Running "stats topkeys" would return something like (I've added the line breaks and indentations to make it more readable in this document):

STAT my-key2 get_hits=0,get_misses=1,cmd_set=0,incr_hits=0,
     incr_misses=0,decr_hits=0,decr_misses=0,delete_hits=0,
     delete_misses=0,evictions=0,cas_hits=0,cas_badval=0,
     cas_misses=0,ctime=2,atime=2
STAT my-key1 get_hits=1,get_misses=0,cmd_set=1,incr_hits=0,
     incr_misses=0,decr_hits=0,decr_misses=0,delete_hits=0,
     delete_misses=0,evictions=0,cas_hits=0,cas_badval=0,
     cas_misses=0,ctime=12,atime=12

We hope to characterize the impact of this new stat before the final release and would like to include your feedback.

Stats returned by aggregate

The combination of the storage engine interface and the SASL auth allows for the combination of a connection-based stats. The aggregate subcommand is used to aggregate the stats from all of the connections on the server. The stats returned from the aggregate subcommand is the same as the normal stats command.

Stats returned by stats settings

extension

Displays one of the extensions loaded (may appear multiple times).

STAT logger syslog
STAT ascii_extension scrub
STAT ascii_extension noop
STAT ascii_extension echo

topkeys

The number of keys we are monitoring.

For part 2 of "What's new in Memcached", check this post, more informations about Virtual buckets, new commands and modularity in it.