memcache PHP session handler redundancy

[Adam Donnison]

mike wrote:
> On 7/25/07, Martin Minka <martin.minka at gmail.com> wrote:
> 
>> The session handler is using power of more memcache servers to store
>> sessions, but it does not support redundancy and in case that one of
>> this memcache servers is lost, some sessions are lost.
> 
> i use a database (mysql) for this.
> 
> memcached imho is too volatile (by design) for me. unless session data
> does not change too often and i can issue the reads into the cache, i
> wouldn't bother personally. perhaps for a site with millions of users
> though. not sure. you might have to look into a hybrid method of
> committing to both places in the off chance you restart memcached, the
> data is pushed out due to LRU, etc.
> 
> (biggest thing is user experience and how important the data is in the
> session store)

I've set up memcached as a front-end for a MySQL backed session store, 
but in such a way that I can turn off the MySQL backend if need be or 
turn off the memcached front end.  In conjunction with this I looked at 
exactly what was being kept in session data, and realised that a lot of 
this was simply not vital data and could easily be recreated as long as 
we had a minimum of information (which is available in another cookie) 
with which the data could be found.

I'm currently running with only memcached for sessions, as session data 
is now no longer vital for getting a user up and running.

In any use of memcached or any other technology (like MySQL), you have 
to analyse your usage and decide what it is you are trying to achieve 
and then decide the best technology to achieve that.

Adam

-- 
Adam Donnison, Senior Web Developer
MySQL AB, Melbourne, Australia, www.mysql.com
VoIP:	sip:4524 at sip.mysql.com
Office: +61 3 9752 1512 ext. 366
Are you MySQL certified?  www.mysql.com/certification