I want to use memcached

http://www.danga.com/memcached/

I have installed it through yum install memcached

But now I need to connect to PHP, and there is an extension named memcache and one named memcached? ARGH

http://us3.php.net/manual/en/book.memcache.php
http://us3.php.net/manual/en/book.memcached.php

Could someone point me in the right direction here.. which one is going to work?

Also, do I need to open any ports for it to work even though it's local? After running it, I try telnet 127.0.0.1 11211 and I get connection refused.

link|improve this question

33% accept rate
5  
If you're looking at this question now, please bear in mind that the accepted answer is wrong. Picking a solution based solely on the name is dangerous, particularly when the one with the better name is a worse project. Please look at the other answers for more information. – tylerl Oct 7 '10 at 23:34
feedback

12 Answers

up vote 15 down vote accepted

The short answer: Either one is what you are looking for, but my first choice would be memcache (the first one you listed), purely based on its correct use of nomenclature.

Now here's how I came to that conclusion:

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.

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

link|improve this answer
27  
Is the name of the project really an appropriate reason to pick one implementation over the other? – David Pashley Sep 8 '09 at 17:41
3  
David: Not quite... but it's certainly enough of a reason to leave a particular implementation until last in my testing, thereby effectively giving preference to the other(s). I would most likely still try out all implementations available, but technical flaws in descriptions of software by the author tend to make me wonder about what technical flaws may lie in the software. I did read your comment, though, about the actual software, so I gave you an upvote for your answer too. :-) – Jessica McKinnon Sep 8 '09 at 18:33
2  
I never thought the "d" in memcached to mean deamon but to mean the past participle of the verb cache. Plus, you couldn't name the new interface as "memcache" since there was already one with that name. – GetFree May 16 '10 at 23:24
4  
The amount of bugs and whether or not the extension is actively developed is so much more important than being anal about the problematic d. Seriously, you should not even think about testing one extension last because of something like that, it's completely off the bat – Fake51 Jun 26 '10 at 10:50
5  
Erm, both aren't functionally the same: memcached supports cas tokens for instance, memcache doesn't. If you need those, you know which (ill named or not) to pick. – Wrikken Sep 24 '10 at 11:53
show 3 more comments
feedback

You probably want to see the PHP Client Comparison.

Short version: They will both work, and for most cases either one will do just fine.

Regarding the other issue: Yes, you should be able to do telnet 127.0.0.1 11211. Very few firewalls would block localhost from communicating with itself. If you are not able to connect, verify that memcached really is running by doing ps auxwww | grep memcached, which will also show you the command-line arguments used to start memcached. One of the arguments should be -p 11211 or another port number. See man memcached for the meaning of all the possible arguments.

link|improve this answer
Upvote for adding some troubleshooting steps. – Jessica McKinnon Sep 8 '09 at 18:37
feedback

As Nate's link suggests, both work perfectly well for simple usage. However, memcached supports more features that allow you to get the most performance out of memcached. The binary protocol reduces the amount of data required to be sent between client and server. Multigets and multisets allow you to get/set multiple items at the same time. If you're finding you need more oomph out of memcache, memcached is the better module. The use of libmemcached suggests that the library itself is possibly more optimised than the PHP only version.

Memcached is a more recent module compared to memcache, having only been released 8 months ago. If you need to target an older version of PHP, then you can only really use memcache.

link|improve this answer
Great explanation! – john Oct 8 '11 at 1:58
feedback

Guys, here's the correct answer: http://about.digg.com/blog/new-pecl-extension-libmemcached-released

@Bill Getas: Easy on the arrogance. As it happens, Andrei is more than likely a little smarter than you are.

link|improve this answer
feedback

The older, buggier one is called php-memcache because that seemed the most appropriate name. The newer, better version independently developed by the folks at Digg was instead named php-memcached in the interest of disambiguation.

People who would recommend you pick one over the other based solely on the correctness of the name really have no business offering technical advice.

link|improve this answer
feedback

Both have issues as of today. PECL/memcache is old and reliable, with a few exceptions where it is out dated. PECL/memcached 1.x is beta at best. Some functions don't deal with numeric keys, it leaks connections when using persistent connections. Some (all?) is being fixed in GitHub and will be released at some point in 2.x, but not today. For a more detailed review see http://brian.moonspot.net/php-memcached-issues

link|improve this answer
feedback

Having used php-memcache recently, I'd have to point you to php-memcached.

Here's a couple of reasons off the top of my head..

1) There's no getErrorCode() or equivalent method, so if get() returns FALSE, you'll have no idea whether that's because the value stored in memcache IS false, or whether there was an issue of some sort.

2) Its hashing algorithm for consistent hashing appears to differ from other implementations, such as the many client libraries built off of libmemcached. This means that if you want to use the same memcache cluster with multiple languages, you will likely have issues where you'll store a value with the PHP client, and other clients won't find it.

link|improve this answer
feedback

I'm working on a book "Expert PHP and MySQL". I wrote pretty much the same thing about the differences. What I recommended was PECL/memcached. #1 - it wraps around a full-featured well-performing C library #2 - it is more recently maintained. #3 - more features. No disparagement to PECL/memcache.

link|improve this answer
feedback

Good grief. The person who named memcached, and the people who kept on accepting that name, should be slapped. Hard. And the thing should be renamed. memcache2, or memecache, or memcash, or even lamecache. In Microsoft land, new is embraced, sought after, rewarded, even while the rest of humanity is taxed trillions of man-years by constant suffering under fresh and wholly unnecessary failures. In Unix land, we, as a very strict rule, detest change and 'bucking tradition'. xyzd and 'daemon' are very strong, very old tradition. The server is even named memcached. Since when does any client, anywhere else share the identical name as the server? Sorry, but no matter how good memcached may be, it is named improperly and affrontively.

link|improve this answer
1  
Agreed, but an answer is not the right place for a rant. After all, it doesn't help to answer the question. – Martijn Heemels Apr 9 '11 at 21:41
feedback

whatever you say.. the extension was appallingly named (no pun intended).

link|improve this answer
feedback

[Change all the underscore chars "_" to the dot "." for the links]

  1. This question could be answered in two parts:

    1) What are MEMCACHE and MEMCACHED?
    2) What is the comparison between them?

  2. I found all the answers trying to answer the second question without addressing the first. After a bit of studying, I have the conclusion as:

    MEMCACHE and MEMCACHED refer to the same thing, or more specifically, refer to different parts on the same thing. MEMCACHE is the client of MEMCACHED (which is the server naturally), while LIBMEMCACHED is also a client to MEMCACHED. The two clients MEMCACHE and LIBMEMCACHED refer to the server named MEMCACHED from the same web site: www_memcached_org/, but might be or likely be on different versionings.

  3. So, what is the problem coming from?

3.1) I would think that because of the nature of open source, each software comes individually and lacks of a general naming at upper level. When use this software, you need the server and a client as a pack in your application. The PHP site did not specifically point out or put each component on suitable angle consistantly. See the followings for MEMECACHE and MEMCACHED intro pages from the php site:

  MEMCACHE -- www_php_net/manual/en/intro.memcache.php
  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 » www_memcached_org/. 


  MEMCACHED -- www_php_net/manual/en/intro.memcached.php
   » memcached (http://www_memcached_org/) 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 
   » tangent_org/552/libmemcached.html.

Several points:
1) You can see both refer to MEMCACHED -- www_memcached_org/
2) In first doc, mentioned MEMCACHE is an "interface to memcached";
The second doc mentions "uses libmemcached library to provide API", which means LIBMEMCACHED is a client to MEMCACHED.

3.2) The problem also comes from PECL site pages:

  memcached
  pecl_php_net/package/memcached<br />
  Package Information
  Summary  PHP extension for interfacing with memcached via libmemcached library
  Maintainers  Andrei Zmievski <andrei@php.net> (lead) [wishlist] [details]
  License  PHP
  Description  This extension uses libmemcached library to provide API for 
                  communicating with memcached servers.
  Homepage  github_com/andreiz/php-memcached


  memcache
  pecl_php_net/package/memcache
  Package Information
  Summary  memcached extension
  Maintainers  Antony Dovgal (lead) [wishlist] [details]
  Pierre-Alain Joye (lead) [wishlist] [details]
  Herman Radtke <hradtke@php.net> (lead) [details]
  Mikael Johansson (lead) [details]
  License  PHP License
  Description  Memcached is a caching daemon designed especially for
  dynamic web applications to decrease database load by
  storing objects in memory.
  This extension allows you to work with memcached through
  handy OO and procedural interfaces.

Note: Both call "memcached" as a server, but the first also call memcached as a package name. While you look at the second -- memcache as a client, you would think the first, titled "memcached" is also a client.

3.3) A good comparison page also messed up:

  code_google_com/p/memcached/wiki/PHPClientComparison
                        pecl/memcache      pecl/memcached
  First Release Date      2004-06-08         2009-01-29 (beta)
  Actively Developed?     Yes                    Yes
  External Dependency     None              libmemcached

But it looks like it mentions the MEMCACHE used MEMCACHED is an older version from the current MEMCACHED server

3.4) Also, not only MEMCACHE and LIBMEMCACHED, there are other clients for MEMCACHED

see code_google_com/p/memcached/wiki/Clients<br />

-4- may be call:

Memcached-Memcache, package referring server MEMCACHED and client MEMCACHE
Memcached-Libmemcached, package referring server MEMCACHED and client LIBMEMCACHED
Memcached-Apr_memcache, package referring server MEMCACHED and client APR_MEMCACHE
...
or,<br />
Memcached with Memcache, package referring server MEMCACHED and client MEMCACHE
Memcached with Libmemcached, package referring server MEMCACHED and client LIBMEMCACHED
Memcached with Apr_memcache, package referring server MEMCACHED and client APR_MEMCACHE
...

would be better<br />


link|improve this answer
2  
This long-winded answer doesn't even come close to making things clear for the poster. The poster is already aware there are multiple clients. Listing them, and proposing alternative names, doesn't make it easier to pick the right one. – Martijn Heemels Apr 9 '11 at 21:39
feedback

Let's not call two different things the same name, eh?

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.