Zhenya Ciurana - Official Author Blog

Facebook just released their fork of memcached. memcached was first created to support LiveJournal's explosive growth and is often used in writing scalable web sites. Although enterprise Java applications tend to favor technologies such as Terracotta and Oracle Coherence, memcached is available for them along with every major programming language in use today. The official memcached repository, Google App Engine's Memcache, and now the Facebook memcached fork are different flavors or forks of the same technology.

memcached is installed in as many servers as possible in a cluster. The servers are transparently available to the clients over a network connection. Clients are responsible for establishing the connection by either talking to the memcached servers directly, or by instantiating a language-specific client that allows the application to add, query, remove, and modify key/value pairs. Applications use these values by querying the cache or by adding or refreshing the values in the course of their lifetime. The overall goal consists of eliminating unnecessary access to databases or other constrained resources.

The memcached client usage pattern is something like:

# Google App Engine memcache example:
from google.appengine.api import memcache
.
.
  datum = memcache.get(key)

  if datum is None:
    datum = dataRepository.runQueryBasedOn(key)
    if datum is not None:
      memcache.add(key, datum, DURATION)
  
  return datum
.
.

The client application may fetch data in bulk by providing multiple keys, or may delete or even flush the cache. memcached's popularity arose from its balance of ease-of-use and robustness.

Facebook is arguably the largest memcached user now, given their growth in the last 18 months and their reliance on caching to optimize their user experience. They forked the code to meet their own unique performance requirements because the original implementation was somewhat lacking. The Facebook code offers these differences against the main memcached branch:

• Thread-bound shared connection buffer pools for UDP and TCP sockets for more efficient memory utilization than the original, a-buffer-per-TCP-connection model.
• Fetch operations use dedicated UDP sockets for transmitting replies to support application-level flow control and to reduce network traffic.
• "Opportunistic" network I/O that combines interrupt- and polling-driven operations against the network interfaces to alleviate Linux kernel contention issues.
• Reduced network lock contention through the use of batched dequeues for data transmission to reduce or eliminate network contention issues in 8-core (or higher) systems.

Most of these optimizations are specific to Linux kernels running on multi-core processors, as Paul Saab described in the memcached fork announcement.

Chapter 7: Memcache and Session Data of Developing with Google App Engine describes how to use an elegant Memcache client implementation: simple and powerful.

Cheers!