mike wrote:
On 7/25/07, Martin Minka <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
Office: +61 3 9752 1512 ext. 366
Are you MySQL certified? www.mysql.com/certification
