Skip to content

Latest commit

 

History

History
231 lines (158 loc) · 6.69 KB

ReleaseNotes140rc1.wiki

File metadata and controls

231 lines (158 loc) · 6.69 KB

  1. summary Release Notes for Release 1.4.0-rc1

Table of Contents

Memcached 1.4.0 RC1 Release Notes

Date: Thu May 28 2009

Download

Download Link:

http://memcached.googlecode.com/files/memcached-1.4.0-rc1.tar.gz

New Features

Binary Protocol

A new feature that brings new features. We now have goodness like CAS-everywhere (e.g. delete), silent, but verifiable mutation commands, and many other wonders.

Note that the original protocol is *not* deprecated. It will be supported indefinitely, although some new features may only be available in the binary protocol.

Client Availability

Many clients for the binary protocol are available.

  • C
  libmemcached supports just about anything you can do with a memcached
  protocol and is the foundation for many clients in many different
  languages (which you can find linked from the project page).

  Project page: http://tangent.org/552/libmemcached.html

  • Java
  spymemcached has very good text and binary protocol support over IPv4
  and IPv6 with a quite comprehensive test suite.

  Project page: http://code.google.com/p/spymemcached/

  • Protocol Spec
  NIH problem?  Go write your own client.  :)

  http://cloud.github.com/downloads/memcached/memcached/protocol-binary.txt

Performance

Lots of effort has gone into increasing performance.

There is no longer a build-time distinction between a single-threaded and multi-threaded memcached. If you want a single-threaded memcached, ask for one thread (though there'll still be utility threads and other such things in the background). This change lets us focus on a future where multiple cores can be saturated for servicing requests.

Facebook-inspired contention reduction with per-thread stat collection and the Facebook connection dispatch and thread starvation prevention contributions helped our scalability.

Lock analysis also showed us that we had quite a bit of contention on hash table expansion which has been moved into its own thread, greatly improving the scalability on multicore hardware.

A variety of smaller things also shook out of performance testing and analysis.

There's also a memory optimization for users who don't actually make use of CAS. Running memcached with -C disables the use of CAS resulting in a savings of about eight bytes per item. If you have big caches, and don't use CAS, this can lead to a considerable savings.

Stats

There are several new stats and some new ways to look at older stats.

New Stats

  • stats settings
  Show all current server settings (useful for troubleshooting as well
  as internal verification).

  • Delete
  The global stats now contain statistics on deletion.

  delete_hits refers to the number of times a deletion command was
  issued which resulted in a modification of the cache while
  delete_misses refers to the number of times a deletion command was
  issued which had no effect due to a key mismatch.

  • Incr/Decr
  Incr and decr each have a pair of stats showing when a
  successful/unsuccessful incr occurred.  incr_hits, incr_misses,
  decr_hits, and decr_misses show where such mutations worked and where
  they failed to find an existing object to mutate.

  • CAS
  CAS stats are tracked in three different ways:

  * cas_hits

    Number of attempts to CAS in a new value that worked.

  * cas_misses

    Number of attempts to CAS in a value where the key was not found.

  * cas_badval

    Number of attempts to CAS in a value where the CAS failed due to the
    object changing between the gets and the update.

  • slab class evicted time
  Per slab class, you can now see how recently accessed the most recent
  evicted data was.  This is a useful gauge to determine eviction
  velocity on a slab so you can know whether evictions are healthy or if
  you've got a problem.

More Granular Stats

Where possible, stats are now tracked individually by slab class. The following stats are available on a per-slab-class basis (via "stats slabs"):

  * get_hits
  * cmd_set
  * delete_hits
  * incr_hits
  * decr_hits
  * cas_hits
  * cas_badval

(misses are obviously not available as they refer to a non-existent item)

Removed stats

"stats malloc" and "stats maps" have been removed.

If you depended on these commands for anything, please let us know so we may suggest alternatives for you.

Misc

- More tests - More/better documentation - Code cleanup

Bug Fixes

  * Build fixes on ubuntu (gcc and icc) and FreeBSD
  * bad interaction with cas + incr (bug 15)
  * setuid failures are reported properly at daemonization time
  * decr overflow causing unnecessary truncation to 0 (bug 21)
  * failure to bind on Linux with no network (i.e. laptop dev)
  * some memcached-tool cleanup
  * Alignment bug in binary stats (bug26)
  * Occasional buffer overflow in stats (bug27)
  * Try to recycle memory more aggressively. (bug14)
  * incr validation (bug31)
  * 64-bit incr/decr delta fixes (bug21)
  * ascii UDP set (bug36)
  * stats slabs' used chunks (bug29)
  * stats reset should reset item stats, eviction counters, etc... (bug22)
  * Fix all stat buffer management

Development Info

We've added a bunch of tests and new code coverage reports.

All included code in this release has been tested against the following platforms (using the in-tree test suite):

  * ubuntu 8.10 (64-bit, both gcc and icc)
  * ubuntu 8.04 (32-bit)
  * OS X 10.5 (ppc and intel)
  * OpenSolaris 5.11 x86 (with and without dtrace)
  * Solaris 10 sparc (with and without dtrace)
  * FreeBSD 7 x86

Feedback

Please try this version. Make it suffer. Report feedback to the list or file bugs as you find them.

  * Mailing List:  http://groups.google.com/group/memcached
  * Issue Tracker: http://code.google.com/p/memcached/issues/list
  * IRC:  #memcached on freenode

Contributors

The following people contributed to this release since 1.2.8.

Note that this is based on who contributed changes, not how they were done. In many cases, a code snippet on the mailing list or a bug report ended up as a commit with your name on it.

Note that this is just a summary of how many changes each person made which doesn't necessarily reflect how significant each change was. For details on what led up into a branch, either grab the git repo and look at the output of `git log 1.2.8..1.4.0-rc1` or use a web view.

  * Repo list: http://code.google.com/p/memcached/wiki/DevelopmentRepos
  * Web View:  http://github.com/memcached/memcached/commits/1.4.0-rc1