Memcached newbie questions

John j at
Mon Dec 31 04:22:56 UTC 2007


To use memcached as your session handler in PHP, you can specify the 
following directives in your php.ini:

session.save_handler = memcache
session.save_path = "http://localhost:11211"

To test if your current version of php/pecl-memcached supports session 
do a var_dump(MEMCACHE_HAVE_SESSION), if 1 then you are good to go, 
otherwise you need to upgrade php/pecl-memcached.

For caching SQL queries, I would recommend you simply create cookies 
between relational queries and keep track of the DML's that affect a 
particular cache.


Brian Moon wrote:
>> - Does php's memcached client API supports (consistent?) key hashing?
> I believe verion 3(alpha) does.
>> - Is memcache's php session handler a good way to store information
>> about a user? Or would it be better to manually store user info to
>> memcache? I'm trying to figure out if memcache's session handler saves
>> variables as one big chunk (so it cannot overpass the 1MB limitation)
>> or as different chunks (that transparently integrates them into the
>> php $_SESSION array).
> If your session data is not volitale and can be lost at any moment, 
> then it is ok to store it ONLY in memcached.  But, most use memcached 
> as a cache and not as storage.  Having said that, I have not used a 
> memcached session handler for PHP.  It is not supported natively that 
> I know of. So, you would have to look at the handler you are using.
>> - The most intriguing issue I've been buffled about is the following:
>> How to store SQL results. For example, say I store SELECTs as md5 into
>> memcache. Then say at some point in the code, an UPDATE is executed.
>> How can I determine which memcache keys (that is, which SELECTs)
>> should be invalidated?? Is there a framework or some way that do this
>> gracefully? Or should I use memcache only for queries that do not need
>> be updated immediately, but can update after they expire?
> You can really go two ways.
> 1. Cache raw sql queries and just let them expire.  Lacks granularity, 
> but is easy to implement.  If you start removing cache just when the 
> table changes, you are not doing much good.  The MySQL query cache can 
> do that on a MySQL server.  But, it is not nearly as good as a smart 
> memcached implementation.
> 2. Cache data at the object level instead of the query level.  This 
> will require more code and more
> For more information and ideas, you may want to read this:
> And I have posted some high level cache concepts in this blog post:

More information about the memcached mailing list