A short treaty on high-performance session caching.



Using memcached for sessions is naive (faster is not always better) and prone to huge issues with random log-outs. In-fact, as your site become more critical and has higher traffic then although it is counter intuitive you need to abandon RAM based caching solutions as users will quickly overwhelm the available storage. Database sessions provide a reasonably robust solution for badly designed server farms that do not use consistent server forwarding for a given user. Consistently forwarding a given user to a given server using file sessions is more efficient, with the only issue being the potential loss of the server and hence a random logout when another working server is selected - but that is a 'blue-moon' issue. However, this issue is tiny in comparison to the loss of the session server database storage which would take down the entire site.

There is also the option of using MCache sessions which access a session server. Distributed session servers are the best option for high-traffic multi-server installations and require only simple server forwarding rules. Distributed = robust, and caching is multi-level moving from RAM to disc and eventually to oblivion (GC) as usage of the session data ages through lack of access.



In the end each solution has a number of points of failure. Memcached is better used for less critical and far more efficient caching of data that can easily be recreated without user intervention. An extra moment to re-cache a lost page or query result is of no consequence to a user; having to log in again because session data was lost is highly annoying and leads to users giving up on the site (Google 'evony login' for a high profile example)



Overall experience in server farms using from ten to over five hundred servers has led us to this recommendation.



1. Make sure your load balancing rules send the same user to the same server consistently. This results is very efficient use of both database and memory caching. This allows for efficient file caching of sessions using the power of disc caches.



2. Even if you can do (1) above then there is still merit in using some form of persistent and properly garbage collected session caching. memcache and memcached both will create random log-outs for users and should be avoided for reasons given in the narrative.

Database session handling is robust across multiple servers, but its speed (or lack thereof) is the reason for this entire discussion.

Here mcache (which does *not* stand for memory cache) provides a session server with all the benefits of both memory caching for recent sessions and disc backup for swapped out session data.

Of course, the overhead in setting up mcache is higher - you may actually have to read a manual rather than using someone else's example from the interweb ;-)