When Should I Use Memcache Instead of Memcached

When should I use Memcache instead of Memcached?

Memcached client library was just recently released as stable. It is being used by digg ( was developed for digg by Andrei Zmievski, now no longer with digg) and implements much more of the memcached protocol than the older memcache client. The most important features that memcached has are:

1. Cas tokens. This made my life much easier and is an easy preventive system for stale data. Whenever you pull something from the cache, you can receive with it a cas token (a double number). You can than use that token to save your updated object. If no one else updated the value while your thread was running, the swap will succeed. Otherwise a newer cas token was created and you are forced to reload the data and save it again with the new token.
2. Read through callbacks are the best thing since sliced bread. It has simplified much of my code.
3. getDelayed() is a nice feature that can reduce the time your script has to wait for the results to come back from the server.
4. While the memcached server is supposed to be very stable, it is not the fastest. You can use binary protocol instead of ASCII with the newer client.
5. Whenever you save complex data into memcached the client used to always do serialization of the value (which is slow), but now with memcached client you have the option of using igbinary. So far I haven't had the chance to test how much of a performance gain this can be.

All of this points were enough for me to switch to the newest client, and can tell you that it works like a charm. There is that external dependency on the libmemcached library, but have managed to install it nonetheless on Ubuntu and Mac OSX, so no problems there so far.

If you decide to update to the newer library, I suggest you update to the latest server version as well as it has some nice features as well. You will need to install libevent for it to compile, but on Ubuntu it wasn't much trouble.

I haven't seen any frameworks pick up the new memcached client thus far (although I don't keep track of them), but I presume Zend will get on board shortly.

UPDATE

Zend Framework 2 has an adapter for Memcached which can be found here

Memcache Vs. Memcached

(PartlyStolen from ServerFault)

I think that both are functionally the same, but they simply have different authors, and the one is simply named more appropriately than the other.

---

Here is a quick backgrounder in naming conventions (for those unfamiliar), which explains the frustration by the question asker: For many *nix applications, the piece that does the backend work is called a "daemon" (think "service" in Windows-land), while the interface or client application is what you use to control or access the daemon. The daemon is most often named the same as the client, with the letter "d" appended to it. For example "imap" would be a client that connects to the "imapd" daemon.

This naming convention is clearly being adhered to by memcache when you read the introduction to the memcache module (notice the distinction between memcache and memcached in this excerpt):

Memcache module provides handy
procedural and object oriented
interface to memcached, highly
effective caching daemon, which was
especially designed to decrease
database load in dynamic web
applications.

The Memcache module also provides a
session handler (memcache).

More information about memcached can
be found at »
http://www.danga.com/memcached/.

The frustration here is caused by the author of the PHP extension which was badly named memcached, since it shares the same name as the actual daemon called memcached. Notice also that in the introduction to memcached (the php module), it makes mention of libmemcached, which is the shared library (or API) that is used by the module to access the memcached daemon:

memcached is a high-performance,
distributed memory object caching
system, generic in nature, but
intended for use in speeding up
dynamic web applications by
alleviating database load.

This extension uses libmemcached
library to provide API for
communicating with memcached servers.
It also provides a session handler
(memcached).

Information about libmemcached can be
found at »
http://tangent.org/552/libmemcached.html.

When not to use memcache

https://github.com/steveyen/community-site/blob/master/db_doc/main/WhyNotMemcached.wiki

Memcached is terrific! But not for every situation...

• You have objects larger than 1MB.
  
  
  • Memcached is not for large media and streaming huge blobs.
  • Consider other solutions like: http://www.danga.com/mogilefs
• You have keys larger than 250 chars.
  
  
  • If so, perhaps you're doing something wrong?
  • And, see this mailing list conversation on key size for suggestions.
• Your hosting provider won't let you run memcached.
  
  
  • If you're on a low-end virtual private server (a slice of a machine), virtualization tech like vmware or xen might not be a great place to run memcached. Memcached really wants to take over and control a hunk of memory -- if that memory gets swapped out by the OS or hypervisor, performance goes away. Using virtualization, though, just to ease deployment across dedicated boxes is fine.
• You're running in an insecure environment.
  
  
  • Remember, anyone can just telnet to any memcached server. If you're on a shared system, watch out!
• You want persistence. Or, a database.
  
  
  • If you really just wish that memcached had a SQL interface, then you probably need to rethink your understanding of caching and memcached.

How to use MemcacheD instead of Memcache on PHP and Windows Xampp?

You're confusing the two. memcached is the Memcache daemon program (the d stands for daemon). This has to be running for you to use Memcache. This is NOT what you use inside PHP. You launch this inside Windows like you would any other program.

The Memcache PECL library is how you can connect to your running daemon. You use new Memcache inside PHP to create an object that connects to the daemon and then interacts with it.

When to use memcached

I just don't know how/when to use it?

Use it only once you have proved that adding caching is the best performance boost you can get. Adding data caching or output caching to a complex application that previously did not have any sort of caching can uncover a large number of subtle bugs and bizarre behavior.

Use a code profiler first. Find out where your code is having real performance problems. Identify the bottlenecks and fix them. If that fix involves caching, so be it, but gather evidence first.

When to avoid memcache?

If you know when to bust the caches to prevent out-of-date things from being cached, there's not really a reason to avoid memcache for anything small unless it's so trivial to compute that it'd be approximately as long to hit memcache as it would to just compute it.

---

Related Topics