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.
I use Ubuntu, and Debian mostly, so this answer is based on those, but I suspect the answer for other distros is largely the same.
In /etc/memcached.conf -- If it's not in exactly the same place, a) I'd be surprised, and b) you could find it with locate
# Start with a cap of 64 megs of memory. It's reasonable, and the daemon default
# Note that the daemon will grow to this size, but does not start out holding this much
# memory
-m 64
So all you need do, is change the -m 64 line to
-m 4096
Or similarly large value in Megabytes.
There's some other yummy tuning parameters in there, such as the user it runs as, and what to do when it runs out of memory, and the IP address to bind the daemon to.. Have a look for yourself.
Best Answer
Even if you have set the keys to not expire in Memcached, records will be deleted according to least-recently-used if Memcached fills up. The standard slab-based storage mechanism stores records in fixed size chunks that are allocated from slabs of 1Mb size. Although this is fast, it also means that Memcached can end up wasting quite a lot of memory. Once a slab has been allocated to hold chunks of a particular size I do not think the chunks can be resized. If a mix of large and small objects are cached, and the composition changes over time, it is possible that memcached will end up storeing small objects in much larger chunks if these are the only ones available.
This is one of the issues that companies like e.g. gear6 (www.gear6.com) and northscale (www.northscale.com) have addressed in their Memcached distributions.