[imp] memcached sessions

[Kevin M. Myer]

Quoting Liam Hoekenga <liamr at umich.edu>:

> What about making sure that one of the memcache servers was 
> "localhost" and trusting it as the authoritative one for the data?  
> When you write out session data, write it to localhost, and to 
> whichever in the pool you've decided to write to.  When you get 
> bounced to a new server, query localhost (which isn't going to have 
> it), and then query the pool if necessary?

And what if localhost dies?  Or you don't have tons of free RAM on your 
local machine?

> Either that... or write the data to all the servers in the pool.. 
> which is good for redundancy, but probably not great for performance.

Right :)

> How does the perl API handled pooled servers?  or libmemcache?  I'd 
> still like to look at the mcache extension (built on libmemcache), 
> but further work this PM has it still segfaulting.  It's a shame that 
> the maintainer of the PECL memcached extension doesn't see the value 
> in adding connection pooling to his code (I asked and he said "it's 
> easy to handle in your application in a few lines of code".  Blech.)

It is actually easy to handle, with a simple hash code, to determine 
which server to write to.  What I wrote a little bit ago just does 
that.  What it does not do is handle downed servers, because a downed 
server would change the number of available servers, and alter the 
results of the hash function, since a value it operates on is the 
number of available servers.

I think one of the dangers is trying to make one methodology fit into 
another one, without making some adaptations in the process.  I read 
through a lot of the memcached archives a few weeks ago and came away 
with a realization that memcached does just what it says it does - it 
caches data, to prevent (potentially slower) database lookups.  If a 
cache lookup fails for data, its no big deal, you fall through to the 
database.  Now when you try to fit information that impacts a page load 
and controls your user's experience on your web page, like session 
data, into a caching mechanism, that's not really designed for high 
availablity or failover, then things start to get trickier.  And you 
can't fault memcached for that, or even an API to use it, because it 
really is a simple concept and sometimes its better to not try to make 
nice simple things too complex, and just use and appreciate them for 
what they are intended to be.

So all that to say that what I think I've arrived at is:
1) memcached is a fast session store, if you can live with the lack of 
fault-tolerance
2) extending memcached to be fault tolerant might not be worth the 
effort - some sites have daemon uptimes of months on end, so it may be 
stable enough.  I'd probably end up restarting Apache more times than I 
would have to with memcached, when all is said and done.
3) The less layers of complexity, the better.  If I can get by with 
libevent + memcached + PHP + PECL + PECL memcache (and I'm already 
using PHP and PECL in the grand scheme of things) vs. libevent + 
memcached + PHP + libmemcache + php-mcache, thats one less layer and 
dependency that I have to deal with..

Not sure any of that contributes to anything - just some random thoughts..

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org